Hi,

The "spaces" inside Comments or Compiler Directives are not the correct color compared to "spaces" inside code. So when you set the foreground color of Space characters, that color is not applied inside Comments or Compiler Directives. Thus making things like Comments especially hard to read.

See the attached image.

Is there a specific reason this is done, or can I add this as a bug / feature request to Mantis?

Regards,
- Graeme -

No specific reason.
Simply matter of priority in which things are applied.

Currently the space inside a comment is seen as a comment, therefore treated as comment, which is a point of view.
I agree, for comments this is not very useful.

what about spaces in strings?
In strings, I could see people wanting there spaces to be 'string", (a string of only spaces for example....)

I probably fix it for comment, but comments only.

please comment on it if you like (pun intended)

ah well, yes, it needs the scanner to break comments up into several tokens....

I will have to see about how soon I get to do that.

I only want the scanner to do that if the result is needed. otherwise the structural scan suffers from slow down

Martin wrote

what about spaces in strings?

They suffer the same problem. This would be a "nice to have" - see comment below.

I probably fix it for comment, but comments only.

Comments have far more words in the text that strings in my code. So I'll be perfectly happy with having only comments fixed for now.

Regards,
- Graeme -

Martin wrote

I only want the scanner to do that if the result is needed. otherwise the structural scan suffers from slow down

I guess one could look at the Editor Settings (is "show special characters" enabled) and if so, is "Text foreground color" non-default, then only apply the tokens to comments. Just a guess. :)

Regards,
- Graeme -

No I meant something else. Though hopefully, I might be able to add that soon.

The highlighter scan for 2 reasons. using the same scan engine, as it is a lot of work to write/maintain it, and 99% makes no big diff)

1) structure (e.g for folds, but also where a comment ends, so that lines further down are updated)
This must be done, everytime the text changes (unless, the editor is locked, and no paint events will be happening)
If the text changes, then fold gutter will update and also text 10 lines after the change may change in color (eg. comment nesting level reduced)

However, in this scan only internal structures are updated. So it doesn't matter if a comment contains a space. It also doesn't matter if a word is keyword, unless the keyword changes structure. ("begin"/"var" change structure / "if"/"then" do not change structure)

2) scanning current line for painting.
this requires to break down the line, for each color/attribute change

---
So in structure scan, if in a comment, the scanner only needs to look for the end of comment. much easier.

Btw, while I agree, that spaces as spaces even in comments is probably more useful, it is not always the case.

If someone setting to highlight comment or string is by underlining, then a continuous underline should be expected.

Martin wrote

If someone setting to highlight comment or string is by underlining, then a continuous underline should be expected.

I guess. :)

I must add, I really like the look of "Bold+Italic" spaces. ;-)

Regards,
- Graeme -

If I understand this right, it would make comment background color stop working?

-Fl?vio

All a question of using the right font ;-p

good point

Martin wrote

> If I understand this right, it would make comment background color stop working? > good point

Umm... then what if the special characters is always rendered using the same foreground color as setup for Comments - just a bit darker or light than the original color.

Attached are a few screenshots and a demo program showing what I mean.

Note the "dots" (spaces) inside Comments are darker or lighter shade of the original color. The normal Spaces foreground color is a completely separate color.

From the demo program, here is the code I used to calculate the Dark and

Light color based on the Original color value.

----8<-------------8<-------------8<-------------8<-------------8<----
function Dark(Col: TfpgColor; Percent: Byte): TfpgColor;
var
  lColor: TFPColor;
begin
  lColor.Red := fpgGetRed(Col);
  lColor.Green := fpgGetGreen(Col);
  lColor.Blue := fpgGetBlue(Col);
  lColor.Red := Round(lColor.Red*Percent/100);
  lColor.Green := Round(lColor.Green*Percent/100);
  lColor.Blue := Round(lColor.Blue*Percent/100);
  Result := FPColorTofpgColor(lColor);
end;
function Light(Col: TfpgColor; Percent: Byte): TfpgColor;
var
  lColor: TFPColor;
begin
  lColor.Red := fpgGetRed(Col);
  lColor.Green := fpgGetGreen(Col);
  lColor.Blue := fpgGetBlue(Col);
  lColor.Red := Round(lColor.Red*Percent/100) + Round(255 -
Percent/100*255);
  lColor.Green := Round(lColor.Green*Percent/100) + Round(255 -
Percent/100*255);
  lColor.Blue := Round(lColor.Blue*Percent/100) + Round(255 -
Percent/100*255);
  Result := FPColorTofpgColor(lColor);
end;
----8<-------------8<-------------8<-------------8<-------------8<----

Regards,
- Graeme -

I know the problem. I used to use special-char-dots, but comments are not readable... In normal source, i would have space to be a very light grey

There are various solutions (some may be of use for other stuff too)

- the cheap: new "comment-space" color (not my preference)

1) add a alpha channel:
- specify: foreground="no color", alpha=70%
- result: the "default" color will faded with 70% background "default" = "Default Text", "comment" or "string"
depending on context

- specify: foreground="green color", alpha=70%
- result: the green will be mixed with the "default" (70% default 30% green)

2) add a layer-priority on each setting
e.g the setting with the highest layer will override others. so currently layers are
space = 1
comment = 2

---
I do like 1, for the problem at hand, spaces in comment may still be blue-ish (or whatever your setting, but faded to background

the 2nd solution may be more useful, for things like how to mix "syncro-edit-active-area-color with current-selection. But I would not necessarily specify the layer on the colors => that would be confusing
- star a syncro edit (start mid-line) => when active the area that was selected, is highlighted by some background color
- select a block that start before, and end inside tha above area => the are start can no longer be seen
feature 2 alone does not solve this => but there are many other such conflicts...

Martin wrote

--- I do like 1, for the problem at hand, spaces in comment may still be blue-ish (or whatever your setting, but faded to background

+1

I like your option (1) as well.

Comments will still look like comments - unlike my color scheme where comments are green, but Backgound and Spaces are block or dark grey.

Regards,
- Graeme -

Is there some "special chars"

Is there a SynAttribute for "special chars"? BTW in SynEdit I had a long-live TO-DO to allow only showing Tab chars (and maybe linebreaks) ;-)

-Fl?vio

eoShowSpecialChars in SynEdit.Options ?

yea, selecting which special chars would be nice too

I meant a "SynHighlighter.SpecialCharsAttri".

yea, selecting which special chars would be nice too --

Yeah :-)
If you remember, to extract and refactor the SynEdit Drawer is in the end of my TODO list ;-)

-Fl?vio

No, currently that is only space and tab => so they use the color for whitespace

But it is an idea... Whitespace not a real highlighter issue, a whitespace s not defined by the kind of highlight

It could be done as a TSynEditMarkup. (which could still enquire with the highlighter, is a token type allows for whitespace at all. => a shell highlighter, might return foo\ bar as one word, and that should not be whitespace detected....

But that might require further work, before it can move... It would simplify the scanning issue...

Martin wrote

> I probably fix it for comment, but comments only.

Comments should stay comments. Space in a commect is not the same as a space in other parts of code.

If I were you I would not implement only missing thing for comments is a spell checker.

Even if you intend to implement a highlight for spaces in comments it must differ from the highlight for spaces in code.

Best regards,
Paul Ishenin.

Yes, as already figured, a (for example) continues underline (comment/string) must not be broken by spaces.

the problem to be solved (which I experienced myself) are "show special chars".

I myself used (past tense) to have that on all the time, for #9 detection. But then every space is a dot. So I set the space foreground color, near the background, and all the special chars are faded out. Only in comments and strings, it looks like hell.

For me personally it might already be solved by show #9 as special char only. (though I actually liked the spaces too)

My current idea is to make the color (forground) alpha adjustable. Doing so, I can very easily, either:
- add an option to apply it only to code-spaces, or top all-spaces (checkbox)
- add a 2nd color attribute for all -none-code-spaces (though having 2 space colors, well might seem strange)

--------
In order to get the best decision, it would be good to understand as much about the different forms of usage that people have for the current implementation.

So if you can:
- how to you currently use it
colors and attibutes of spcace/comment/string
- how might it have affected you?

I too wanted to remove the "dot" for spaces from the synedit code [because string literals and comments are hard to read], so that only tab characters are shown. While having "show special character" enabled, I couldn't figure out what is a real dot in a string literal and what is a "fake show special chars dot" in a string literal. See attached image.

From the image, it is impossible to say if that string literal really

contains a utf-8 dot character, or if it is just a fake dot (space indicator).

I have a look at a few other editors that show such special characters too. Most of them simply paint the "fake space dot" in specified color, even in string literals (that may have a different color). See attached image of EditPad Pro

What EditPad Pro does makes it clear that the "greyed dot" is a space, and not a utf-8 dot character in the string literal. Even comments are easy to read. This seems like a easier solution to the problem than the "blended alpha channel color text", but it is obviously up to you what you want to implement.

Regards,
- Graeme -

             if (c = #32) and Special then begin
               // #194#183 looks like .
               Dest[DestPos-1] := #194;
               Dest[DestPos]   := #183;
               inc(DestPos);
             end;

Is the dot.

just delete the block, with no replacement. (the space is already copied, the block overwrites the space)

Martin wrote

just delete the block, with no replacement. (the space is already copied, the block overwrites the space)

Awesome, thanks for the tip.

Regards,
- Graeme -

For now I went for the cheapest options.
I implemented a "visualized special char" color/attribute settng

It works highlighter independent, and acts on all space/tabs (if they are visualized). The default is not to modify them.

Now you can set the foreground color of all of them to a new value (sorry no alpha yet). So you got a black background, you set a dark grey.

Only issue: if you have different background colors for comment, string, normal-text => then you still have only one "space" foreground color for all of them. You can override the background too => but that probably would not look that nice.

You can set frames, but they will act as "one per group of whitespace". so you can not frame each tab separately.