emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC M


From: Kévin Le Gouguec
Subject: Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode
Date: Wed, 03 Jul 2019 20:25:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

João Távora <address@hidden> writes:

>> can you suggest some other mechanism by
>> which CC Mode can create the required font-locking?  If you can, and
>> it's workable, we all win.
>
> No, I can't, but I've asked others to chime in. I would personally do it
> (in fact I already do do it) via flymake-mode.

To expand on that a bit…

AFAICT from its documentation, flymake aims to be "a universal
on-the-fly syntax checker for GNU Emacs".  It is distributed as a core
Emacs library, and as an ELPA package requiring Emacs 26.1.

Looking at this situation from afar[1], invalid-syntax highlighting
sounds exactly like the kind of feature that could be implemented as a
flymake backend[2].

(
    Although I guess the question then moves to "How would the
    *backend* implement this feature?" to which I have no answer,
    knowing nothing of either flymake's API or CC mode's
    invalid-syntax detection process.  Abstractly, I guess that would
    imply

    - lifting some fontification code off CC mode since I assume the
      flymake frontend would handle the presentation,

    - keeping the invalid-syntax detection code,

    - marshalling the information it gathers into flymake
      "diagnostics".
)

>From this excerpt of the discussion of bug#36474[3]:

Alan Mackenzie <address@hidden> writes:

>> 4. Someone reinvents electric-pair-mode in cc-model.el.
>> Let's not do this.
>
> No, let's not do that!  :-)

… I understand that it is a shared principle that there is no
intrinsic value to CC mode implementing features that another library
already provides[4], as that complicates maintenance.


Anyway, this was my very abstract reading of the situation; if I knew
the actual code better, I could probably come up with a truckload of
reasons why *as things stand now*, tearing the highlighting feature
apart and banging on it until it fits flymake's API is not the path of
least resistance.

Therefore, feel free to disregard.


[1] "Long-time-user-long-time-lurker-no-contribution-to-speak-of"-kind
    of afar.

[2] Quoting (flymake) Backend functions:

    >    A backend’s responsibility is to diagnose the contents of a
    > buffer for problems, registering the problem’s positions, type,
    > and summary description.  This information is collected in the
    > form of diagnostic objects created by the function
    > ‘flymake-make-diagnostic’ (*note Flymake utility functions), and
    > then handed over to Flymake, which proceeds to annotate the
    > buffer.

[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36474#8

[4] Although in this particular case, CC mode strives to support Emacs ≥
    24.5, so depending on flymake would limit the feature to Emacs ≥
    26.1.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]