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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> This is very welcome functionality (and the highlighting as well).
>> 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.
>
> I'm fine with removing these modes after analyzing more use cases.

BTW, I'm writing under the assumption that we'd want to eventually have
both of those vars default to t.

>> IOW, I wonder if there are many use cases where users will want to have
>> some `outline-minor-mode` buffers with cycling and others without.
> Here's is a list of use cases where I tried to use outline-minor-mode
> with cycling, and somewhere also with highlighting.

Any mode where you've found bad interactions?

> 3. (add-hook 'emacs-lisp-mode-hook 'outline-cycle-minor-mode)
>    without outline highlighting to not overwrite major mode faces

In which way did the highlighting get in the way?

> But none of them require to disable cycling.  I don't know where
> outline-minor-mode without cycling would be needed.  Maybe in
> external packages that implement own cycling in outline-minor-mode
> like in https://debbugs.gnu.org/41198#99

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.


        Stefan