Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings

[Daniele Nicolodi <daniele@grinta.net>]

On 03/03/2021 22:44, Stefan Monnier wrote:
>>> This is very welcome functionality (and the highlighting as well).

Having implemented it myself [1], in what seems like a much less elegant
way at a quick lock at the code, I fully agree.

[1] https://github.com/beancount/beancount-mode/blob/main/beancount.el#L922

>>> I wonder if we really need the new minor modes, tho, instead of just
>>> sticking to the new `outline-minor-mode-cycle` and
>>> `outline-minor-mode-highlight` variables (which we could make into
>>> `defcustom`s).
>>
>> One example (mostly for demonstration purposes) currently is
>> in etc/compilation.txt. whose Local Variables contains just:
>>
>>   ;;; eval: (outline-cycle-highlight-minor-mode)
>>
>> Initially I implemented this only with variables and without modes
>> like you suggested:
>>
>>   ;;; outline-minor-mode-cycle: t
>>   ;;; outline-minor-mode-highlight: t
>>   ;;; eval: (outline-minor-mode 1)
>>
>> But then thought that maybe with a mode would be more concise and convenient.

Can't you add setting the variables to the minor-mode hooks?

I haven't tried your code, but there are occasions in which
outline-minor-mode is used to section the buffer on syntactic elements
that are already fontified (on function declarations, for example). What
does happen then when outline-minor-mode-highlight is t? I think these
would be cases in which outline-minor-mode-highlight nil would be better.

> FWIW, I think the only really good way to solve this problem is to
> replace `indent-for-tab-command` with a new command (call it
> `tab-dwim`?)  which can be more finely configured by major and minor
> modes.  E.g.  by making it call `tab-dwim-function` on which modes can
> `add-function` at will (and at various depths so they can control
> whether it should take precedence or not over the "TAB causes
> indentation" or "TAB causes completion", ...).>
> The mechanism of priorities of keymaps coupled with "fallthrough"
> (either via the "menu-item + filter" trick or via some explicitly
> looking up the keymaps and calling the next command) isn't fine-grained
> enough to deal with the amount of overloading that people want to use on
> that poor TAB key.

That would be nice to have, indeed.

Cheers,
Dan