Hi,

I am trying to figure out, what is intended currently, and/or what may be acceptable.

At current the implementation of the Ctrl Mouse Link suggests that out of the RGB values, the bllue value is to be inverted. This works fine on words in normal text (identifiers), which turn from black to blue. Comments just stay blue (instead of getting black), compiler directives just stay red (instead of getting pink (red+blue).

This is because currently CtrlMouseLinks are only re-colored if the word to which the apply is a separate token.

if (fLastCtrlMouseLinkYCurLine) or (nTokenPos+1fLastCtrlMouseLinkX1)

Each identifier is returned as a separate token, even if there are no highlighter changes to the token before/after. So they are highlighted. Blocks or Compiler-Directives are one whole token across all the words contained in them. So they *normally* do not benefit highlighting.

Except of course, if you break them across lines (there must be no leading or trailing spaces)
{$I
unit1.lrs
}
(*
abc
*)
In those examples "unit1.lrs" will turn pink. "abc" will turn black.

On the other Hand if ever an optimizer should bundle other words (like identifiers with the separating dots) into one word, then the current method would fail as well.

Now the question is what is intended or acceptable as future behaviour (because I am moving the code and the token boundary will loose importance, so the inconsistent coloring of directives/blocks will go).

===> But which color should a CtrlMouseLink in a directive/Comment have?

I personally dislike the pink. They could stay red as they do currently (with a blue underline) or the could just turn blue as normal text. And comments could stay blue to?
Maybe the color could even be configured in the Editor Environment ?

Best Regards
Martin

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080715/a7a9bec8/attachment.ksh

The new Markup will handle this, that is why I was asking. Because If I needed to carry the current behaviour, I would need to do a lot of extra steps.

I will most likely let the user decide on coloring via the Editor-Enviroments/Highlighter settings (as for Special-Line or Selection). So if the user set foreground to "default" (clNone) there will only be underlining. Otherwise there is a fixed color.

I am still looking into getting underlining via fontstyle to work reliable.

The new Markup will handle:
- "Highlight all" currently for incremental search, but planed also for normal sarch/replace, or outside search (other occurrences of selected block, or word under cursor)
- Matching Brackets
- Special Lines
- Ctrl-Mouse-Link
- Selected Block
as well as new Markups. (e.g. for code-templates)

All Markups work independent of the Highlighter. They only instruct to keep/alter/override selected color or style information.

Each Markup works similar to a plug-in, so it will be easy to write extra markup-modules. Hopefully I will have the next part of the implementation ready by the end of this week.

As a side effect it also has several fixes:
- Bracket highlight with utf8 chars in line
- Block and special line with Foreground=clNone (just change the Background Color, keep the Foreground according to highlighter); depends on settings. (probably also honour font style)
- Display of selection in column mode, if some lines include tabs
- Paintlines will be simplified. Selected-Block Highlighting happens before the token Accu. So all tokens that are in the selection can be joined in the token-accu

Best Regards
Martin