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

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

>> Any mode where you've found bad interactions?
>
> Only in two modes so far:
>
> 1. in emacs-lisp-mode sometimes the inner part of a large expression
> gets to the beginning of the line, then trying to indent it with TAB
> hides the remaining part.  A workaround is to type SPC before indenting
> with TAB.
>
> 2. in diff-mode TAB on a diff header line used to navigate to the next hunk
> with 'diff-hunk-next', now it hides the next hunk.  A workaround is to
> move point to the next line before typing TAB to go to the next hunk.
>
> Are these a possible reasons that would prevent enabling cycling
> in outline-minor-mode by default?

Until we resolve them?  Sounds like it, yes.

[ 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`.  ]

>>> 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.

>> 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`.

>> 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.
> It seems only some very high-level map like overriding-terminal-local-map
> could handle this generally.

That'd only be necessary as a temporary measure until modes learn not to
bind TAB to their own command but to use `tab-dwim-functions` instead.


        Stefan