[Github-comments] Re: [geany/geany] New UI on windows is bloated and scaled up (Issue #3063)
> but not so well documented, and requires some hacker skills. Thats the idea of https://github.com/geany/www.geany.org/pull/40, any last minute suggestions how to improve it are welcome. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3063#issuecomment-1543217138 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] New UI on windows is bloated and scaled up (Issue #3063)
> we can't please all the people all the time So the best way is to give the user convenient tools that allow to customize the program to the maximum possible extent. With Geany, it's possible, but not so well documented, and requires some hacker skills. :) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3063#issuecomment-1543047002 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] New UI on windows is bloated and scaled up (Issue #3063)
My 2 cents (remember I'm not a Windows user) is that we can't please all the people all the time, especially with themes. If the techee-tweaked theme solves the Adwaita bloat that is the actual OP, then lets merge it, most importantly along with the wiki article about how to change it, and a link from the download page to the wiki since the download page is one place most Windows users will visit. Maybe after the release notes link below the table, don't bury it away. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3063#issuecomment-1542997802 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] New UI on windows is bloated and scaled up (Issue #3063)
> I'm close to give up on this. Would be a shame. > It's more like that @nrikonomov's comment kills our efforts to find a better > solution for most users. I'm not sure what exactly @nrikonomov meant, I thought that with the "project killing" comment he meant the use of those "250,250,250 shades" which I fixed in the Prof-Gnome theme some time ago. And he seemed to like the modified theme as mentioned in https://github.com/geany/geany/issues/3063#issuecomment-1272315353. It's hard to satisfy everyone but to my eyes the Prof-Gnome theme is neutral enough so it shouldn't offend too many people and fixes the OP's problem (with which I agree). If someone has some more constructive comments than "I don't like it", I can try to update the theme (like I did with the white color). I'd suggest switching to this theme - and if Geany's issue tracker gets filled by complaints of people that we killed Geany, we can always "revive" it by switching back to Adwaita. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3063#issuecomment-1542898938 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Rewrite Python standard library tags creation script for Python 3 (PR #3039)
@eht16 commented on this pull request. > @@ -8,296 +7,368 @@ # # This script should be run in the top source directory. # -# Parses all files given on command line for Python classes or functions and write -# them into data/tags/std.py.tags (internal tagmanager format). +# Parses all files in the directories given on command line for Python classes or functions and +# write them into data/tags/std.py.tags (internal tagmanager format). Thank you for spotting, fixed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3039#discussion_r1190423491 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Rewrite Python standard library tags creation script for Python 3 (PR #3039)
@eht16 commented on this pull request. > # If called without command line arguments, a preset of common Python libs > is used. # # WARNING -# Be aware that running this script will actually *import* modules in the specified directory +# Be aware that running this script will actually *import* all modules given on the command line # or in the standard library path of your Python installation. Dependent on what Python modules # you have installed, this might not be want you want and can have weird side effects. Amazing, someone actually read the docs :). Thank you for spotting, fixed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3039#discussion_r1190423354 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Rewrite Python standard library tags creation script for Python 3 (PR #3039)
@eht16 pushed 1 commit. 706ee56f0f0b2c09744c380b033b2ff44682a95e Fix doc typos -- View it on GitHub: https://github.com/geany/geany/pull/3039/files/d350dad27a45656cd9c84a0ac9dfb3a0412d6604..706ee56f0f0b2c09744c380b033b2ff44682a95e You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Port create_php_tags to Python3 and generate new PHP tags file (PR #3488)
> Is there a reason that Python tags are in ctags format and php tags in > tagmanager? Before #3039, Python tags were also in tagmanager format and so are the PHP tags. As said in https://github.com/geany/geany/pull/3488#issuecomment-1537369732, I would switch the format to ctags for the PHP tags as well. But I'd like to make this iterative to avoid a huge "I do it all in one"-PR :). -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3488#issuecomment-1542846084 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Port create_php_tags to Python3 and generate new PHP tags file (PR #3488)
@eht16 commented on this pull request. > # write tags script_dir = dirname(__file__) tags_file_path = join(script_dir, '..', 'data', 'tags', 'std.php.tags') -with open(tags_file_path, 'w') as tags_file: +with open(tags_file_path, 'w', encoding='iso-8859-1') as tags_file: The content parsed from the JSON is (probably) just ASCII. But the `TA_*` markers are not ASCII and are encoded in `iso-8859-1`, also for other files using this tagmanager format. I just added it on writing the file to explicitly set it, as Python3 `open()` wants the `encoding` argument. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3488#discussion_r1190417531 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Port create_php_tags to Python3 and generate new PHP tags file (PR #3488)
@eht16 commented on this pull request.
> (arg_list, TA_ARGLIST),
(return_type, TA_VARTYPE),
(scope, TA_SCOPE)]:
if attr is not None:
-tag_line += '{type:c}{attr}'.format(type=type, attr=attr)
+tag_line += f'{type_:c}{attr}'
+print(tag_line)
Oops, thanks for spotting. Just removed it.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3488#discussion_r1190415163
You are receiving this because you are subscribed to this thread.
Message ID:
[Github-comments] Re: [geany/geany] Port create_php_tags to Python3 and generate new PHP tags file (PR #3488)
@eht16 pushed 1 commit. 721550ca76caa155dc3ea2c7e0edb4710ef6c7e9 Port create_php_tags to Python3 and generate new PHP tags file -- View it on GitHub: https://github.com/geany/geany/pull/3488/files/36ccb38776e6c1439900b39c79b5a20a535c0969..721550ca76caa155dc3ea2c7e0edb4710ef6c7e9 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] New UI on windows is bloated and scaled up (Issue #3063)
I'm close to give up on this. It's more like that @nrikonomov's comment kills our efforts to find a better solution for most users. Aprt from that, I completely with what @elextr said in https://github.com/geany/geany/issues/3063#issuecomment-1539252949. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3063#issuecomment-1542828696 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany-themes] Fix broken theme index (PR #58)
The first commit roughly ports the `mkindex.py` to work with Python3 and regenerate the broken `index.json` (it got broken in #57 0c0a8c28bcd3479e472f6125f3362c679cfc895b). The broken `index.json` caused an error on the theme index page on the Geany website (https://www.geany.org/download/themes/). The other commits fix older, already existing errors in themes which were not detected because `make index` was not used :(. In the future, before merging PRs in this repository, the reviewer should take care that `make index` was executed or do it by himself/herself. Also the `AUTHORS` file is not very well maintained. PR creators and reviewers should carefully read `ADDING-A-THEME.md` before merging. Ideally, there would be a PR template to remind about this. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany-themes/pull/58 -- Commit Summary -- * Fix mkindex.py to work with Python3 and regenerate index.json * Fix duplicate key in retro theme * Fix screenshot filename for kary-pro-colors-light theme -- File Changes -- M colorschemes/retro.conf (1) M index/index.json (692) M index/index.json.md5 (2) R screenshots/kary-pro-colors-light.png (0) M scripts/mkindex.py (26) -- Patch Links -- https://github.com/geany/geany-themes/pull/58.patch https://github.com/geany/geany-themes/pull/58.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/pull/58 You are receiving this because you are subscribed to this thread. Message ID: geany/geany-themes/pull/5...@github.com
[Github-comments] Re: [geany/geany] [WIP] [D] Switch to mainline ctags parser (PR #3479)
@ntrel pushed 1 commit. 067914790722ea0d99e4d072ba4c5bb8be8cfa18 D: parse template instance types with parameter list -- View it on GitHub: https://github.com/geany/geany/pull/3479/files/d3fa78adb5747a9612261433a817a47566c1366e..067914790722ea0d99e4d072ba4c5bb8be8cfa18 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
> Maybe we have a different understanding of "signature", in my mind its the
> whole type, return (remember an override can be any covariant type, its not
> necessarily exactly the same as the `Iface::` declaration), qualifying
> scopes, name, and parameters, but IIUC you are using "signature" above just
> for the parameters?
I meant return type and parameter list. But it doesn't matter much if we
understand each other now :)
Anyway, I've been playing with this a bit to see how it feels, and I'm trying
this now, not hating it yet (not saying that'll last :slightly_smiling_face:):
One improvement would be using the editor font itself so it looks more natural,
and that shouldn't be too hard (either manually specifying the font in the
markup or with a tad of CSS)
this is the current diff:
```diff
diff --git a/src/symbols.c b/src/symbols.c
index 58451166e..1de3968d9 100644
--- a/src/symbols.c
+++ b/src/symbols.c
@@ -486,7 +486,7 @@ static void hide_empty_rows(GtkTreeStore *store)
}
-static const gchar *get_symbol_name(GeanyDocument *doc, const TMTag *tag,
gboolean found_parent)
+static const gchar *get_symbol_name(GeanyDocument *doc, const TMTag *tag,
gboolean found_parent, gboolean include_line)
{
gchar *utf8_name;
const gchar *scope = tag->scope;
@@ -530,7 +530,8 @@ static const gchar *get_symbol_name(GeanyDocument *doc,
const TMTag *tag, gboole
if (! doc_is_utf8)
g_free(utf8_name);
- g_string_append_printf(buffer, " [%lu]", tag->line);
+ if (include_line)
+ g_string_append_printf(buffer, " [%lu]", tag->line);
return buffer->str;
}
@@ -949,7 +950,7 @@ static void update_tree_tags(GeanyDocument *doc, GList
**tags)
/* only update fields that (can) have
changed (name that holds line
* number, tooltip, and the tag itself)
*/
- name = get_symbol_name(doc, found,
parent_name != NULL);
+ name = get_symbol_name(doc, found,
parent_name != NULL, TRUE);
tooltip = get_symbol_tooltip(doc,
found);
gtk_tree_store_set(store, ,
SYMBOLS_COLUMN_NAME,
name,
@@ -1006,7 +1007,7 @@ static void update_tree_tags(GeanyDocument *doc, GList
**tags)
expand = ! gtk_tree_model_iter_has_child(model, parent);
/* insert the new element */
- name = get_symbol_name(doc, tag, parent_name != NULL);
+ name = get_symbol_name(doc, tag, parent_name != NULL,
TRUE);
tooltip = get_symbol_tooltip(doc, tag);
gtk_tree_store_insert_with_values(store, , parent,
0,
SYMBOLS_COLUMN_NAME, name,
@@ -1509,20 +1510,28 @@ static void show_goto_popup(GeanyDocument *doc,
GPtrArray *tags, gboolean have_b
GtkWidget *image;
gchar *fname = short_names[i];
gchar *text;
+ gchar *tooltip;
gchar *sym = get_symbol_tooltip(doc, tmtag);
if (!sym)
- sym = g_strdup("");
- if (! first && have_best)
+ sym = g_strdup(get_symbol_name(doc, tmtag, FALSE,
FALSE));
+ if (!sym)
/* For translators: it's the filename and line number
of a symbol in the goto-symbol popup menu */
- text = g_markup_printf_escaped(_("%s:%lu: %s"),
fname, tmtag->line, sym);
+ sym = g_strdup_printf(_("%s: %lu"), fname, tmtag->line);
+ if (! first && have_best)
+ /* For translators: it's the symbol in the goto-symbol
popup menu */
+ text = g_markup_printf_escaped(_("%s"),
sym);
else
/* For translators: it's the filename and line number
of a symbol in the goto-symbol popup menu */
- text = g_markup_printf_escaped(_("%s:%lu: %s"),
fname, tmtag->line, sym);
+ text = g_markup_printf_escaped(_("%s"), sym);
+ /* For translators: it's the tooltip for a symbol in the
goto-symbol popup menu */
+ tooltip = g_markup_printf_escaped(_("%s:%lu:
%s"), fname, tmtag->line, sym);
g_free(sym);
image =
gtk_image_new_from_pixbuf(symbols_icons[get_tag_class(tmtag)].pixbuf);
- label = g_object_new(GTK_TYPE_LABEL, "label", text,
"use-markup", TRUE, "xalign", 0.0, NULL);
+ label =
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
Maybe we have a different understanding of "signature", in my mind its the whole type, return (remember an override can be any covariant type, its not necessarily exactly the same as the `Iface::` declaration), qualifying scopes, name, and parameters, but IIUC you are using "signature" above just for the parameters? > Anyway, I would have to try and use it without the file and line and see if I > can adapt to it, so I can have a better idea of whether the file really is > useful or just a habit I have. I mean, I'm not against having file:line, and @ntrel suggested having it as a tooltip IIRC, I'm just looking at ways to shorten the selection box since your image in the OP is indeed hard to use. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542400877 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
Anyway, I would have to try and use it without the file and line and see if I can adapt to it, so I can have a better idea of whether the file really is useful or just a habit I have. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542381962 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
> I would have thought they would be `bool Foo::maybedosomething(int n)` and > `bool Bar::maybedosomething(int n)` not the same? It wouldn't, that's what I wrote (emphasis mine): > Having the signature is fairly irrelevant: it's gonna always be the same. > **What's interesting is the symbol name and scope**, and as that'll usually > be spread in different files, the source file isn't useless. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542379742 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
Ahh, what is shown as the signature of the two implementations in in your example, I don't have the PR applied? I would have thought they would be `bool Foo::maybedosomething(int n)` and `bool Bar::maybedosomething(int n)` not the same? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542342885 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
BTW, this is giving weird results when going to anything that doesn't have a tooltip (e.g. anything that doesn't look like a callable), e.g. a type. Especially weird when called on a class name, as it'll look something like this, mixing names and nothing: * `foo.hxx:42: ` * `foo.hxx:44: ns::Foo::Foo ()` * `foo.hxx:44: ns::Foo::Foo (const Foo )` There should at least always be the fully qualified name on the right if we want to display something. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542337333 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
@elextr it mostly does, but that's not my point. My point is that if you have
an "interface" implemented by several classes:
```C++
class Iface {
public:
virtual bool maybeDoSomething(int n) = 0;
};
class Foo : public Iface {
public:
virtual bool maybeDoSomething(int n) override { return n == 42; }
};
class Bar : public Iface {
public:
virtual bool maybeDoSomething(int n) override { return (n % 42) == 0; }
};
```
Having the signature is fairly irrelevant: it's gonna always be the same.
What's interesting is the symbol name and scope, and as that'll usually be
spread in different files, the source file isn't useless.
Having the signature is useful when having overloads, not really for overrides.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3475#issuecomment-1542325433
You are receiving this because you are subscribed to this thread.
Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
> actually more often than the signature (as again, very often it's interface > implementations rather than overloads, so the signature is the same Well, goto declaration vs goto definition is supposed to separate the interface from the implementation, but I havn't actually evaluated how well that happens. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542293730 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] On limitations of Geany for C++ (Discussion #3493)
> Then Geany should not tell Scintilla to highlight local type names. In general the majority of C++ types are in header files so they are not local to my mind. But i'm not sure what you mean by local type names? And simply removing semantic information from some names isn't really a helpful solution if that makes them look different when semantically they are not. > Seems like they aren't keywords in the Scintilla sense. Yes, the Scintilla sense does not match what C++ does, thats the point. > Maybe too difficult for Scintilla to fix? It is with the current (ab)use of global word lists as typenames yes. > Although compiler support might not be there yet. IIUC MSVC does most of the modules spec, gcc and clang do the majority (but different majorities) so not all the fancy details are available yet, but the basics are there. Thats why not much is in the wild with modules yet. > The preprocessor is the source of so many headaches with parsing. I expect > supporting modules would be much more straightforward than supporting > includes. Certainly things like `#define`s can't cause changes to modules, so thats a blessing, but there is still the issue of getting the declarations that are `export`ed in the module interface into where the module is `import`ed. And there is still the issue of the module lookup path that is specified on the compiler command line (for clang at least) so the build system interaction is still needed to find them. And of course the dear olde STL is still there, so includes won't be going away anytime soon. > A LSP does sound like the way to go for all things related to parsing It does seem to be the flavour of the day for IDE/Editors yes, and that means that if there is a LSP for one IDE it can be used by others, thats the idea. Google finds at least one for D. > One thing that would be good is to support an external ctags program That would be slower than the current system of course, but then if its a separate process, not inline with the UI, it can be more thorough. The LSP is of course an external program too, and the method the editor/IDEs I have seen that use LSPs handle the delay by having a syntax colouring that runs fast inline with typing, and the semantic colouring is provided later from the parallel process of the language server. It would require some adjustment of the syntax lexers to not overwrite "semantic" styles, or an adjustment of Scintilla to store two sets of styling and use the semantic styling first and fallback to the syntax styles if its not present. > A LSP does sound like the way to go for all things related to parsing though > I'm not sure that syntax highlighting needs to be too sophisticated. The > latter means we can stick with Scintilla. I suspect that integrating the styling as outlined above would be not too hard, what would be difficult would be to find all uses of tagmanager within Geany and redirect the queries to the LSP given that tagmanager is synchronous, but the LSP is asynchronous. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/discussions/3493#discussioncomment-5861265 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
> I made https://github.com/geany/geany/pull/3495 to limit the width, does that > help? I'll give it a try, thanks > Whats the point of showing file:line? The goto symbol will go to it, and if > the user knows file:line they won't be using goto symbol, what is important > is to be able to select the correct version of the symbol to goto. Well, I myself very often use the goto feature as a quick way to go where I want, even if I know the file (yet, usually not the line). And most of the time I do know the file I want, actually more often than the signature (as again, very often it's interface implementations rather than overloads, so the signature is the same -- yet, the namespace/class is usually not) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542206091 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] On limitations of Geany for C++ (Discussion #3493)
> Scintilla semantic styling (keywords, types, and the rest) for names is global Then Geany should not tell Scintilla to highlight local type names. > final and override are only keywords in specific contexts Seems like they aren't keywords in the Scintilla sense. > if there tags are loaded local variables of the same name are shown by > Scintilla as types. Maybe too difficult for Scintilla to fix? > Can't follow includes C++ 20 has modules (only 45 years late!). Not sure how much work it is for C++ projects to switch to modules? Although compiler support might not be there yet. The preprocessor is the source of so many headaches with parsing. I expect supporting modules would be much more straightforward than supporting includes. --- A LSP does sound like the way to go for all things related to parsing, though I'm not sure that syntax highlighting needs to be too sophisticated. The latter means we can stick with Scintilla. One thing that would be good is to support an external ctags program - that way e.g. I could use the official dtags program written in D without making Geany depend on a D compiler. That would greatly improve parsing from either geany_c.c's support or uctags. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/discussions/3493#discussioncomment-5860600 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
Whats the point of showing file:line? The goto symbol will go to it, and if the user knows file:line they won't be using goto symbol, what is important is to be able to select the correct version of the symbol to goto. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542142535 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
> I got many cases where the popup now spans most of my screen width, making > the thing a bit hard to use quickly. I made #3495 to limit the width, does that help? > Also, although useful, the signature is so big and prominent that the > filename is almost buried and harder to find With that pull, the width shouldn't exceed the editor widget, so you can look for the filename on the left of the popup. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542119417 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Limit Go to Tag menu width to 80 (PR #3495)
Follow up to #3475. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3495 -- Commit Summary -- * Limit Go to Tag menu width to 80 -- File Changes -- M src/symbols.c (2) -- Patch Links -- https://github.com/geany/geany/pull/3495.patch https://github.com/geany/geany/pull/3495.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3495 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] Re: [geany/geany] Make Go to Symbol commands show symbol type/signature in list (PR #3475)
> what was the reasons for you to abandon it? Because looking for a signature is far more common for me than looking for file and line. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3475#issuecomment-1542082357 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Mark tags as "local" only for files with a known C/C++ source extension (PR #3490)
> I'll look a tad into modules out of curiosity one day, but does that mean > that a kind of header equivalent is generated by the compiler, so that it can > be installed and imported? Presumably somewhere internal to compiler data files somewhere I guess ... oooh, that google is good https://gcc.gnu.org/wiki/cxx-modules#CMI_Location #3245 > Just looking quickly at https://en.cppreference.com/w/cpp/language/modules > suggests that there will be an export keyword, making things fairly easy for > the C++ parser, doesn't it? Yes, if for that declaration only having an "export" keyword it overrules the file long "local visibility only" ruling made from having a `.cpp` or equivalent extension. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3490#issuecomment-1542017683 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] The annoyance autocompletion selection bar keeps back (Issue #3494)
Help solve the annoyance of invisible autocompletion selection bar, which keeps on coming up, usually after update geany related packages or else Please guide to the thorough solving action -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3494 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Mark tags as "local" only for files with a known C/C++ source extension (PR #3490)
> So if we set the filescope/local/whatever flag for `.cpp` files that will > make the symbols exported with the module invisible elsewhere, but they > should be visible. Just looking quickly at https://en.cppreference.com/w/cpp/language/modules suggests that there will be an `export` keyword, making things fairly easy for the C++ parser, doesn't it? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3490#issuecomment-1541857005 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Mark tags as "local" only for files with a known C/C++ source extension (PR #3490)
> Just to flesh out how C++ modules impact this. […] I'll look a tad into modules out of curiosity one day, but does that mean that a kind of header equivalent is generated by the compiler, so that it can be installed and imported? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3490#issuecomment-1541833084 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Mark tags as "local" only for files with a known C/C++ source extension (PR #3490)
I've been running this (well, almost… see below :grin:) for a couple days and
it seems to work nicely
My "small" patch on top just because:
```diff
diff --git a/src/tagmanager/tm_ctags.c b/src/tagmanager/tm_ctags.c
index a5cb9531e..16e2ebf04 100644
--- a/src/tagmanager/tm_ctags.c
+++ b/src/tagmanager/tm_ctags.c
@@ -119,12 +119,7 @@ static gboolean init_tag(TMTag *tag, TMSourceFile *file,
const tagEntryInfo *tag
tag->name = g_strdup(tag_entry->name);
tag->type = type;
- /* ctags sets "isFileScope" also for files with an unknown extension -
-* make sure we set "local" only for files with a known C/C++ extension
*/
- if (file->lang == TM_PARSER_C || file->lang == TM_PARSER_CPP)
- tag->local = tag_entry->isFileScope && file->is_c_source;
- else
- tag->local = tag_entry->isFileScope;
+ tag->local = tag_entry->isFileScope && file->trust_file_scope;
tag->flags = tm_tag_flag_none_t;
if (isTagExtraBitMarked(tag_entry, XTAG_ANONYMOUS))
tag->flags |= tm_tag_flag_anon_t;
diff --git a/src/tagmanager/tm_source_file.c b/src/tagmanager/tm_source_file.c
index 599ae4fa7..e5a27419b 100644
--- a/src/tagmanager/tm_source_file.c
+++ b/src/tagmanager/tm_source_file.c
@@ -609,20 +609,28 @@ static gboolean tm_source_file_init(TMSourceFile
*source_file, const char *file_
else
source_file->lang = tm_ctags_get_named_lang(name);
- source_file->is_c_source = FALSE;
+ source_file->trust_file_scope = TRUE;
+ /* ctags sets "isFileScope" for all C/C++ files without a known header
+* extension, but we don't want to use it for files with a less
conventional
+* extension, not to exclude symbols we shouldn't */
if (source_file->lang == TM_PARSER_C || source_file->lang ==
TM_PARSER_CPP)
{
- const gchar **ext;
- const gchar *common_src_exts[] =
- {".c", ".C", ".cc", ".cp", ".cpp", ".cxx", ".c++",
".CPP", ".CXX", NULL};
+ const gchar *ext = strrchr(source_file->short_name, '.');
- for (ext = common_src_exts; *ext; ext++)
+ source_file->trust_file_scope = FALSE;
+ if (ext)
{
- if (g_str_has_suffix(source_file->short_name, *ext))
+ const gchar *common_src_exts[] =
+ {"c", "C", "cc", "cp", "cpp", "cxx", "c++",
"CPP", "CXX"};
+
+ for (guint i = 0; i < G_N_ELEMENTS(common_src_exts);
i++)
{
- source_file->is_c_source = TRUE;
- break;
+ if (strcmp(ext + 1, common_src_exts[i]) == 0)
+ {
+ source_file->trust_file_scope = TRUE;
+ break;
+ }
}
}
}
diff --git a/src/tagmanager/tm_source_file.h b/src/tagmanager/tm_source_file.h
index f3ca0cbc8..342d1259c 100644
--- a/src/tagmanager/tm_source_file.h
+++ b/src/tagmanager/tm_source_file.h
@@ -36,7 +36,7 @@ typedef struct TMSourceFile
char *short_name; /**< Just the name of the file (without the path) */
GPtrArray *tags_array; /**< Sorted tag array obtained by parsing the
object. @elementtype{TMTag} */
/* Flag indicating whether the file is a C/C++ source (i.e. not a
header) based on its extension */
- gboolean is_c_source;
+ gboolean trust_file_scope;
} TMSourceFile;
GType tm_source_file_get_type(void);
```
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3490#issuecomment-1541830319
You are receiving this because you are subscribed to this thread.
Message ID:
[Github-comments] [geany/geany] On limitations of Geany for C++ (Discussion #3493)
Despite the heroic efforts of the Uctags crew and @techee and others there are some limitations that Geany can't overcome when using assistance features in C++. Since its come up a few times in various issue/PR discussions I thought it might be useful to summarise the fundamental limitations imposed by the underlying design of the Geany/Uctags/Scintilla combination in relation to C++. Or to put it another way, how C++ has outgrown that design which was "adequate" for plain C. I concentrate on C++ because I use and know it and because it has a Uctags parser that is more capable than most and because it manages to include nearly all the problems that the Geany design has for other languages :smile:. Hopefully an overall understanding of the limitations can guide a coordinated approach to heuristics that attempt to improve usability rather than individual heuristics being applied independently as happens now. These are in no special order. 1. Scintilla semantic styling (keywords, types, and the rest) for names is global, but C++ can re-use names for objects with different semantics in different scopes (`foo` can be a type in one scope but a variable or function in another), in different contexts (eg `final` and `override` are only keywords in specific contexts, they are variables elsewhere), and even in the same scope if a name is a struct/class/union type, a variable of the same name is allowed and hides the typename. Idioms like "first letter caps"ing typenames help, but the STL, Boost++ and other major libraries have all lower case typenames, so if there tags are loaded local variables of the same name are shown by Scintilla as types. 2. Can't follow includes, neither Geany nor Uctags can see includes because the dependencies are specified in the build system and neither can understand those. The result is that the information provided to users is compromised, see below. 3. Types of declared entities depends on declarations in the include files, which are not read, so the variable type is just an opaque name, no members, member functions or constructors information is available either to Geany or the user. 4. Types of expressions are not deduced so inferred types cannot be deduced, eg `auto a = foo(bah);` This is for two reasons: a. Uctags doesn't have any capability to do it, even the type of `1 + 1.0` b. even if it did have the capability the lack of accurate type information and template definitions from the include files means it cannot. 5. The lack of type information means that assistance features (autocomplete, calltips) are empty. 6. To avoid the total lack of accurate assistance features Geany attempts to use name based lookup, but that spams the lists with many irrelevant names. There is some attempt to filter or to rank by relevance, but its not particularly good simply because it does not have the information to work off. 7. Tags do not provide lexical scope information for variables, so name hiding cannot be deduced, so again name based lookup will show irrelevant options. 8. When C++ modules start being used in the wild they will suffer from all the include file problems and a few extras. How do a few other editor/IDEs do it?[^1] - Vscode - via plugin API, C/C++ is custom plugin IIUC, but one plugin talks Language Server Protocol to a Language Server Process (LSP) for whatever the language is. - Visual studio - C/C++ builtin custom MS intellisense, has LSP interface for other languages - Eclipse - C/C++ custom Java code plugin, plugin talking to LSP for other languages eg Rust, C# and more - Qt creator - LSP for some languages - Sublime text - LSPs - Xcode - LSPs for Swift, C/C++ (which is built on clangd) - Code Blocks - C/C++ plugin talking to clangd via LSP - Notepad++ - various alpha stage LSP plugins, but IIUC notepad does not use Lexilla. I am somewhat surprised at how fast LSP use has infiltrated the big guys like MS, Eclipse, and Apple although C/C++ are still supported by legacy code that existed before LSPs in some cases. So am I suggesting Geany should use LSPs, probably not, the previous attempt to use clangd showed that hard coded ways of doing things is heavily entrenched in Geany, its would take nearly a rewrite. Geany 2.0/GTK4 "somebody", anybody? [^1]: this list is to the best of my and googles knowledge in 1/2 an hour, it may contain erorrs and is certainly incomplet -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/discussions/3493 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-themes] Added new color theme evg-ega-dark, fixed mkindex.py (PR #57)
Merged #57 into master. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/pull/57#event-9207432334 You are receiving this because you are subscribed to this thread. Message ID:
