>
> I just tried the patch and it doesn't seem to work for me, if I change a
> type name other occurrences of it don't change:
>
> typedef int bar;
>
> bar z;
>
> if you change the name of the typedef, the typedef itself gets
> re-highlighted when the cursor blinks (roughly a second later), but the
> usage below don't.
>
OK, right - the color would get updated only after you start typing.
> However, instead of re-colorizing everything maybe we could only colorize
> up to the end of the visible area, which would mitigate (or even
> eradicate?) the slowness:
>
> diff --git a/src/editor.c b/src/editor.c
> index 1336588..cfbfbe9 100644--- a/src/editor.c+++ b/src/editor.c@@ -4682,12 +4682,20 @@ on_editor_scroll_event(GtkWidget *widget, GdkEventScroll *event, gpointer user_d
> static gboolean editor_check_colourise(GeanyEditor *editor)
> {
> GeanyDocument *doc = editor->document;+ gint start_line, end_line, start, end;
>
> if (!doc->priv->colourise_needed)
> return FALSE;
> + start_line = SSM(editor->sci, SCI_GETFIRSTVISIBLELINE, 0, 0);+ end_line = start_line + SSM(editor->sci, SCI_LINESONSCREEN, 0, 0);+ start_line = SSM(editor->sci, SCI_DOCLINEFROMVISIBLE, start_line, 0);+ end_line = SSM(editor->sci, SCI_DOCLINEFROMVISIBLE, end_line, 0);+ start = sci_get_position_from_line(editor->sci, start_line);+ end = sci_get_line_end_position(editor->sci, end_line);+
> doc->priv->colourise_needed = FALSE;- sci_colourise(editor->sci, 0, -1);+ sci_colourise(editor->sci, start, end);
>
> /* now that the current document is colourised, fold points are now accurate,
> * so force an update of the current function/tag. */
>
>
> This is insufficient because when the document gets loaded, we need to
perform the whole-document colorization otherwise we won't get valid fold
points ("fold all" doesn't work as expected with your patch).
Anyway, we can have two types of colorization - full, performed on document
load, and partial (the one from your patch), performed only to recolorize
typenames (they won't modify fold points in any way so it should be safe).
I've updated the patch with this and it seems to work well.
(The updated patch still fixes the performance problem - the visible area
colorization appears to be cheap.)
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/575#issuecomment-164157945
@elextr what do you mean? if someone wants accurate style/fold info on some possibly invisible area, one has to ask for it using [`SCI_COLOURISE`](http://www.scintilla.org/ScintillaDoc.html#SCI_COLOURISE), just like the code @techee wants to get rid of does. Neither Scintilla nor us ever guaranteed everything was always styled, and it probably often isn't (typically it's not in the notification when you just entered a character).
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/575#issuecomment-164041597
I just tried the patch and it doesn't seem to work for me, if I change a type name other occurrences of it don't change:
```C
typedef int bar;
bar z;
```
if you change the name of the typedef, the typedef itself gets re-highlighted when the cursor blinks (roughly a second later), but the usage below don't.
However, instead of re-colorizing everything maybe we could only colorize up to the end of the visible area, which would mitigate (or even eradicate?) the slowness:
```diff
diff --git a/src/editor.c b/src/editor.c
index 1336588..cfbfbe9 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -4682,12 +4682,20 @@ on_editor_scroll_event(GtkWidget *widget, GdkEventScroll *event, gpointer user_d
static gboolean editor_check_colourise(GeanyEditor *editor)
{
GeanyDocument *doc = editor->document;
+ gint start_line, end_line, start, end;
if (!doc->priv->colourise_needed)
return FALSE;
+ start_line = SSM(editor->sci, SCI_GETFIRSTVISIBLELINE, 0, 0);
+ end_line = start_line + SSM(editor->sci, SCI_LINESONSCREEN, 0, 0);
+ start_line = SSM(editor->sci, SCI_DOCLINEFROMVISIBLE, start_line, 0);
+ end_line = SSM(editor->sci, SCI_DOCLINEFROMVISIBLE, end_line, 0);
+ start = sci_get_position_from_line(editor->sci, start_line);
+ end = sci_get_line_end_position(editor->sci, end_line);
+
doc->priv->colourise_needed = FALSE;
- sci_colourise(editor->sci, 0, -1);
+ sci_colourise(editor->sci, start, end);
/* now that the current document is colourised, fold points are now accurate,
* so force an update of the current function/tag. */
```
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/575#issuecomment-164031773
@b4n Could you apply this one? Regardless of whether this is the main cause of https://github.com/geany/geany/issues/791 or not, I believe it should be applied because it helps in general. And better to apply it earlier in the release cycle to check if it has some side-effects (but I believe it doesn't).
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/575#issuecomment-163988079
Forgot to mention, this isn't meant to be the final pull request - I'd just like some feedback on the last four patches and then make the remaining minor corrections (I'll probably make a new pull request for the final version).
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/505#issuecomment-163684603
Alright, I've repushed the anonymous struct handling fix - having the global counter for anonymous types caused a problem with unit tests. With the global per-all-file counter the anonymous struct name would become different every time and the generated tags files might be different every time the tag file is generated.
I hope the current approach works well - all this namespace search code is like walking through a minefield - you never know what gets broken if you make a change.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/505#issuecomment-163682342
