@est31 the syntax highlighting is done by the editor we use from the [Scintilla project](www.scintilla.org), you should report there.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/595#issuecomment-185162709
> @@ -25,8 +25,8 @@ lexerror=error
>
> [keywords]
> # all items must be in one line
> -primary=alignof as be box break const continue crate do else enum extern false fn for if impl in let loop match mod mut offsetof once priv proc pub pure ref return self sizeof static struct super trait true type typeof unsafe unsized use virtual while yield
> -secondary=bool char f32 f64 i16 i32 i64 i8 int str u16 u32 u64 u8 uint
> +primary=abstract alignof as become box break const continue crate do else enum extern false final fn for if impl in let loop macro match mod move mut offsetof override priv proc pub pure ref return self sizeof static struct super trait true type typeof unsafe unsized use virtual where while yield
> +secondary=bool char f32 f64 i8 i16 i32 i64 int isize str u8 u16 u32 u64 uint usize
Probably was unfriendly to people with olde code using olde versions of rust to just simply remove them, doesn't hurt to have both in the keyword list.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/595/files#r53151616
Another thing syntax highlighters mistake about rust is its support for nested block comments.
For example take this code:
```Rust
/*
/*
inner
*/
interesting
*/
```
`interesting` here is commented out, because its still "inside" the outer comment boundary.
Same code rendered as C++:
```C++
/*
/*
inner
*/
interesting
*/
```
`interesting` here gets read like normal code. C++ parses, like C, from the first occurence of `/*` to the first occurence of `*/`.
I wonder, can geany cope with this? I don't use geany, so I can't test. I just know that the text editor I use (kate) has that precise problem.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/595#issuecomment-185159810
> @@ -25,8 +25,8 @@ lexerror=error
>
> [keywords]
> # all items must be in one line
> -primary=alignof as be box break const continue crate do else enum extern false fn for if impl in let loop match mod mut offsetof once priv proc pub pure ref return self sizeof static struct super trait true type typeof unsafe unsized use virtual while yield
> -secondary=bool char f32 f64 i16 i32 i64 i8 int str u16 u32 u64 u8 uint
> +primary=abstract alignof as become box break const continue crate do else enum extern false final fn for if impl in let loop macro match mod move mut offsetof override priv proc pub pure ref return self sizeof static struct super trait true type typeof unsafe unsized use virtual where while yield
> +secondary=bool char f32 f64 i8 i16 i32 i64 int isize str u8 u16 u32 u64 uint usize
Indeed, `uint` and `int` have been renamed to `isize`/ `usize` as per [rust RFC 0544](https://github.com/rust-lang/rfcs/blob/master/text/0544-rename-int-ui….
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/595/files#r53149667
Current situation (and USERLIST one suggested above too) has bad usability with the mouse (ctrl+click) as it requires a double click. As there is a primary mouse-based trigger, I think it's important to fix this.
(It probably could be nice to also directly select on single click from Scintilla's AUTOCLIST, but as wa don't have any mouse-based triggers currently it's not that important)
Anyway I tried to re-implement this using a `GtkMenu` and `gtk_menu_popup()`, and it had a subtlety (because we don't get the proper `GdkEvent` to feed `gtk_menu_popup()`) but otherwise was pretty straightforward, simpler (all popup logic is left out to `GtkMenu`), and behaves better regarding input, as click selects, and keyboard navigation works fine. As it isn't likely there would be an endless list of possibilities, and anyway if there was the UI here wouldn't be really usable, I don't think there is a problem with putting elements in a menu (which doesn't scroll before filling the screen).
WIP branch: https://github.com/b4n/geany/commits/wip/techee/multi_tag_goto%2Bpopup-menu…
---
> Regarding the popup I decided doing it the lightweight way - I had a look at Scintilla and the autocompletion positioning/resizing code is quite complex. So I just took some reasonable size values for the popup and placed it inside the middle of the window (similarly to the ctrl-tab document switching popup).
The complexity from Scintilla's popup placement is the will to align the text column exactly to the cursor, so that the autocompletion suggestion is perfectly vertically aligned with the buffer's text. This means location the exact X coordinate of the second row's cell renderer, which isn't that trivial.
In my above-mentioned menu-based popup I implemented [a straightforward version of the popup placement](https://github.com/b4n/geany/blob/wip/techee/multi_tag_goto%2Bpo… that simply places the top-left of the popup below the cursor. I believe this to be good enough in this case, as anyway the item text has nothing to do with the buffer's content.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/406#issuecomment-184301478
){kind=link}