emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with co


From: Dmitry Gutov
Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls
Date: Fri, 1 Dec 2017 20:50:02 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0

On 12/1/17 7:51 PM, Stefan Monnier wrote:
(defvar prog-widen-function #'widen)
(defun prog-widen () (funcall prog-widen-function))
I don't know if we need that in the common API, but individual packages can
define such shims if they find that convenient.

If we don't add such a thing in the common API, how could individual
packages know the boundary of the current chunk without adding
MMM-specific hacks?

The idea for multi-mode packages has always been to make do without making the major modes actually aware of hunk boundaries.

And the snippet of code won't make them aware either, since the chunk boundaries are conveyed via narrowing only in particular dynamic contexts, such as when indent-line-functions is called.

Adding other means too might make sense, but that's expanding the scope of the current proposal. I'd rather make it small and try to get it into Emacs 26.

(defvar cc-mode-inside-indent-line nil)
(defun cc-mode-maybe-widen ()
   ;; You can also throw in an Emacs version check here,
   ;; for good measure.
   (unless cc-mode-inside-indent-line (widen)))
And then the "low-level primitives" can call cc-mode-maybe-widen.

But just `widen` will do thew wrong thing (it'll widen too much) when
we're inside an MMM chunk.

Yes, so CC Mode primitives all should call cc-mode-maybe-widen. Having them call prog-widen vs widen is very much the same difference.

Having it as a function means you don't have to compute the value of
prog-first-column every time to "enter" a chunk, but instead we only
compute it if/when the submode decides it needs to know what is the
value of prog-first-column.

You probably mean adding a variable prog-first-column-function, then?

Or will we expect multi-mode packages to simply advise the prog-first-column function? I'm fine with that.

And when else will we need this value?

Here are some examples I can think of:
- auto-fill-mode may like to compute the hypothetical indentation that
   would result from inserting a newline somewhere (and do that before
   touching the buffer).

Won't it need to call indent-line-function to find out how much the next line should be indented?

- some package may like to highlight lines which aren't currently
   indented right (so, it won't call indent-according-to-mode, but
   it will need to compute the "desired" indentation).

This example will *definitely* need to call indent-line-function.

And both of them should be solved by exchanging indent-line-function for (non-mutating) line-intentation-function. But that's a change for another day.

I'm sure there can be other cases.

I'm sure there can be. A complete proposal to let the modes know chunk boundaries, etc, has yet to be finalized, however. And just having font-lock and indentation work reliably in multi-mode contexts will be a significant win.



reply via email to

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