Because of some problems with the macOS build of git master, I just modified it that instead of cloning the repo it just downloads the current master from https://github.com/geany/geany/archive/refs/heads/master.tag.gz. The tarball, however, doesn't contain a git repository and the build fails with
```
Program python3 found: YES (/Users/jhbuild/gtk/inst/bin/python3)
Program rst2html found: NO
Program rst2pdf found: NO
Program git found: YES (/usr/bin/git)
Running command: /usr/bin/git rev-parse --short --revs-only HEAD
--- stdout ---
--- stderr ---
fatal: not a git repository (or any of the parent directories): .git
../../../../gtk/source/geany-git/meson.build:170:1: ERROR: Command `/usr/bin/git rev-parse --short --revs-only HEAD` failed with status 128.
```
It appears that the problem is the line here which doesn't check if the repo exists (or recovers from the error):
https://github.com/geany/geany/blob/2509e21526d36034f5251381a76555e7300fbfc…
Once we make a release, the release tarballs will suffer from the same problem so I think it's something that should be fixed.
@kugel- Since you are the meson expert, any idea what the best solution of this problem should be?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3424
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3424(a)github.com>
A line like `function y = foo(a, b, c)` should yield a tag of `foo`, not `foo(a, b, c)`.
That way, Ctrl-clicking `foo` somewhere in the code will take me there.
The function name is `foo` after all, not `foo(a, b c)`.
Also, fixed issue where a line like `function foo() % this = bug` would yield a tag of `bug` instead of `foo` because the `=` in the comment was not ignored.
Finally, added a check to ensure that the line starts with the keyword `function`, and not any word starting with `function...` which could be a variable name (e.g. `functionality`).
Here I am considering that function names contain only alphanumeric characters (and underscore) as Matlab's documentation states. I'm not aware of the possibility of declaring functions with `.` or other special characters directly using `function`.
Example Matlab file demonstrating the issue:
```matlab
function y = foo(a, b, c) % the function name should be `foo`, not `foo(a, b, c)`
y = a+b+c;
end
function baz() % this = bug
disp('The function name is `baz`, not `bug`');
end
functionality = struct('a', 1, 'b', 2);
```
This used to yield tags `foo(a, b, c)` and `bug`, as well as `struct('a', 1, 'b', 2);` as a function; now it yields tags `foo` and `baz` as expected, and omits the `functionality` thing.
_(If it's any consolation, notice that GitHub also messes up the highlighting of `baz()` because of the `=` in the comment.)_
____
PS: Similarly, it might be good to figure out a way to also exclude occurrences of the substring `"struct"` that aren't the keyword `struct` itself, such as in strings, or as part of words, e.g.:
```matlab
restructure = true;
disp('You are on the way to destruction.');
```
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3358
-- Commit Summary --
* ctags: Matlab: function name only, without args
-- File Changes --
M ctags/parsers/geany_matlab.c (17)
-- Patch Links --
https://github.com/geany/geany/pull/3358.patchhttps://github.com/geany/geany/pull/3358.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3358
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3358(a)github.com>
This is a RFC regarding updating to the current version of Scintilla and getting off of the "fork" of the versions 3.x series (LongTerm3 branch).
The longer we wait to update, especially with the splitting off of lexers from Scintilla itself, we're basically just accumulating technical debt. Eventually the kind fellow currently maintaining the LongTerm3 branch will stop.
As far as I know, the main platforms Geany tries to support all have modern enough compilers/C++ standard libraries by now. There may be some older legacy/LTS platforms with users who won't be able to self-update to latest Geany without more effort, but with such limited developer time/interest/contributions for Geany, I don't think it's unreasonable to make some trade-offs like this in order to ensure Geany doesn't bitrot.
I might be willing to have a look at upgrading the code to work with latest Scintilla, but not if people are opposed, hence this RFC.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2519
Notable changes since 5.1.5
- multithreaded layouting and line wrapping. Neil says this can lead to dramatic improvements. Disabled by default, see SCI_SETLAYOUTTHREADS (i.e. we don't use it yet)
- New APIs to support 64-bit document positions on Win32: SCI_GETSTYLEDTEXTFULL, SCI_GETTEXTRANGEFULL, SCI_FINDTEXTFULL, and SCI_FORMATRANGEFULL We should move should move to these APIs, as the predecessors will be deprecated sooner or later. Not sure if it affects GTK-backend on win32 as well?
- Change bar (probably similar to the git-changebar plugin)
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3551
-- Commit Summary --
* Update Scintilla to version 5.3.6
-- File Changes --
M meson.build (2)
M scintilla/gtk/Converter.h (7)
M scintilla/gtk/PlatGTK.cxx (494)
M scintilla/gtk/ScintillaGTK.cxx (289)
M scintilla/gtk/ScintillaGTK.h (14)
M scintilla/gtk/ScintillaGTKAccessible.cxx (9)
M scintilla/include/Scintilla.h (60)
M scintilla/include/Scintilla.iface (80)
M scintilla/include/ScintillaCall.h (21)
M scintilla/include/ScintillaMessages.h (13)
M scintilla/include/ScintillaStructures.h (26)
M scintilla/include/ScintillaTypes.h (35)
M scintilla/lexilla/include/Lexilla.h (16)
M scintilla/lexilla/include/SciLexer.h (32)
M scintilla/lexilla/lexers/LexBash.cxx (935)
M scintilla/lexilla/lexers/LexBatch.cxx (59)
M scintilla/lexilla/lexers/LexCPP.cxx (210)
M scintilla/lexilla/lexers/LexCmake.cxx (2)
M scintilla/lexilla/lexers/LexCoffeeScript.cxx (8)
M scintilla/lexilla/lexers/LexDiff.cxx (57)
M scintilla/lexilla/lexers/LexGDScript.cxx (43)
M scintilla/lexilla/lexers/LexHTML.cxx (163)
M scintilla/lexilla/lexers/LexJulia.cxx (4)
M scintilla/lexilla/lexers/LexLua.cxx (6)
M scintilla/lexilla/lexers/LexMake.cxx (36)
M scintilla/lexilla/lexers/LexMarkdown.cxx (123)
M scintilla/lexilla/lexers/LexMatlab.cxx (200)
M scintilla/lexilla/lexers/LexNsis.cxx (4)
M scintilla/lexilla/lexers/LexPowerShell.cxx (83)
M scintilla/lexilla/lexers/LexProps.cxx (39)
M scintilla/lexilla/lexers/LexPython.cxx (103)
M scintilla/lexilla/lexers/LexR.cxx (252)
M scintilla/lexilla/lexers/LexRuby.cxx (778)
M scintilla/lexilla/lexers/LexRust.cxx (2)
M scintilla/lexilla/lexers/LexSQL.cxx (6)
M scintilla/lexilla/lexers/LexVHDL.cxx (18)
M scintilla/lexilla/lexers/LexYAML.cxx (87)
M scintilla/lexilla/lexlib/CharacterCategory.cxx (190)
M scintilla/lexilla/lexlib/CharacterSet.h (15)
M scintilla/lexilla/lexlib/DefaultLexer.cxx (3)
M scintilla/lexilla/lexlib/LexAccessor.cxx (9)
M scintilla/lexilla/lexlib/LexAccessor.h (30)
M scintilla/lexilla/lexlib/LexerModule.cxx (2)
M scintilla/lexilla/lexlib/LexerModule.h (2)
M scintilla/lexilla/lexlib/OptionSet.h (4)
M scintilla/lexilla/lexlib/PropSetSimple.cxx (8)
M scintilla/lexilla/lexlib/StyleContext.cxx (39)
M scintilla/lexilla/lexlib/StyleContext.h (104)
M scintilla/lexilla/lexlib/WordList.cxx (25)
M scintilla/lexilla/lexlib/WordList.h (1)
M scintilla/lexilla/src/Lexilla.cxx (10)
M scintilla/lexilla/version.txt (2)
M scintilla/src/CallTip.cxx (22)
M scintilla/src/CallTip.h (6)
M scintilla/src/CaseConvert.cxx (197)
M scintilla/src/CaseFolder.cxx (34)
M scintilla/src/CaseFolder.h (8)
M scintilla/src/CellBuffer.cxx (182)
M scintilla/src/CellBuffer.h (33)
M scintilla/src/CharacterCategoryMap.cxx (190)
M scintilla/src/ContractionState.cxx (83)
M scintilla/src/ContractionState.h (1)
M scintilla/src/Decoration.cxx (48)
M scintilla/src/Decoration.h (2)
M scintilla/src/Document.cxx (239)
M scintilla/src/Document.h (70)
M scintilla/src/EditModel.cxx (8)
M scintilla/src/EditModel.h (6)
M scintilla/src/EditView.cxx (1268)
M scintilla/src/EditView.h (53)
M scintilla/src/Editor.cxx (741)
M scintilla/src/Editor.h (60)
M scintilla/src/Geometry.cxx (20)
M scintilla/src/Geometry.h (29)
M scintilla/src/Indicator.cxx (28)
M scintilla/src/KeyMap.cxx (4)
M scintilla/src/KeyMap.h (2)
M scintilla/src/LineMarker.cxx (47)
M scintilla/src/MarginView.cxx (101)
M scintilla/src/MarginView.h (2)
M scintilla/src/Partitioning.h (128)
M scintilla/src/PerLine.cxx (57)
M scintilla/src/PerLine.h (42)
M scintilla/src/Platform.h (2)
M scintilla/src/PositionCache.cxx (304)
M scintilla/src/PositionCache.h (67)
M scintilla/src/RESearch.cxx (31)
M scintilla/src/RESearch.h (2)
M scintilla/src/RunStyles.cxx (118)
M scintilla/src/RunStyles.h (10)
M scintilla/src/ScintillaBase.cxx (82)
M scintilla/src/ScintillaBase.h (4)
M scintilla/src/Selection.h (10)
M scintilla/src/SparseVector.h (143)
M scintilla/src/SplitVector.h (28)
M scintilla/src/Style.cxx (3)
M scintilla/src/Style.h (1)
M scintilla/src/UniConversion.cxx (4)
M scintilla/src/UniConversion.h (2)
M scintilla/src/UniqueString.cxx (2)
M scintilla/src/UniqueString.h (7)
M scintilla/src/ViewStyle.cxx (89)
M scintilla/src/ViewStyle.h (18)
M scintilla/src/XPM.cxx (22)
M scintilla/src/XPM.h (4)
M scintilla/version.txt (2)
-- Patch Links --
https://github.com/geany/geany/pull/3551.patchhttps://github.com/geany/geany/pull/3551.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3551
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3551(a)github.com>
OK, so here's my take on #3542. I realized that I actually liked most of the stuff, it was just a matter of different presentation and some implementation details.
I think from the discussion in #3542 it was clear that most people wanted to see the path and line number and to to be able to distinguish it from the signature easily - the core thing was to use a different font for the file name (italics) and for the signature (small monospaced font). For the tooltip, I just separated these two by a newline.
In more details, this is what I did:
1. Show signature for all tag types using get_symbol_name() when get_symbol_tooltip() returns NULL. Modify get_symbol_name() to drop line number when needed. (More or less taken over the complete implementation from Colomban)
2. Add scope information to the signature both when using get_symbol_name() and get_symbol_tooltip(). (Based on Nick's idea)
3. Truncate the length of the popup to at most 80 characters (More or less taken over the complete implementation from Nick)
4. Improve formatting of entries in the popup so individual pieces of information are easier to distinguish:
- file name and line number are always in italics
- the following signature is in small monospaced font
5. Add tooltip to every entry (based on Nick's implementation).
- split the tooltip into two lines - the first line shows the file and the line number, the second line the signature
- both of the lines are formatted in the same way as described in (4)
(Thanks to Nick Treleaven and Colomban Wendling for the original implementation.)
@b4n @ntrel @elextr @kugel- What do you think? (Pinging about everyone, this will be one of those features where we'll all have a different opinion and hate each other with passion ;-)
The result looks something like this:
<img width="995" alt="Screenshot 2023-08-23 at 22 40 37" src="https://github.com/geany/geany/assets/713965/7ddc4946-06fa-4424-8…
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3547
-- Commit Summary --
* Improve tag-goto popup
-- File Changes --
M src/symbols.c (42)
M src/tagmanager/tm_parser.c (20)
M src/tagmanager/tm_parser.h (3)
-- Patch Links --
https://github.com/geany/geany/pull/3547.patchhttps://github.com/geany/geany/pull/3547.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3547
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3547(a)github.com>
Closing some directory structure from the sidebar tree (when showing the tree at least) sometimes crashes on master (and always makes Valgrind angry).
Steps to reproduce:
Given this file tree:
```shell
$ find /tmp/root/ -type f
/tmp/root/2
/tmp/root/1/1.1/1.1.2
/tmp/root/1/1.1/1.1.1
/tmp/root/1/1.2/1.2.2
/tmp/root/1/1.2/1.2.1
```
1. run Geany on those files (`geany -c /tmp/_new_config $(find /tmp/root/ -type f)`
2. right-click on e.g. directory `/tmp/root/1` in the document sidebar, and select "close"
3. you'll either see a crash, or that not everything under that directory got closed properly
Here's Valgrind being unhappy:
```console
$ valgrind geany -c /tmp/_new_config $(find /tmp/root/ -type f)
[…]
==917061== Invalid read of size 8
==917061== at 0x5B31345: g_node_nth_child (gnode.c:1052)
==917061== by 0x50A7361: gtk_tree_store_iter_nth_child (gtktreestore.c:793)
==917061== by 0x491DB76: on_openfiles_document_action_apply (sidebar.c:1330)
==917061== by 0x491DC0C: on_openfiles_document_action (sidebar.c:1347)
==917061== by 0x5A833AF: g_closure_invoke (gclosure.c:832)
==917061== by 0x5A96075: signal_emit_unlocked_R.isra.0 (gsignal.c:3796)
==917061== by 0x5A9CBF4: g_signal_emit_valist (gsignal.c:3549)
==917061== by 0x5A9CDBE: g_signal_emit (gsignal.c:3606)
==917061== by 0x50D7833: gtk_widget_activate (gtkwidget.c:7845)
==917061== by 0x4F8A935: gtk_menu_shell_activate_item (gtkmenushell.c:1375)
==917061== by 0x4F8AC70: gtk_menu_shell_button_release (gtkmenushell.c:791)
==917061== by 0x4DFBCB3: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130)
==917061== Address 0x9bcdc20 is 32 bytes inside a block of size 40 free'd
==917061== at 0x484317B: free (vg_replace_malloc.c:872)
==917061== by 0x5B3068B: g_nodes_free (gnode.c:123)
==917061== by 0x5B3068B: g_node_destroy (gnode.c:143)
==917061== by 0x50AA8F2: gtk_tree_store_remove (gtktreestore.c:1229)
==917061== by 0x491F851: sidebar_openfiles_remove_iter (sidebar.c:959)
==917061== by 0x491F8AE: openfiles_remove (sidebar.c:972)
==917061== by 0x491FA6C: sidebar_remove_document (sidebar.c:1027)
==917061== by 0x48D0B5B: remove_page (document.c:733)
==917061== by 0x48D29C0: document_remove_page (document.c:787)
==917061== by 0x48D29FC: document_close (document.c:695)
==917061== by 0x491DAED: document_action (sidebar.c:1299)
==917061== by 0x491DB47: on_openfiles_document_action_apply (sidebar.c:1322)
==917061== by 0x491DB9E: on_openfiles_document_action_apply (sidebar.c:1332)
==917061== Block was alloc'd at
==917061== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==917061== by 0x5B2C678: g_malloc (gmem.c:130)
==917061== by 0x5B45011: g_slice_alloc (gslice.c:1074)
==917061== by 0x5B305BD: g_node_new (gnode.c:110)
==917061== by 0x50AAF0B: gtk_tree_store_insert_before (gtktreestore.c:1375)
==917061== by 0x491E725: tree_add_new_dir (sidebar.c:654)
==917061== by 0x491E89A: get_parent_for_file (sidebar.c:840)
==917061== by 0x491E995: sidebar_openfiles_add_iter (sidebar.c:869)
==917061== by 0x491F5C7: sidebar_openfiles_add (sidebar.c:901)
==917061== by 0x48D0CE4: document_create (document.c:662)
==917061== by 0x48D3840: document_open_file_full (document.c:1349)
==917061== by 0x48D3C81: document_open_file (document.c:914)
==917061==
```
I believe this is due to collapsing directories together when there's only one child. This leads to tree iters changing, and overall structure shifting while navigating it -- even if it's down from the bottom-up depth-first as it is.
It's probably not trivial to fix, and I failed to do so quickly. One reason why it's not that easy is that it has to handle all this shifting *and* allow the tree to stay in the end if e.g. a file was not saved and the user cancelled the close request (my attempt was just to repeatedly close the first node until there was no more, but obviously that's not working).
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3527
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3527(a)github.com>
When the openfiles sidebar shows documents as a tree, closing a document can lead to sever re-layout of the view (e.g. collapsing directory nodes together). This makes walking the tree and closing documents at the same time highly tricky, as nodes might be shifting as we go.
This lead to invalid memory access, and unexpected results, when closing some tree structures.
One example of Valgrind showing how bad things are:
==917061== Invalid read of size 8
==917061== at 0x5B31345: g_node_nth_child (gnode.c:1052)
==917061== by 0x50A7361: gtk_tree_store_iter_nth_child (gtktreestore.c:793)
==917061== by 0x491DB76: on_openfiles_document_action_apply (sidebar.c:1330)
==917061== by 0x491DC0C: on_openfiles_document_action (sidebar.c:1347)
==917061== by 0x5A833AF: g_closure_invoke (gclosure.c:832)
==917061== by 0x5A96075: signal_emit_unlocked_R.isra.0 (gsignal.c:3796)
==917061== by 0x5A9CBF4: g_signal_emit_valist (gsignal.c:3549)
==917061== by 0x5A9CDBE: g_signal_emit (gsignal.c:3606)
==917061== by 0x50D7833: gtk_widget_activate (gtkwidget.c:7845)
==917061== by 0x4F8A935: gtk_menu_shell_activate_item (gtkmenushell.c:1375)
==917061== by 0x4F8AC70: gtk_menu_shell_button_release (gtkmenushell.c:791)
==917061== by 0x4DFBCB3: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130)
==917061== Address 0x9bcdc20 is 32 bytes inside a block of size 40 free'd
==917061== at 0x484317B: free (vg_replace_malloc.c:872)
==917061== by 0x5B3068B: g_nodes_free (gnode.c:123)
==917061== by 0x5B3068B: g_node_destroy (gnode.c:143)
==917061== by 0x50AA8F2: gtk_tree_store_remove (gtktreestore.c:1229)
==917061== by 0x491F851: sidebar_openfiles_remove_iter (sidebar.c:959)
==917061== by 0x491F8AE: openfiles_remove (sidebar.c:972)
==917061== by 0x491FA6C: sidebar_remove_document (sidebar.c:1027)
==917061== by 0x48D0B5B: remove_page (document.c:733)
==917061== by 0x48D29C0: document_remove_page (document.c:787)
==917061== by 0x48D29FC: document_close (document.c:695)
==917061== by 0x491DAED: document_action (sidebar.c:1299)
==917061== by 0x491DB47: on_openfiles_document_action_apply (sidebar.c:1322)
==917061== by 0x491DB9E: on_openfiles_document_action_apply (sidebar.c:1332)
==917061== Block was alloc'd at
==917061== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==917061== by 0x5B2C678: g_malloc (gmem.c:130)
==917061== by 0x5B45011: g_slice_alloc (gslice.c:1074)
==917061== by 0x5B305BD: g_node_new (gnode.c:110)
==917061== by 0x50AAF0B: gtk_tree_store_insert_before (gtktreestore.c:1375)
==917061== by 0x491E725: tree_add_new_dir (sidebar.c:654)
==917061== by 0x491E89A: get_parent_for_file (sidebar.c:840)
==917061== by 0x491E995: sidebar_openfiles_add_iter (sidebar.c:869)
==917061== by 0x491F5C7: sidebar_openfiles_add (sidebar.c:901)
==917061== by 0x48D0CE4: document_create (document.c:662)
==917061== by 0x48D3840: document_open_file_full (document.c:1349)
==917061== by 0x48D3C81: document_open_file (document.c:914)
Fix this by decoupling tree walking from closing documents. We now do two passes: first we collect documents to work on walking the tree as before, and only then we perform the action on each node of the list.
Fixes #3527.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3535
-- Commit Summary --
* Fix crash closing directory from the openfiles sidebar
-- File Changes --
M src/sidebar.c (29)
-- Patch Links --
https://github.com/geany/geany/pull/3535.patchhttps://github.com/geany/geany/pull/3535.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3535
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3535(a)github.com>