Make highlighting less fragile to changes

[oblitum]

Just so we both don't forget about this experiment:

On Sat, Mar 28, 2015 at 10:35:46PM -0700, Francisco Lopes wrote: [1]@jeaye yeap, I'm planning to use it since I find it much better. The sole missing thing I dislike about it is trying to handle colorscheme instability. As you already know it's quite broken while typing, if there was a way to restrict this, it would be perfect. I was thinking of alternatives myself, like, trying to refresh highlighting in key situations solely, like when going to normal mode, or when moving cursor line, or refreshing just when there're no errors in the TU, I don't know in truth =)

Seems reasonable. How about an option for realtime (incomplete) updating which defaults to on? It seems like it'd be simple enough to guard the functionality between two cases:

1) Incomplete highlighting is enabled 2) There was a successful compilation

[jeaye]

Just thinking about how this could work... making color_coded only highlight once a compilation was 100% succcessful isn't an issue. The issues come up as side effects to doing this. An instance where it might work well:

• (normal mode) You have some code which successfully compiles and is highlighted
• (insert mode) You add a new line and start typing new code
• The highlighting isn't applied until your new code compiles properly

Even this can have some issues, but let's say that works well. An instance where this doesn't work well might be:

• (normal mode) Given some code that is highlighted
• (insert mode) Change a line in the code and start typing something else
• Since the highlighting hasn't been updated, the new code will use the old code's highlighting
  • This will look worse than realtime highlighting

There are more cases where this can go wrong than where it will be nice, I think. A broader solution might just be to have this option disable color_coded while in insert mode altogether. As soon as you exit insert mode, it applies the latest highlighting it can. Any edits in normal mode (dd, for example) will highlight as soon as possible, like they do now. The issue with this is that highlighting is still handy in insert mode.

[oblitum]

A broader solution might just be to have this option disable color_coded while in insert mode altogether. As soon as you exit insert mode, it applies the latest highlighting it can. Any edits in normal mode (dd, for example) will highlight as soon as possible, like they do now. The issue with this is that highlighting is still handy in insert mode.

This may be a good approach (at last for me since I'm always back and forth between normal and insert mode).

[oblitum]

You know what? Another thing regarding the bad impression of instant highlighting is that it's not happening so instantly... I'm not sure this is solvable but, when you enter a new line by pressing o, all the lines that comes after this new line get the colors of the previous coloring. I mean, line N get the highlighting that was in line N-1, so it looks weird briefly for all the lines following a new one until I start typing in this new line or something.

[oblitum]

Maybe async neovim would solve all of this...

[oblitum]

In sum, the problem is, repositioned text ideally should get its highlighting repositioned too, at the time it gets repositioned, not much later.

[oblitum]

Also, I'm sorry, the way I formerly commented about solving this issue is the result of a misunderstanding on how you implement highlighting. I thought that by having the highlighting internal elements not updated so instantly, I wouldn't get updated highlighting for new stuff but the remaining code would still get in sync with its previous highlighting. I see now it doesn't seem to work this way, less frequent updates would turn matters worse since remaining text woudn't have highlighting in sync, which I thought it would.