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

[Juri Linkov]

> [ As for how to resolve it (in terms of behavior rather than in terms
>   of code), I think the cycling should only kick after trying
>   indentation and the indentation function did not change the buffer.
>   This is the kind of refinement in behavior which can't be obtained
>   just by key bindings but is (barely) obtainable via `add-function`.  ]

This fallback-on-no-op logic works for indentation, but not for e.g.
diff-hunk-next (works only at the last hunk where TAB is no-op).

Another idea is to put the cycling keymap only at the beginning of the
outline heading line.  Then at the beginning of the line TAB will cycle,
while on the rest of the line TAB will fall back to the default binding
to indent/navigate etc.

>>>> 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?
>> Actually, I discovered only now that outline faces with
>> outline-minor-mode-highlight don't override major mode faces.
>
> So at least it currently doesn't get in the way ;-)
> More seriously: it's because you've put `append` in the LAXMATCH part
> rather than the OVERRIDE part of the font-lock-keywords rule.

Ah, this explains everything.  Now I tried to put it in the OVERRIDE part,
and the result is angry fruit salad.

>>> 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 problem is that too many commands bound to TAB need to adapt
>> this special handling: indent-for-tab-command, diff-hunk-next,
>> compilation-next-error, forward-button, etc. etc.
>
> And I'm saying we should reduce this to a single command (`tab-dwim`)
> and then instead of binding TAB modes should `add-function` to
> `tab-dwim-function`.

Adding font-lock faces on heading lines was necessary anyway, so currently
it was easier to add a local cycling keymap to the same lines as well.

But binding TAB globally to a general tab-dwim command, and allowing
modes to set a buffer-local tab-dwim-function could work as well.