emacs-devel
[Top][All Lists]
Advanced

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

Re: emacs rendering comparisson between emacs23 and emacs26.3


From: Stefan Monnier
Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Thu, 16 Apr 2020 09:52:25 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>   ;; Rather than a -functions hook, this is a -function because it's easier
>   ;; to do a single scan than several scans: with multiple scans, one cannot
[...]
> From my point of view, "multiple scans" are _much_ easier.

Obviously it's a matter of opinion.

Luckily, you have a Turing complete language at hand, so
`syntax-propertize-function` does not *impose* a single scan, it just
encourages it (especially with `syntax-propertize-rules`).

Your `syntax-propertize-function` can definitely use multiple scans if
it wants (and it's simply up to you to be careful about the fact that
until the last scan, `syntax-ppss` (and `parse-partial-sexp`) will
obviously not give the "final" answer, and if you use `syntax-ppss`
there, it's then your responsability to manually flush its cache with
`syntax-ppss-flush-cache`).

Really, you can use `syntax-propertize-function` with CC-mode without
significant changes to the code (i.e. reusing the code mostly unchanged
for the actual work).  The basic idea is to have CC-mode pretend that
the buffer only extends as far as `syntax-propertize--done`:

- when opening the file, pretend it's empty (i.e. do the initial scan
  as if `point-max` were equal to `point-min`).
- when `syntax-propertize-function` is called with arguments BEG and END,
  treat it as if the old code was faced with the following sequence of
  operations:
  1- delete all the text between BEG and `point-max`.
  2- insert at the end of file the new text found between BEG and END.

Clearly, the old code is supposed to handle correctly all three elements
(an empty file, deletion of text at EOB, and insertion of text at EOB),
so the old code will be able to handle those requests correctly without
any need for a redesign (you just have to "hide" the rest of the buffer
from the corresponding code, which might be doable with narrowing).

Of course the code of CC-mode is designed to handle many more operations
than deletion and insertion at EOB, so after that first step you could
try and adjust the code accordingly, but that can only make it simpler,
and is not necessary for a first cut.


        Stefan




reply via email to

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