emacs-devel
[Top][All Lists]
Advanced

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

Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Repla


From: Dmitry Gutov
Subject: Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls
Date: Mon, 11 Dec 2017 01:30:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0

On 12/9/17 12:47 PM, Eli Zaretskii wrote:

You explained that you consider the design and implementation of
prog-indentation-context unnecessarily complex, and that a simpler
design and implementation would be more elegant, given the current
practices in related modes.  You have _not_ explained why keeping the
prog-indentation-context stuff would prevent us from supporting MMM
and similar features as easily as under your proposed changes.

I'm honestly might be forgetting some things, given the brain-numbing effects of discussions like this, but:

- We need to expand the scope of use of all elements of prog-indentation-context but the first to other facilities as well, such as font-lock, beginning-of-defun-function, etc, at which point the name of the variable kind of ceases to make sense.

Out of all these, font-lock is the most apparent to the user, and thus, arguably, the most important. It is, luckily, not an issue in most major modes, but it *is* an issue in CC Mode, which you said you wanted to see supported.

- PREVIOUS-CHUNKS, given how it's permissively documented now, will likely prevent some useful caching mechanisms inside major modes that will decide to use it (in particular the first option will, "A string containing text"). I also fail to see how one would write support for it without having to program two fairly different code paths.

- In case the discussion about moving 'widen' calls to indent-for-tab-command and indent-according-to-mode concludes affirmatively, we won't be able to use prog-widen there because prog-indentation-context gets set "later".

This issue can probably be avoided by dropping the backing variable and moving to a similar-but-different design with hooks like prog-first-column-function, prog-current-chunk-function, etc, but these details still need to be finalized, and for that I'm waiting for Alan's feedback on adapting CC Mode to MMM.

- Then, we'll go onto solving the less well-examined issues with our designer hands tied more strongly than they could have been, because we've committed to one particular API, one that's harder to smoothly migrate over from.

Next, WHAT HAPPENS IF WE SUPPORT PROG-INDENTATION-CONTEXT PROPERLY:

- All the major modes will have to be adapted to use prog-widen in indentation code, and maybe some other places they use 'widen' at now. This, in turn, will break their uses in mmm-mode, polymode, and whatever other MMM packages are out there (including mhtml-mode, but it's easy to fix).

- Thus, MMM frameworks will need to be updated, changing over from the current practice. Compatibility shims will need to be added in them, to work with both older and new Emacs.

So if you were worried that removing prog-indentation-context would cause inconvenience to antlr-mode (its last released version which jumped the gun with supporting prog-indentation-context), properly supporting prog-indentation-context will cause more breakage overall, in said MMM frameworks. Until they all get updated and all users install the new versions, by various means those updates are delivered.



reply via email to

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