KSyntaxHighlighting meta data

Dr.-Ing. Christoph Cullmann cullmann at absint.com
Sat Aug 4 16:56:52 BST 2018


Hi,

> On Thursday, 2 August 2018 11:31:59 CEST Dominik Haumann wrote:
>> > I'm not too worried about keeping API compatibility for extra getters,
>> > this
>> > all exists since many years and has proven to be stable.
>> 
>> Ok.
>> 
>> > I am however more
>> > worried about aspects of the syntax files becoming part of the de-facto
>> > API
>> > that you might not expect to be "API". We have that with the keyword
>> > access
>> > now for example, which exposes internal names used in the syntax files.
>> 
>> True, I haven't thought about it this way. Should we remove the
>> keywordList() getters again? Maybe we can come up with something better at
>> Akademy.
>> 
>> CC: Alexander, who requested this feature
> 
> I don't think we need to revert that, there's indeed valid use-cases for it,
> like the one Alexander has, and IIRC the Sieve editor in KDE PIM also
> duplicates the keyword list for auto-completion. And I don't really see a way
> to enable that without accessing the lists by name.
> 
> It's just something to keep in mind before we go further down that route, and
> possible to mention in the docs for the XML files, so we don't rename stuff
> there without thinking about the implications.
I ported a bit more stuff over.

Normal highlighting and folding seems to work fine.
I still get random colorization, but I assume that is the "broken" handling of the
format => attribute mapping I do atm.
The highlighting and folding info itself looks sane, I think.

I removed the exposure of the internal contexts in our internal API.

I added "FIXME-SYNTAX" markers to the places outside of katehighlight.cpp that still need
fixes.

Three functions we will need to implement are:

    /**
     * Get all keywords valid for the given cursor position.
     * @param doc document to use
     * @param cursor cursor position in the given document
     * @return all keywords valid at that location
     */
    QStringList keywordsForLocation(KTextEditor::DocumentPrivate* doc, const KTextEditor::Cursor& cursor);

    /**
     * Is spellchecking required for the tiven cursor position?
     * @param doc document to use
     * @param cursor cursor position in the given document
     * @return spell checking required?
     */
    bool spellCheckingRequiredForLocation(KTextEditor::DocumentPrivate* doc, const KTextEditor::Cursor& cursor);

    /**
     * Get highlighting mode for the given cursor position.
     * @param doc document to use
     * @param cursor cursor position in the given document
     * @return mode valid at that location
     */
    QString higlightingModeForLocation(KTextEditor::DocumentPrivate* doc, const KTextEditor::Cursor& cursor);

For them, we would need some more interfacing to the syntax-highlighting framework,
I assume. Before, they did compute the context up to the given column and then collect the info from there.

For spellCheckingRequiredForLocation it could be good enough to just look at the property of the format there,
that can already be implemented.

For the other two, more interfacing is needed (if one doesn't try to do higlightingModeForLocation only with the format, too)

I map already all formats to their definitions, which allows other things to work.

For the meta info, one still needs to fill:

    class HighlightPropertyBag
    {
    public:
        QString singleLineCommentMarker;
        QString multiLineCommentStart;
        QString multiLineCommentEnd;
        QString multiLineRegion;
        CSLPos  singleLineCommentPosition;
        QString deliminator;
        QString wordWrapDeliminator;
        QLinkedList<QRegularExpression> emptyLines;
        QHash<QString, QChar> characterEncodings;
        KatePrefixStore characterEncodingsPrefixStore;
        QHash<QChar, QString> reverseCharacterEncodings;
        int encodedCharactersInsertionPolicy;
    };

Beside emptyLines which is just foldingIgnoreList(), the other things that come from the XML files
would still need some accessor in the framework.

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234


More information about the KWrite-Devel mailing list