This pull request switches us to the new cxx parser for C and C++.
There is nothing really special worth noting here apart from the
change how anonymous tags are called in the new parser. In the
old parser we had e.g.
```
anon_struct_1
anon_union_2
anon_typedef_3
```
which are now called just
```
__anon1
__anon2
__anon3
```
The question is whether we should do something about that or just keep it this way (it should be possible to rename the tags in our code, the only problem is that we have to go through all the tags and apart from tag names also update scope names).
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3032
-- Commit Summary --
* Add "l" prefix to functions in lcpp.c/h
* Rename C/C++ parsers to "Old"
* Add the new cxx parser
* Enable the new cxx parser
* Update C/C++ unit tests
-- File Changes --
M ctags/Makefile.am (32)
A ctags/parsers/cpreprocessor.c (2297)
A ctags/parsers/cpreprocessor.h (137)
A ctags/parsers/cxx/cxx.c (163)
A ctags/parsers/cxx/cxx_debug.c (182)
A ctags/parsers/cxx/cxx_debug.h (63)
A ctags/parsers/cxx/cxx_debug_type.c (54)
A ctags/parsers/cxx/cxx_keyword.c (639)
A ctags/parsers/cxx/cxx_keyword.h (178)
A ctags/parsers/cxx/cxx_parser.c (2023)
A ctags/parsers/cxx/cxx_parser.h (27)
A ctags/parsers/cxx/cxx_parser_block.c (804)
A ctags/parsers/cxx/cxx_parser_function.c (2281)
A ctags/parsers/cxx/cxx_parser_internal.h (388)
A ctags/parsers/cxx/cxx_parser_lambda.c (332)
A ctags/parsers/cxx/cxx_parser_namespace.c (345)
A ctags/parsers/cxx/cxx_parser_template.c (858)
A ctags/parsers/cxx/cxx_parser_tokenizer.c (1689)
A ctags/parsers/cxx/cxx_parser_typedef.c (491)
A ctags/parsers/cxx/cxx_parser_using.c (170)
A ctags/parsers/cxx/cxx_parser_variable.c (917)
A ctags/parsers/cxx/cxx_qtmoc.c (342)
A ctags/parsers/cxx/cxx_scope.c (276)
A ctags/parsers/cxx/cxx_scope.h (86)
A ctags/parsers/cxx/cxx_subparser.c (125)
A ctags/parsers/cxx/cxx_subparser.h (45)
A ctags/parsers/cxx/cxx_subparser_internal.h (27)
A ctags/parsers/cxx/cxx_tag.c (700)
A ctags/parsers/cxx/cxx_tag.h (202)
A ctags/parsers/cxx/cxx_token.c (185)
A ctags/parsers/cxx/cxx_token.h (124)
A ctags/parsers/cxx/cxx_token_chain.c (1220)
A ctags/parsers/cxx/cxx_token_chain.h (288)
M ctags/parsers/geany_c.c (130)
M ctags/parsers/geany_lcpp.c (48)
M ctags/parsers/geany_lcpp.h (32)
M ctags/parsers/geany_verilog.c (2)
M src/tagmanager/tm_parser.c (62)
M src/tagmanager/tm_parser.h (1)
M src/tagmanager/tm_parsers.h (5)
M src/tagmanager/tm_tag.c (2)
M tests/ctags/backslashes.c.tags (10)
M tests/ctags/bit_field.c.tags (46)
M tests/ctags/bug1201689.c.tags (2)
M tests/ctags/bug1466117.c.tags (8)
M tests/ctags/bug1491666.c.tags (8)
M tests/ctags/bug1563476.cpp.tags (1)
M tests/ctags/bug1575055.cpp.tags (2)
M tests/ctags/bug1585745.cpp.tags (8)
M tests/ctags/bug1764143.h.tags (4)
M tests/ctags/bug1770479.cpp.tags (2)
M tests/ctags/bug1773926.cpp.tags (2)
M tests/ctags/bug1799340.cpp.tags (6)
M tests/ctags/bug1907083.cpp.tags (8)
M tests/ctags/bug1924919.cpp.tags (4)
M tests/ctags/bug507864.c.tags (6)
M tests/ctags/bug556645.c.tags (3)
M tests/ctags/bug556646.c.tags (42)
M tests/ctags/bug639639.h.tags (6)
M tests/ctags/bug639644.hpp.tags (4)
M tests/ctags/c-digraphs.c.tags (6)
M tests/ctags/c-trigraphs.c.tags (6)
M tests/ctags/cpp_destructor.cpp.tags (6)
M tests/ctags/cxx11-final.cpp.tags (6)
M tests/ctags/cxx11-noexcept.cpp.tags (4)
M tests/ctags/cxx11-override.cpp.tags (6)
M tests/ctags/cxx11enum.cpp.tags (10)
M tests/ctags/cxx14-combined.cpp.tags (6)
M tests/ctags/extern_variable.h.tags (2)
M tests/ctags/func_typedef.h.tags (2)
M tests/ctags/local.c.tags (2)
M tests/ctags/macros.c.tags (4)
M tests/ctags/namespace.cpp.tags (4)
M tests/ctags/prototype.h.tags (2)
M tests/ctags/signature.cpp.tags (9)
M tests/ctags/static_array.c.tags (2)
M tests/ctags/var-and-return-type.cpp.tags (6)
-- Patch Links --
https://github.com/geany/geany/pull/3032.patchhttps://github.com/geany/geany/pull/3032.diff
--
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/pull/3032
```C++
namespace ns {
class C {
void f( // when typing the ( the calltip says "ns::C::f (junk, rubbish)"
public:
C(junk, rubbish){}
~C(){}
};
};
```
Yep, takes the parameters for the constructor and it uses that as the prototype for the new function that doesn't exist yet.
And ... if there happen to be other functions named `f` the calltips will cycle through the prototypes of those functions and never come back to the erroneous one.
Seems like some extraneous function definition is being made for the calltip. But it never appears in the symbol list. Like as if something is scanning for the ) and using the parameter list immediately before it, ignoring the `public: C(`. But what, its not the parser because the symbol doesn't show in the sidebar?
--
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/1249
geany version - 1.29
Most of the function declarations in glibc header files are marked with __THROW.
Geany cannot identify or incorrectly identifies these functions.
(sample files /usr/include/pthread.h, /usr/include/unistd.h).
--
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/1314
When I typedef int abc; abc is highlighted as a new type, but using abc = int; doesn't.
Moreover, it would be niece to have third kind of color for keywords.
One more thing, is it possible to declare keywords highlighted as numbers (ex. true, false, nullptr in the same color as 42, 0xDEADBEEF and so on) ?
--
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/1944
The multi-line comment within a macro means that `int y` (and all code following it) doesn't get parsed by ctags:
```c
int x;
#define CHANGE_TREE(new_child) \
G_STMT_START { \
/* only change the tag tree if it's actually not the same (to avoid flickering) and if
* it's the one of the current document (to avoid problems when e.g. reloading
* configuration files */ \
if (child != new_child && doc == document_get_current()) \
{ \
if (child) \
gtk_container_remove(GTK_CONTAINER(tag_window), child); \
gtk_container_add(GTK_CONTAINER(tag_window), new_child); \
} \
} G_STMT_END
int y;
```
Removing the comment restores parsing. The macro is actually from Geany's sidebar.c, but #2345 gets rid of it.
--
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/2349
Only a few of the symbols for the file `sidebar.c` show up in the symbols pane. This is due to the lines [here](https://github.com/geany/geany/blob/5b307bc05dbb055a06dc83c1d749ffab4… within a comment inside a macro not being backslashed confusing ctags.
Because cpp removes comments before preprocessing its not a problem for the compiler, cpp never sees the comment and the macro is whole, but ctags gets confused and gives up.
Should we just add the backslashes as a workaround. And is it worth reporting since we don't use the ctags "new C/C++" parser?
--
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/2916
I wanted to ask if there is an easy way of migrating to geany the (custom) syntax highlighting rules from either Atom, VSCode or Sublime.
(Background: https://github.com/davidchall/topas-syntax)
--
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/3056
I prefer that the terminal doesn't use bold fonts when printing characters with bold or highlight attribute since it's easier to my eyes.
This patch allows VTE to be configured that way through `vte_terminal_set_allow_bold()`.
Preview: http://i.imgur.com/KPZwPyi.png?1
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1132
-- Commit Summary --
* Allow VTE to be configured to not use bold fonts
-- File Changes --
M data/geany.glade (15)
M doc/geany.txt (3)
M src/keyfile.c (2)
M src/prefs.c (6)
M src/vte.c (3)
M src/vte.h (1)
-- Patch Links --
https://github.com/geany/geany/pull/1132.patchhttps://github.com/geany/geany/pull/1132.diff
---
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/pull/1132
When playing with the macOS bundle to look well both in light and dark themes, I noticed that in the dark theme colors in the message window are extremely hard to read with the default colors. While it may be hard to determine whether users use light or dark themes as discussed here
https://github.com/geany/geany/issues/2644
I think we should rather improve the default colors we use so they look reasonably well both in light and dark environments. I took the colors from the middle of the color spectrum here
https://uxplanet.org/create-an-easily-switchable-light-dark-styles-in-figma…
and the result looks quite good IMO:
<img width="1244" alt="Screen Shot 2021-11-20 at 18 22 16" src="https://user-images.githubusercontent.com/713965/142735812-3e8eac…
<img width="1244" alt="Screen Shot 2021-11-20 at 18 22 46" src="https://user-images.githubusercontent.com/713965/142735816-fb2cca…
I changed just the `geany-compiler-context` and `geany-compiler-message` colors which are the worst dark-theme offenders but we could update all the colors so we use a single color palette. The palette I used is just an example which looks good IMO but we could use other palette if someone has some better idea.
What do you think?
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3013
-- Commit Summary --
* Use dark-theme friendly colors for compiler messages
-- File Changes --
M data/geany.css (4)
-- Patch Links --
https://github.com/geany/geany/pull/3013.patchhttps://github.com/geany/geany/pull/3013.diff
--
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/pull/3013
This patch fixes symbol tree construction when #2657 is applied.
When a filter for tags is used for the symbol tree, it may happen that
parent tags in the symbol tree are removed because they don't match
the filter. Such tags are still visualised nicely by the symbol tree
which shows these tags with full scope like
```
MissingStruct::some_member
```
However, the current code doesn't expect that it may happen that
`MissingStruct` re-appears in the results when filter is deleted. In such
case `some_member` isn't re-parented under `MissingStruct` and stays
displayed in the above format.
This patch simply removes tags like `MissingStruct::some_member` for
which parent hasn't been constructed yet from the symbol tree and re-adds
them in the "insertion pass" for the symbol tree update code.
The only change this patch does is that it replaces
```
if (parent_name && ! g_hash_table_lookup(parents_table, parent_name))
parent_name = NULL;
```
with
```
if (parent_name && ! g_hash_table_lookup(parents_table, parent_name))
cont = tree_store_remove_row(store, &iter);
else
{
```
The rest is just indentation after the `else`.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3050
-- Commit Summary --
* Fix setting parents in symbol tree when filtering is used
-- File Changes --
M src/symbols.c (50)
-- Patch Links --
https://github.com/geany/geany/pull/3050.patchhttps://github.com/geany/geany/pull/3050.diff
--
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/pull/3050
![src="https://user-images.githubusercontent.com/713965/142735812-3e8eac…](http://src="https://user-images.githubusercontent.com/713965/142735812-3e8eac67-23cc-4dcf-9179-4ea1e1973934.png%22%3E){kind=link}
![src="https://user-images.githubusercontent.com/713965/142735816-fb2cca…](http://src="https://user-images.githubusercontent.com/713965/142735816-fb2ccabe-3547-4fc8-b752-60ba9da6d654.png%22%3E){kind=link}