#872 Enable Scintilla.dll to load external lexers

Won't_Implement
closed
Neil Hodgson
Scintilla (356)
2
2012-03-09
2011-12-09
Markus Nißl
No

To my understanding, on Windows, Scintilla.dll only includes the editing component whereas SciLexer.dll includes a bunch of lexers.

If you use Scintilla for programming exclusively in your own programming language, there is no need to load SciLexer.dll (as you do not take advantage of any of the bundled lexers). Though, Scintilla.dll is not enable to load an external lexer through SCI_LOADLEXERLIBRARY and SCI_SETLEXERLANGUAGE as it is possible with SciLexer.dll.

I'm in favour of including this possibility into the basic editing component.

Discussion

  • Neil Hodgson
    Neil Hodgson
    2011-12-09

    There are already many ways of including lexers with products and I am not in favour of adding more. Applications may define their own lexers by using SCLEX_CONTAINER. They may also set up their own version of SciLexer that includes their set of lexers.

     
  • Neil Hodgson
    Neil Hodgson
    2011-12-09

    • assigned_to: nobody --> nyamatongwe
    • priority: 5 --> 2
    • milestone: --> Won't_Implement
     
  • Markus Nißl
    Markus Nißl
    2011-12-12

    As I see things now, I guess we started out wrong one year ago when we dropped our old editing component and integrated Scintilla.

    By reading the documentation, we got the idea that the best way to support syntax highlighting for your own programming language is to write a lexer by implementing the ILexer interface. We put it into one of our DLLs and accessed it through SCI_LOADLEXERLIBRARY and SCI_SETLEXERLANGUAGE.

    We then also got to see that we cannot take advantage of some Scintilla features as the only way to access the document was through the IDocument interface (e.g. you have no access to markers).

    So, would it be better to integrate our lexer in a class that is not derived from ILexer and delegate calls from SCN_STYLENEEDED to an instance of this class instead? Then it would be sufficient to ship and load Scintilla.dll.

    I'm not fond of having to maintain our own version of Scintilla, would it be to strip out bundled lexers from SciLexer.dll or to enable Scintilla.dll to load external lexers. We would like to ship the official version which means less work and less error proneness.

     
  • Neil Hodgson
    Neil Hodgson
    2011-12-15

    Lexers are components with limited purposes and so deliberately limited APIs. If you want to perform actions not supported by those APIs these should be done in your application.

     
  • The main problem as I see it is the fact that Catalogue.cxx contains both the mechanics of loading lexers and reference to lexers themselves, through Scintilla_LinkLexers(..)

    Spliting that file would be of great benefit for those who want to do a custom build, having scintilla and its lexers separated. This won't affect the current way Scintilla is build -it's only about adding a new file to the build.

    I have currently modified the LexGen.py to output the Scintilla_LinkLexers() in another file, and I compile Scintilla in scintilla.dll; I compile the lexers in another dll, importing everything they need from the main dll. This way I can split each lexer in its own dll, each of them, when loaded, will import its needed classes from the mail dll.

     
  • Neil Hodgson
    Neil Hodgson
    2012-02-10

    Still not seeing any advantage over building a version of SciLexer.DLL with no lexers.

     
  • So what's the point then in being able to load additional lexers if those lexers need be statically linked with Scintilla? That means having two instances of scintilla loaded, one for each lexer library.

    The problem here is that the lexers cannot be separated in another dll - they need be linked to scintilla. But I see there is code for Scintiila to be able to load additional lexers library.

     
  • Neil Hodgson
    Neil Hodgson
    2012-02-14

    Lexers do not have to be statically lined with Scintilla.

     
  • Neil Hodgson
    Neil Hodgson
    2012-03-09

    • status: open --> closed