Hi everyone! Two years ago there was a request about such feature http://lists.geany.org/pipermail/users/2014-January/009121.html
And now there is patch that adds support for highlighting C function names. patch need some testing, if you will find wrong highlighting let me know.
Branch with path located here https://github.com/linvinus/geany/commits/highlight_function_names after install you need add new colors in your filetypes.c ``` function_declaration=class function=function ```
Since you have it in your github fork, can you make a pull request?
i can,but i suppose it need to be more tested also, mainly patched lexer in scintilla, so probably there should be pull request to scintilla upstream instead. what do you think? or make request anyway?
Well, if its mostly Scintilla, then yes you should make the request to them first. After its in a Scintilla release that has been included in Geany, you can make a PR of any changes in Geany that are then needed. That way the PR will be without the noise of the Scintilla changes.
Ok. for those who interested in that feature, please don't wait release, instead testing it right now. lang C is 100% supported lang C++ 100% supported, with only one bug-feature, some objects initialization also highlighted for example AutoSurface **surface**(this); without without context matching is not possible to resolve that.
Example of possible theme, left side is geany source on github, right side is geany with same file without text modifications,
looks almost the same =)
Out of curiosity, does it support function pointers?
```c g_signal_connect(obj, "sig", G_CALLBACK(some_function), NULL); GCallback cb = &some_function; sigc::mem_fun<void>(*this, &TheClass::some_function); ```
I don't think Scintilla should be doing the determination of function names, it should be another list like types. That way more accurate knowledge of function names can be provided from the symbol parsers or (soon) libclang plugin.
@codebrainz if you are talking about this line `GCallback cb = &some_function;` then no , it will not.
there is how it looks like with patch with default colors. 
@elextr it depends on how fast this external plugin will be.
highlighting in lexer is pretty fast to work on fly. i suppose this patch can be as option in lexer, so those who wish it, can enable it in configuration.
The external plugin isn't a problem for this since it will disable the Scintilla lexer anyway, its not logical to have two things doing colouring.
The symbol parsers exist now and are what provide the lists of typenames for type highlighting. Since the symbols also include the functions a similar method could be used to highlight function names with no change to Scintilla apart from perhaps allowing another name list.
@elextr sounds interesting, how to check this features?
See `document_highlight_tags()` in `document.c`. Thats where the typenames are passed to Scintilla, conceptually something similar for function names could be used. As I said before, you might have to add an extra wordlist to the Scintilla lexer, but thats easy IIUC. You would probably need a version of `symbols_find_typenames_as_string()` for function names.
@ekextr using Scintilla word lists for that is unrealistic in the current state of things, it's way too slow. I tried populating the list of C preprocessor symbols in a plugin, with all the macros definitions, and it caused very annoying slowdowns. Nothing causing a lockup, but way enough to be noticeable and annoying. So I'd think that the very same kind of problem would show with a very large list of function names. Possibly worse as there are a lot more identifiers to check against. Or possibly less because there's nothing to further compute. Anyway, I think before searching down this path testing how Scintilla can cope with a *huge* keyword list is needed.
Also, as there is actual syntax for function declarations and call, it might make more sense to highlight that syntax rather than known function names.
@b4n, sure, some premature optimisation of Scintilla is welcome :)
But as has been shown above, that syntax is used in C++ for more than one thing. It needs semantics to separate it, and Scintilla doesn't do semantics. Of course if typenames from the types list override the syntax it would be fine, but I'm not sure Scintilla can do that since it doesn't know which wordlists are which, and other Scintilla users might use a different wordlist.
Also explicit template function call syntax needs to be handled.
@elextr which tags function `document_highlight_tags()` should put to Scintilla? i mean is it internal tags , generated by Geany itself , or this tags loaded from some external file? for my testing file function `keywords_str = symbols_find_typenames_as_string(doc->file_type->lang, FALSE);` returns NULL
oh, i found, it loads struct definitions and etc. ok i understand that.
but i agree with @b4n CPP lexer in already checking lists for every word in file, increasing this lists will slowdown geany.
``` if (keywords.InList(s)) { lastWordWasUUID = strcmp(s, "uuid") == 0; sc.ChangeState(SCE_C_WORD|activitySet); } else if (keywords2.InList(s)) { sc.ChangeState(SCE_C_WORD2|activitySet); } else if (keywords4.InList(s)) { sc.ChangeState(SCE_C_GLOBALCLASS|activitySet); ... int subStyle = classifierIdentifiers.ValueFor(s); if (subStyle >= 0) { sc.ChangeState(subStyle|activitySet); } ```
my approach don't use any list.
probably, example from @codebrainz could be resolved if we collect detected function definition in some list. so that only local functions will be in that list, then pointers of that functions also will be highlighted
@elextr I don't really understand how you expect @codebrainz's examples to be highlighted. The code @linvinus suggests seems to try and find function *calls*. OK, posisbly the `foo` part of `foo<type>()` should probably be highlighted, but the `cb` variable or its RHS I'm not sure. I guess it depends on what you expect the feature to be.
Also, using a list of names can indeed highlight more locations, but OTOH it has many other shortcomings: * not syntax-based, which you don't currently like for type names: how would it really be different here? * bound to only highlight *known* names, so like for typenames it's unreliable as a visual clue as it's inconsistent. * as said, requires a way to feed the lexer with a very large list of names (probably at least a few hundred thousands, each names probably about 16 chars long in an optimistic scenario -- who said currently it means building a 2M string?), and the lexer to use that list, both in an efficient enough manner so it can reasonably be done whenever the list of functions names changes (which can happen on every keystroke).
probably, example from @codebrainz could be resolved if we collect detected function definition in some list. so that only local functions will be in that list, then pointers of that functions also will be highlighted
That wouldn't help, because in the `GCallback cb = &some_function;` case, I guess you want to highlight both `cb` and `some_function` -- or none. They are both callable, but there's no syntactic way to know it, short of figuring out `GCallback` is a function type -- and even then, only `cb` really is a callable, the RHS should be but what if the author was nasty… ```C const char *p = "hello"; void(*cb)(void) = p; ```
This will compile just fine -- even more so if you'd explicitly casted `p` appropriately --, but `p` isn't a callable.
PS: BTW, GitHub highlighting is confused by function pointer type apparently, and highlights `void` as a function call.
OK, possibly the foo part of foo<type>() should probably be highlighted, but the cb variable or its RHS I'm not sure.
Yes, and also I don't want operator() highlighted.
``` struct Foo { operator(){ ... } } foo;
foo();
```
`foo` is not a function name.
@elextr no, but it's a callable.
@b4n, lots of things are callable, but the identifiers are not functions :)
not syntax-based, which you don't currently like for type names: how would it really be different here?
Not much different really, the problem is semantics, not syntax. And thats the problem with all the options.
@b4n, lots of things are callable, but the identifiers are not functions :)
So you'll have to answer the question "what would you expect to be highlighted?"
I noted that Emacs recently had the same issues, maybe @linvinus could look at the Emacs ML logs and see what heuristics thay came up with.
improvements, in example from @codebrainz , now mem_func also highlighted 
example from @b4n is not highlighted as function, void is predefined word.
@elextr i'm not sure that i can understand emacs source code =)
operators is not highlighted as functions.
example from @b4n is not highlighted as function, void is predefined word.
Maybe in practice it'd be good enough as we provide keywords for most types, but in `SomeType(*p)()` `SomeType` shouldn't be highlighted as a function call either.
BTW, in your last screenshot, parenthesized initializers are highlighted and they probably should not ( the part ` : doc(doc_), position(position_)`)
@linvinus I didn't expect you to read their code :) I meant the discussion around when to assume foo() is a function and when its a declaration. IIRC they came to some acceptable (but not perfect) heuristics.
parenthesized initializers are highlighted and they probably should not
@b4n, Good catch, another place the syntax is used for something else, ahh C++ :)
operators is not highlighted as functions.
@linvinus I'm not sure you understood the point, in C++ the call operator () can be overloaded and applied to objects, not just to functions. Your image doesn't show that case. As @b4n says it depends if you want all callables highlighted, or functions.
To summarise:
1) it looks ok for C so long as non-call parens in expressions can't be confused with calls.
2) in C++ its possible that there will be too many erroneous highlights due to C++ using the call syntax in many places.
3) I'm not sure if/how well it applies to any of the other languages `Lexcpp.cxx` highlights.
I would suggest that the best way ahead is to submit your patch to Scintilla and see what Neil says. If he is happy then its fine.
The above discussion then becomes purely for Geany and which languages to make it visible for by making the SCE_C_FUNC a non-default style. Irrespective of which choice is made by default (say visible for C and invisible for C++) a user can always change it in their own configuration anyway.
The above discussion then becomes purely for Geany and which languages to make it visible for by making the SCE_C_FUNC a non-default style.
Or rather selecting whether the lexer option is enabled or not.
improvements, in example from @codebrainz, now mem_func also highlighted
In my example, I only meant `some_function` should be highlighted in each of the 3 lines, assuming it's defined like:
```c++ void some_function() {} // or c++ member function void TheClass::some_function() {} ```
I don't think `mem_fun` should be highlighted as a function since it's most likely a class name (would have to check libsigc++ code).
@codebrainz ok, i have removed this. @elextr your summarize is correct, but some things in C++ can be resolved. for example from version 3.5 of my patch, it don't highlight object initialization that i mention in this post https://github.com/geany/geany/issues/1231#issuecomment-247092487
to resolve that i also control parameters of function, if parameters format not equal to (type A,type B, ...) then it not declaration, with some other signs object initialization is recognized and not highlighted
this problem https://github.com/geany/geany/issues/1231#issuecomment-247300895 now resolved
by the way, why geany is not recognize following class declaration?
``` class LineVector {
Partitioning starts; PerLine *perLine;
public:
LineVector(); ~LineVector(); void Init(); ... } ``` LineVector - is not added as keyword.
by the way, why geany is not recognize following class declaration?
Works here. Note that currently you need the file to be saved to disk for symbols to be parsed (yes, even for in-memory parsing, I know).
@b4n not working for me :( (original geany 1.27) default config
could someone test my patch? latest version should be good enough for C++ too. how to configure described in first message of this thread
not working for me :(
There's probably a broken class in that file or something weird with macros that's causing ctags to break. It happens a lot to me when coding C++.
if parameters format not equal to (type A,type B, ...) then it not declaration, with some other signs object initialization is recognized and not highlighted
How did you determine the typenames? And don't forget in a C++ declaration the names `A` and `B` may or may not be present.
by the way, why geany is not recognize following class declaration?
Because its filetype C, not C++, see the status bar in your image above, so class definitions are not understood. Thats fixed in latest Git, but you may have a modified `filetype_extensions.conf` in your user config.
How did you determine the typenames?
by word count before comma "type A" == 2 "const type A" == 2 "enum type A" == 2 "struct type A" == 2 "type A = 0" == 2
And don't forget in a C++ declaration the names A and B may or may not be present.
i'm not a C++ guru, could you share some example?
Sorry I don't understand the "word count before comma" examples, you have ==2 for all of them?
i'm not a C++ guru, could you share some example?
Pick any C++ function _declaration_ (not a _definition_) and you can take out the parameter names and be perfectly valid. Using `CellBuffer.h` as an example `InsertText(int, int)` would be perfectly valid C++. But of course you couldn't leave out `line` from `LineStart(int line)` because its used in the definition. But in definitions you can leave them out if they are unused, that avoids annoying "Parameter x unused" messages.
you have ==2 for all of them?
yes
an example InsertText(int, int)
thanks!
you have ==2 for all of them?
yes
I don't understand, can you explain more?
it is pretty simple =) simple cut (ignore, don't count them) "const enum struct unsigned" from parameters also ignore one word after ''="
simple cut (ignore, don't count them) "const enum struct unsigned" from parameters
That lacks `volatile` and `union` at least. Not sure it's a very solid way of discriminating those.
Oh, ok, what about valid C function calls like:
``` fun("abc def", fun2(para1, para2), 15); ```
or valid C++ function calls like:
```C++ setter("root(//what.ever/)", "//what.ever/", &pl::Path::root, [this](){ bool newfail = getter("scheme()", "ftp:", &pl::Path::scheme, true); newfail |= getter("root()", "//what.ever/", &pl::Path::root, true); newfail |= indexer("segement(0,1)", "dir1", &pl::Path::segment, 0, 1, true); return newfail; }); ```
@b4n thanks for examples!
@elextr C example is fine 
C++ i not, thanks! i will thinking about it.
@elextr proto type `void fun("abc def", fun2(para1, para2), 15);` will not highlighted
proto type void fun("abc def", fun2(para1, para2), 15); will not highlighted
Well, its not a prototype, the prototype would be (at a guess) `void fun(const char*, int, int);` though the second parameter could be anything returned from `fun2`.
my mistake. c++ example also works fine
@elextr yes prototype `void fun(const char*, int, int);` is correct for C (not highlighted yet), but declaration and calls will highlighted.
@elextr just want to mention that usually no one use such prototypes, usually parameters names present in prototypes;
@elextr just want to mention that usually no one use such prototypes, usually parameters names present in prototypes;
In C++ it's common to leave a parameter name out even in the function definition, as @elextr to avoid "unused parameter" warnings (e.g. when overriding a method, or writing a callback function or some other things with a forced signature).
In C it's a little less common to see prototypes without parameter names, but it isn't rare either, some people use this style in all headers.
The problem with the C++ example is that `setter`, `getter`, `indexer` are types not functions, they should be highlighted as types. Whilst `pl::Path::root`, pl::Path::segment` and `pl::Path::scheme` are functions and should be highlighted as such.
(Ok, I was mean not telling you that, but I want to make the point that in C++, purely syntax does not designate a function.)
usually no one use such prototypes, usually parameters names present in prototypes
In C the names are not left out, but in C++ it is more common, and as I said above if a parameter is not used the name _must_ be left out to avoid compiler warnings. Remember in C++ a derived class can override functions of a parent class, but often doesn't need to use all the parameters.
Thanks for the opportunity to use my catch phrase "C++ is not C". Assumptions that its just C with classes are wrong, it has evolved into a very different language. Thats why I suggested above that its ok to submit this to Scintilla for C (and any other Lexcpp languages that it works for) but not yet C++.
@elextr if Geany will know about class then it will highlight this types
The problem with the C++ example is that `setter`, `getter`, `indexer` are types not functions, they should be highlighted as types. Whilst `pl::Path::root`, pl::Path::segment` and `pl::Path::scheme` are functions and should be highlighted as such.
Well, we're again asking what the changes proposed here are supposed to highlight: functions or calls. IMO highlighting calls is fine, whether it's a constructor or a function, and not highlighting functions/members used as value is fine too. But depending on what you see in the feature, you could indeed argue only functions should be highlighted, irrespective of whether they are called or not, and constructors shouldn't.
Really, before continuing and showing cases and arguing whether it's right or wrong, we should sort this out. What is this supposed to do in each one's opinion?
or even more correct question, is Geany should be more smart than user?
suppose we are open file at first time with such lines ```C++ setter("root(//what.ever/)", "//what.ever/", &pl::Path::root, [this](){ bool newfail = getter("scheme()", "ftp:", &pl::Path::scheme, true); newfail |= getter("root()", "//what.ever/", &pl::Path::root, true); newfail |= indexer("segement(0,1)", "dir1", &pl::Path::segment, 0, 1, true); return newfail; }); ``` how we will understand is getter is type or function?
or even more correct question, is Geany should be more smart than user? […] how we will understand is getter is type or function?
Well, the point of syntax highlighting is to help reading the code, so it generally must never be *wrong*.
But in this case I kind of agree: seeing it's a call can give interesting information, and whether it's a type or a function name seem secondary to me.
@b4n, yeah, clearly I am assuming it is to highlight function names, similar to highlighting type names, which was why I initially suggested a similar implementation.
so it generally must never be wrong.
how highlighting can be wrong? it is just color, user must understand source meaning independent from color. different colors make source more contrasting, so user may more easily to divide one thing from another but understand what kind type of thing, it is task for users , isn't ?
@linvinus so if a name is in a word list the style that sets overrides the style from the function call syntax? You should make that very clear in the submission to Scintilla.
In the case where the type is not in an open file you will of course not see type highlighting, the same as you will see default colour for the type names now.
@b4n, the fact that its a constructor and would normally return an object of that type is the far more important information, not that it happens to look like a function call, thats just a distraction.
so if a name is in a word list the style that sets overrides the style from the function call syntax?
yes.
without special colors, both types and functions also will have same color - text color ;) no one is confusing in that case
but understand what kind type of thing, it is task for users , isn't ?
I don't know about others, but for me highlighting provides visual queues that something is wrong in my code. For example if I forgot a brace, all the missing type name highlighting tells me there's a mistake, or if I write `viod foo();` and what was supposed to be a keyword isn't highlighted as such, it lets me know at a glance and sticks out as being a typo. This is why I'm interested in adding semantic highlighting to Geany for the languages I use most often (as discussed on the mailing list recently), to make it even more useful.
@linvinus
how highlighting can be wrong? it is just color, user must understand source meaning independent from color.
Imagine that some portion of the code was highlighted as a string or comment while it actually isn't a string or a comment. That won't help reading the code, but rather will make it a lot harder, because you have *incorrect* visual clues. We don't want that.
@elextr
the fact that its a constructor and would normally return an object of that type is the far more important information, not that it happens to look like a function call, thats just a distraction.
Well, your constructors (?) return booleans, or are converted to it. The call site meaning is clearly function-like, how it's implemented looks fairly secondary in your example. Sure, it might actually be a lot more convoluted, and return a more complex object but that object can be converted to boolean, or has `operator |`, but the caller doesn't seem to really care.
@codebrainz compiler will give you same information in error report
@b4n yes if function highlighted as string this is totally wrong, but i'm talking about things that is looks similar.
so i agree with you, it is doesn't matter is it function or constructor, it call something and return something exactly like function.
earlier https://github.com/geany/geany/issues/1231#issuecomment-247300895 was good example where function-like style works not like function , that case is already resolved in my patch
@b4n @linvinus the example is unusual in that it does something strange with the object, in most cases you do `auto var = typename(params);` so only the `typename` tells you what is going on and it is currently type highlighted in Geany providing a good cue.
If the typename is still highlighted as a type when Geany knows about it (as @linvinus showed) thats fine, it provides the cue to whats going on. Having the function highlighting _removing_ the existing type highlighting functionality seems a backward step.
@elextr if `typename` will be highlighted as function is this will real problem for you? (if Geany also will not know about that type)
@linvinus probably not, it will be a reminder to open the .hpp file to get the types :)
@elextr ok, i will take into account your opinion
@elextr ok, i will take into account your opinion
Just to be clear, the opinion was "its not a problem", this sounded like you might have thought I said it was a problem.
@linvinus have you checked with Scintilla about these changes? If not, you might want to make sure such changes will be accepted there first. It would be a shame to see you spend all this time perfecting your patch only to have it rejected by Scintilla's maintainer (and thus never make it into Geany).
@codebrainz this patch is not for Scintilla authors. primary it for my self. I'm understand that task is very complicated so there always will be people who disagree with it.
if it will not accepted in Scintilla i will not upset, this patches will exist in my ppa repository anyway.
if it will not accepted in Scintilla i will not upset, this patches will exist in my ppa repository anyway.
Sounds good.
parsing function parameters was bad idea, i have removed this part, but now if geany know class, then object initialization will not highlighted.
there is C style (class is unknown), it looks like C prototype 
and this is C++ style (class is known) 
there is another idea, if file type GEANY_FILETYPES_CPP or GEANY_FILETYPES_C will be available on Scintilla lexer side , then lexer may change highlighting behavior, for example don't highlight C-style prototypes at all, because they are looks like object initialization, which is used in C++ very often.
for example, don't highlight 'spaceText' part ```C++ std::string spaceText(virtualSpace, ' '); ``` what do you think?
Note that `LexCPP,cxx` styles for C, C++, Java and JS, but doesn't distinguish between them. Geany distinguishes between them, but Geany and Scintilla are different projects and there are a number of other users of Scintilla. So Scintilla can't depend on anything thats Geany specific.
Also Geany (ab?)uses `LexCPP.cxx` for a number of other built in languages as well as the four above, Actionscript, Ferite, Go, and Haxe and there are several custom filetypes distributed with Geany that use C styling, CUDA, Genie, Graphviz, JSON and Scala. Finally there are many custom filetypes on the wiki and I bet a number of those use C styling.
So it would be best to (as @b4n commented above) to have a property to specifically turn this on or off in the Scintilla lexer as the language sees fit, see `OptionSetCPP`.
@elextr you are right! implemented as option for lexer.
Geany with this patches now available in this PPA https://launchpad.net/~linvinus/+archive/ubuntu/geany
hi. can someone help me? i don't understand in this example https://github.com/Olga-Yakovleva/RHVoice/blob/6ce2461e0a73c46d7ee809e9bd9fd... ```C++ stress_pattern stress=word_with_syls.eval("word_stress_pattern").as<stress_pattern>(); ``` `as<stress_pattern>()` is a function call or not?
Well, its an application of the function call `()` operator, so I guess it is a form of call.
thanks.
Also of note is that the expression before it ends in `.` so it must be an non-static member, so it can't be a type so the expression can't be a constructor, so it must be a function call. Though the most reliable method determining it of course remains looking at the type returned by `eval()` and what member `as<>` is.
there is declaration https://github.com/Olga-Yakovleva/RHVoice/blob/6ce2461e0a73c46d7ee809e9bd9fd...
Hi there!
Would you kindly tell me, will this feature be available some day? What's the current status of development?
Conversation here was really long and i'm really sorry if I'm missing info about merging & etc.
Thank you ;)
Ping, this is a must!
@pedrib nothing has been done since 2017 AFAICT, so you are going to have to make a pull request against current Scintilla (and submit that upstream) and current Geany, with both incorporating the discussions in this issue.
@elextr I'm going to submit a PR, need to get some free time to port the changes and test thoroughly. Already had a look, no PR for Scintilla needed, only Geany changes needed. It's easy to port the changes to the latest git, but I will need to test it thoroughly.
Hi everyone!
Happy 9th anniversary of this issue of a C syntax highlighting problem in one of the most popular Linux IDEs never getting fixed.
I'm just curious if literally anyone intends to ever fix this fundamental problem, or should I start learning C++ so we don't get to the 10th anniversary and make an even bigger meme of the FOSS community than it is?
No, seriously. If nobody is going to do it, I will personally do it by this time next year. I will fix it if it takes that. Just give me a heads up.
@iloveclang highlighting function names for C _only_ might be acceptable.
But as you will learn when you learn C++ the name before the `(` is _NOT_ always a function name (and in Python and many other languages too) so simple highlighting implementations that may be acceptable in C are incorrect in other languages, hence the suggestion to restrict to C.
Also in non-C languages the function name is not always immediately before the `(` eg `get<Foo>(bar)`.
No, seriously. If nobody is going to do it, I will personally do it by this time next year. I will fix it if it takes that. Just give me a heads up.
Well, you and @pedrib should talk maybe, they thought they had a solution? PRs are welcome of course, but "somebodys" gotta do them.
Sorry, been a bit too busy to look at this. @iloveclang you just need to port the patch to the newest geany version and test it out. I did it but then for whatever reason I forgot about it and deleted the patched repo (I'm a dummy, I know). It's really easy, took me a couple of hours if I recall correctly, just needed to fix a few things here and there so that everything builds properly - but note that I did not test it out, so I'm not sure if it works well.
Sorry everyone, I had this sitting on my computer for six months and completely forgot about it. I ported @linvinus patch to the latest git ([469db15](https://github.com/pedrib/geany/commit/469db1505508e1f4b9091e2ebe9be5d7434ac...)). I only fixed some porting issues, otherwise, it's 100% his work untouched.
It seems to work beautifully :D
However I HAVE NOT TESTED IT PROPERLY! Please test it out to see if it's suitable for integration into geany: https://github.com/pedrib/geany/tree/highlight_c_cpp
Sorry everyone, I had this sitting on my computer for six months and completely forgot about it. I ported @linvinus patch to the latest git ([469db15](https://github.com/geany/geany/commit/469db1505508e1f4b9091e2ebe9be5d7434ac9...)). I only fixed some porting issues, otherwise, it's 100% his work untouched.
It seems to work beautifully :D
However I HAVE NOT TESTED IT PROPERLY! Please test it out to see if it's suitable for integration into geany: https://github.com/pedrib/geany/tree/highlight_c_cpp
@iloveclang if you wanna help please test it thoroughly, with huge, big, small and tiny source code files, multiple files opened at a time, C, C++, etc.
Since I'm not happy with my own testing, I'll wait for at least 5 or 10 other people to test it and say it works before submitting an "official" PR.
@pedrib also most of the changes are to Lexilla, so should be submitted there first, Geany does not have the resources to support non-standard lexers.
At least Lexilla is now github, not sourceforge mercurial :-)
@elextr to be clear, all files under ./scintilla should be submitted there right? The rest goes to geany?
I'll let people test out my branch first before submitting
@elextr to be clear, all files under ./scintilla should be submitted there right? The rest goes to geany?
Yeah, SciLexer.h and LexCPP.cxx to [lexilla](https://github.com/ScintillaOrg/lexilla) rest to Geany, but not until the lexilla fix is included.
I'll let people test out my branch first before submitting
Wise ;-)
I cannot test ATM, but a quick scan of the patch suggests some tests:
```C char f(char c){ return c; } char c = f(')'); ```
For C++ [here](https://github.com/pedrib/geany/commit/6b6eaa2e68e8a64f2ebfd3c3f029a5bb4fe2b...) not just `const` but `override` and `final` and `noexcept` and `&&` and attributes and `-> return_type` can occur , see [here](https://en.cppreference.com/w/cpp/language/function) and [here](https://en.cppreference.com/w/cpp/language/member_functions).
Does it highlight constructors as functions even if their names are in the wordlist of types Geany supplies to the lexer?
It attempts to skip macro declarations, but are macro "calls" treated as function calls?
The rest got too hard to follow, maybe later.
Since (AFAICT) it can all be turned off with properties, the discussion of what the defaults for C++ should be might be a :bike: :house: depending on how well it does C++, noting that prototypes are already off by default for C++.
@elextr thanks for the tips. Don't take this as presumption, but I'm pretty busy to do thorough testing and deep changes to the code. I'll let the other people here take on some of that work.
@all Everyone has been super vocal, so if you are reading this and interested in integrating this patch in geany, here is your chance!
Yup. Looks good. Tried it with a bunch of files. Maybe you could compile a few binaries so people can test it more easily. Took me an hour to install all the dependencies and stuff.
@iloveclang did you check what @elextr raised? We need to get his seal of approval to be able to move forward...
Took me an hour to install all the dependencies and stuff.
@iloveclang what platform are you on?
You can install all dependencies in Ubuntu with `apt build-dep geany`
@elextr
arch
I meant the build dependencies. like meson and all the random stuff it needs, and autotools and all the random libraries it encompasses.. and stuff like that
Well, you only needed one of autotools vs meson for Geany and autotools for plugins, not both. I never noticed meson needed any dependencies other than ninja (which a sensible package system should pull in automatically when meson is installed, but I don't know about arch). Autotools has more moving parts for sure.
And of course you need the dependencies of Geany itself, which means `-dev` packages for them on Debuntu etc. Again, don't know how arch packages them. As @pedrib said there are commands for Apt based systems to install them based on the apt package data. But sadly this disparity of packaging means its difficult to provide simple portable recipes for building from Git :-(
Anyway you got it to work which is good, really needs more people to comment on how useful it is/isn't on C and C++ before @pedrib expends the effort to clean up the patch and make a PR to Lexilla then Geany. @iloveclang I presume you looked at C since that was your initial post. Most of my queries relate to C++ so we need more input from C++ users.
Come on gents, everyone was crying about this, now no-one wants to help test it?!
Built the highlight_c_cpp patch and it works great for C. It picks up the 'class' and 'function' colours from the colour scheme.
Function definition uses the 'class' colour. Function calls uses the 'function' colour. Structs have the 'class' colour.
Tried some cpp files and they were the same as above for C.
Mybe there is a bug with Enums? Enum have 'class' colour. Choose a different colour scheme and then change back again. The Enum colour disappears.
Thanks for the patch! It really helps the C look better.
@AprilInParis is that the original or my modified version?
I tested your branch here: https://github.com/pedrib/geany/tree/highlight_c_cpp
A better way of doing this would be using a language server for which @techee has an implementation at [geany-lsp](https://github.com/techee/geany-lsp) that uses clangd (and pyls and gopls).
The LSP protocol allows for semantic tokens for "functions" but its not enabled yet since it is not an existing feature in Geany, only colourising the "types" is used but it works well.
If "somebody" contributed the code to support function semantic tokens in Geany-lsp it would probably work if clangd supports it. Vscode is able to colourise function names correctly because it uses a MS version of clangd.
github-comments@lists.geany.org