Codist icon indicating copy to clipboard operation
Codist copied to clipboard

Suggestion: New Syntax Highlight for Region and New Style Option

Open fitdev opened this issue 5 years ago • 8 comments

Right now #region Name and #endregion aree highlighted as preprocessor directive and preprocessor text. It would be nice if there was a way to customize highlight style for the entire line:

  • Perhaps similar to how there is a style for attribute notation, there should be style for "region notation". This way (if necessary) preprocessor directive and text styles may still be applied (just as for the attribute notation Type name, field name, etc. - are all applied as well).
  • General ability to apply certain effects (right now background color really) to the entire line. This is mostly useful for the aforementioned #region directives, but could be useful elsewhere perhaps (type declarations for example).
  • Additional ways to customize a style. For example borders: solid/dashed, border color, border position: top, bottom, left, right. This is a good candidate for a style that could be applied to the entire line.

Thank you.

fitdev avatar Jun 14 '20 17:06 fitdev

I'd been using an extension providing similar functionality before, like this: https://marketplace.visualstudio.com/items?itemName=PaulRogero.RegionHighlights

Is that what your are looking for?

wmjordan avatar Jun 15 '20 03:06 wmjordan

This extension also provides similar functionality (actually it was I who posted the request to them, years before the development of Codist): https://www.codinion.com

wmjordan avatar Jun 15 '20 03:06 wmjordan

Thank you for pointing this out, and I should have mentioned it myself. Yes, I was using it. I turned it off recently as part of my VS performance investigation. Then I thought that it is a tiny extension and is probably not worth having on its own. Whereas, were the same functionality to be included in Codist, it would make Codist even better at syntax highlighting, hence I submitted the new issue.

Also, I fear that having several extensions competing for editor highlighting rules is not a good idea as it may have serious performance issues.

Regardless of #regions specifically, I do think that adding those extra highlight customizations (border, perhaps even an icon, ability to apply it to whole line) may benefit other styles as well.

fitdev avatar Jun 15 '20 06:06 fitdev

Then I thought that it is a tiny extension and is probably not worth having on its own.

Thank you for sharing your thought.

That was exactly what I was thinking when I posted the request of region highlight to Codinion while it was still free 😀 .

Ironically, I no longer feel that types of highlight useful after that was implemented in Codinion. Thus I did not implement it in Codist, even though some part of the functionality (adornments) could be copied from RegionHighlights without big trouble and the other part (syntax parsing powered by Roslyn) was no longer difficult to me any more.

adding those extra highlight customizations (border, perhaps even an icon, ability to apply it to whole line) may benefit other styles

Yep, adding those borders, icons and range specific lines + backgrounds to the editor may benefit other styles. However, those additions would have to be WPF controls (adornments) and somewhat slow the editor down.

wmjordan avatar Jun 15 '20 07:06 wmjordan

even though some part of the functionality (adornments) could be copied from RegionHighlights without big trouble and the other part (syntax parsing powered by Roslyn) was no longer difficult to me any more

Well, if it will be relatively easy to implement, perhaps you can give it a try. Maybe "hide" these advanced settings under a collapsible button in the Highlight Customization UI (if you feel it may negatively affect UI presentation of those options to the users and / or performance), or have an option that controls whether or not such advanced elements are applied at all (so that those who do not use them will have 0 extra cost in terms of performance of the editor).

However, those additions would have to be WPF controls (adornments) and somewhat slow the editor down.

Oh I see. I had no idea about the performance impact they may have. I didn't realize that even borders cannot be implemented without requiring WPF controls. Still, if as you say you can resuse some code from RegionHighlights for this purpose, perhaps you can add this functionality.

And, on a side note... I did not get back to you regarding my VS syntax highlighting performance issues. I am pretty sure at this stage that the sluggish syntax highlighting performance at times in VS is likely to do with VS itself, and a particular project / document I am working on, - nothing to do with Codist. So, I did not report back, but thought I would mention this now.

fitdev avatar Jun 15 '20 07:06 fitdev

Theoretically it is easy to implement, but it does take some time! It is neither challenging nor innovative, thus I will put it at the end of the pending list.

The Chinese interface is already ready.

Now I will investigate the implementation of #67. And the nasty #125.

wmjordan avatar Jun 15 '20 08:06 wmjordan

I did not get back to you regarding my VS syntax highlighting performance issues

It seems that the CPU consumption of VS 2019 was really really weird. Mysterious, unnamed tasks kept running in the background continually, after compilation, and never rested for a second even if I'd already closed the working solution. This never occurred to VS 2017.

wmjordan avatar Jun 19 '20 09:06 wmjordan

That is strange. Most of those, at least in my case had to do with full solution analysis. I changed ti so that only active document is analyzed and most background tasks went away. And in any case those background tasks, at least as far as I could tell, do not affect the performance of the editor. It is the tasks that run on the same thread as the editor like intellisense completion that cause problems for me.

fitdev avatar Jun 19 '20 13:06 fitdev