New Omni Highlighter and 189 ini-based new highlighters

[pyscripter]

Thanks to a significant contribution of Jan Fiala (@JaFi-cz) a new powerful highlighter has been added named Omni (for omnipotent). It is a massive extension of the General highlighter and importantly, it allows the definition of highlighter in ini files. A component editor has been added that allows the configuration of Omni highlighters both at design and run time.

Jan also contributed 189 highlighter definitions (ini files) from his PSPad editor. It includes highlighters for PowerShell, Go and many others that were missing from SynEdit. They can be found in this folder.

A component editor has also been added that can be used both at design and run time.

• Invoking the component editor:

• The component editor after loading the PowerShell settings:

You can load and save highlighter settings.

• Sample PowerShell script:

Notice that code-folding is readily available for curly-bracket languages.

• Structure highlighting is also readily available for such languages:

Forum Announcement

[vincentparrett]

This is awesome, will defintely be using it!

[MShark67]

Wow! I'm adding this to my test editor, and I have a few notes and questions. I use the GetPlaceableHighlighters call to setup a highlighter menu and I notice the following:

1. Omni has a friendlyname of "General", I think it should be "Omni" or such?
2. There's a highlighter called "General" (TSynGeneralSyn). What is this one for?
3. The TSynMultiSyn highlighter doesn't register as placeable. Is that because it needs extra configuration to work? I haven't ever tried it.

Thanks, as always!

[pyscripter]

I am afraid the code for setting up a highlighter menu would need to be adapted. The problem is that GetLanguageName is a class method. TSynOmniSyn can represent several languages and it defines a property LangName, which should be used in the Highlighter menu. LangName is set when you load an ini file or you set it up manually.

So for SynOmniHighlighterws GetLanguageName should be ignored and LangName used instead.

You could have many instances of SynOmniHighlighter each representing a different language. I am open to suggestions on how the code base could facilitate this. Probably SynOmniSyn should not be registered as placeable.

I use uHighlighterProcs to setup a highlighter menu. They can be easily adapted to cover SynOmniSyn instances.

procedure GetHighlighters(AOwner: TComponent; AHighlighters: TStringList;
  AppendToList: Boolean);
var
  I: Integer;
  Highlighter: TSynCustomHighlighter;
begin
  if Assigned(AOwner) and Assigned(AHighlighters) then begin
    if not AppendToList then
      AHighlighters.Clear;
    for I := AOwner.ComponentCount - 1 downto 0 do begin
      if not (AOwner.Components[I] is TSynCustomHighlighter) then
        Continue;
      Highlighter := AOwner.Components[I] as TSynCustomHighlighter;
      // only one highlighter for each language
      if AHighlighters.IndexOf(Highlighter.GetLanguageName) = -1 then
        AHighlighters.AddObject(Highlighter.GetLanguageName, Highlighter);
    end;
    AHighlighters.Sort;
  end;
end;

The above needs to be changed to support Omni highlighers.

[MShark67]

Thanks! I actually don't ever place highlighters on a form or such as I prefer to create them in code (just my own personal preference for non-visual components when I can get away with it.) I can certainly do that "by hand", but the GetPlaceableHighlighters call works well enough for my simple testing stuff. If I end up testing the multi or omni highlighters I'd just add special handling for that. Thanks for the clarifications!

[pyscripter]

I have added Language names for Omni distinct from General.

I have modified the above function to:

procedure GetHighlighters(AOwner: TComponent; AHighlighters: TStringList;
  AppendToList: Boolean);
var
  Comp: TComponent;
  Highlighter: TSynCustomHighlighter;
  LangName: string;
begin
  if Assigned(AOwner) and Assigned(AHighlighters) then begin
    if not AppendToList then
      AHighlighters.Clear;
    for Comp in AOwner do
    begin
      if not (Comp is TSynCustomHighlighter) then
        Continue;
      Highlighter := TSynCustomHighlighter(Comp);
      // Only one highlighter for each language
      // Omni highlighters are a special case
      if Highlighter is TSynOmniSyn then
        LangName := TSynOmniSyn(Highlighter).LangName
      else
        LangName := Highlighter.LanguageName;

      if LangName = '' then
        Continue;

      if AHighlighters.IndexOf(LangName) = -1 then
        AHighlighters.AddObject(LangName, Highlighter);
    end;
    AHighlighters.Sort;
  end;
end;

This function works whether you create the highlighters at run time or design time as long as they are owned by the same data module or form.

[MShark67]

This function works whether you create the highlighters at run time or design time as long as they are owned by the same data module or form.

I actually make my menus before creating any highlighters (again this is just my personal test editor, so it's not always the most polished thing in the world.) I only create the highlighter if I choose it from the menu. This is no hardship btw, I could just hardcode the list after all, but the existing functionality works well enough for what I'm doing.

[pyscripter]

I see. You create the highlighters "on demand".

[JaFi-cz]

I created 10 free slots for user (omni) highlighters. For now it's enough, no user requested additional slots. I create highlighters in code too, include synedit editor, it prevents problems with interface changes. But it's more work than simply place component Jan Fiala