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

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

[Stefan Monnier]

>     New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings

Thanks, Juri,

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

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.

[ Maybe for highlighting, the interaction with the underlying major
  mode could justify a buffer-local approach, tho I'd be leaning
  towards considering poor interactions as bugs we should fix.  ]


        Stefan

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

[Juri Linkov]

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

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

1. (add-hook 'Man-cooked-hook 'outline-cycle-highlight-minor-mode)
   where manual page sections could be highlighted with outline faces.

2. (add-hook 'diff-mode-hook 'outline-cycle-minor-mode)

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

4. (advice-add 'xref--insert-xrefs :after
            (lambda (&rest _args)
              (setq-local outline-regexp "/")
              (outline-cycle-minor-mode +1)))
   using file names as headings where S-TAB could provide
   an overview of all found files

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

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

[Stefan Monnier]

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

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

[Juri Linkov]

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

I don't know, I could try to use outline-minor-mode-highlight unconditionally
everywhere to check its effect.  It seems that it doesn't put outline faces
on parts already highlighted by major mode font-lock keywords.

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

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?  Or if someone enables
outline-minor-mode then it should be easy for them also to customize
cycling when it's enabled the default?

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

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

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

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

[Stefan Monnier]

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

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.

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

[Stefan Monnier]

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

Indeed, it's no silver bullet.  In the case of `diff-hunk-next` and
`outline-minor-mode-cycle` we really have an irreconcilable
conflict, AFAICT.

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

It might be a good idea to restrict the cycling behavior to the case
where we're at BOL, indeed (of course, it still won't help for
`diff-hunk-next`).

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

;-)


        Stefan

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

[Daniele Nicolodi]

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

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

[Stefan Monnier]

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

I think this can be solved by giving to those "headings" outline levels
which map to "no highlighting".

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

OK, I should push it up my todo list.


        Stefan

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

[Juri Linkov]

>> 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.
>
> I think this can be solved by giving to those "headings" outline levels
> which map to "no highlighting".

Unless outline faces are recycled from outline-1 again
after outline levels reach the last face ;-)

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

[Juri Linkov]

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

It's easier to set them using minor-mode like

  (add-hook 'emacs-lisp-mode-hook 'outline-cycle-highlight-minor-mode)

than using lambda

  (add-hook 'emacs-lisp-mode-hook
    (lambda ()
      (setq-local outline-minor-mode-cycle t)
      (setq-local outline-minor-mode-highlight t)
      (outline-minor-mode 1)))

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

outline-minor-mode-highlight already works surprisingly well,
and doesn't override faces added by major mode.

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

[Daniele Nicolodi]

On 04/03/2021 19:17, Juri Linkov wrote:
>>>> 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?
> 
> It's easier to set them using minor-mode like
> 
>   (add-hook 'emacs-lisp-mode-hook 'outline-cycle-highlight-minor-mode)
> 
> than using lambda
> 
>   (add-hook 'emacs-lisp-mode-hook
>     (lambda ()
>       (setq-local outline-minor-mode-cycle t)
>       (setq-local outline-minor-mode-highlight t)
>       (outline-minor-mode 1)))

That would seem to imply that there should be a minor-mode for every
buffer-local safe variable in Emacs... :-)

>> 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.
> 
> outline-minor-mode-highlight already works surprisingly well,
> and doesn't override faces added by major mode.

Doesn't that mean that it does not apply the faces most of the time? In
almost all my use of outline-mirror mode, the headings are comments in
the current major mode, and almost always are fontified as such by the
major mode.

I should probably try your code. Do you know if it works in Emacs 27?
That would spare me from having to compile Emacs.

Cheers,
Dan

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

[Juri Linkov]

> Doesn't that mean that it does not apply the faces most of the time? In
> almost all my use of outline-mirror mode, the headings are comments in
> the current major mode, and almost always are fontified as such by the
> major mode.

This is what I see: when a line is already fontified e.g. as comments by
the current major mode, then outline-mirror-mode doesn't put outline faces
over it.

> I should probably try your code.

This is not completely my code.  Cycling commands for outlines were recently
implemented by Yuan Fu and Paul W. Rankin in https://debbugs.gnu.org/41198
I only bound these commands to headings in outline-mirror-mode.

> Do you know if it works in Emacs 27?
> That would spare me from having to compile Emacs.

In theory just loading outline.el in Emacs 27 should be enough
to get it to work, but after trying this I see that cycling doesn't
work in Emacs 27.

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

[Daniele Nicolodi]

On 04/03/2021 21:35, Juri Linkov wrote:
>> Doesn't that mean that it does not apply the faces most of the time? In
>> almost all my use of outline-mirror mode, the headings are comments in
>> the current major mode, and almost always are fontified as such by the
>> major mode.
> 
> This is what I see: when a line is already fontified e.g. as comments by
> the current major mode, then outline-mirror-mode doesn't put outline faces
> over it.

It is not as useful as I thought then.

Cheers,
Dan

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

[Juri Linkov]

>>> Doesn't that mean that it does not apply the faces most of the time? In
>>> almost all my use of outline-mirror mode, the headings are comments in
>>> the current major mode, and almost always are fontified as such by the
>>> major mode.
>>
>> This is what I see: when a line is already fontified e.g. as comments by
>> the current major mode, then outline-mirror-mode doesn't put outline faces
>> over it.
>
> It is not as useful as I thought then.

It's easy to override major mode faces, and to add this as an option.
But please elaborate how do you imagine this should look.

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

[Stefan Monnier]

> This is what I see: when a line is already fontified e.g. as comments by
> the current major mode, then outline-mirror-mode doesn't put outline faces
> over it.

That is not quite right: once you fix the laxmatch-vs-override
confusion, your code does put the face on it.  The problem is that by
default those faces only use colors to distinguish the headings level.

FWIW, I think this is a mistake in outline.el: the faces should mostly
change the *height*.  That would interact much better with things like
font-lock-comment-face as well.


        Stefan

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

[Gabriel do Nascimento Ribeiro]

This is a great feature, thank you!  I could replace all my custom elisp
code that handles outline cycle/highlight on my init.el with the new
minor-modes, and everything has been working fine so far.

I think that having only the variables is fine, I can't see any special
need for the minor-modes.

> 4. (advice-add 'xref--insert-xrefs :after
>             (lambda (&rest _args)
>               (setq-local outline-regexp "/")
>               (outline-cycle-minor-mode +1)))
>    using file names as headings where S-TAB could provide
>    an overview of all found files

The use of outline-minor-mode + cycle on xref buffers is one of my main
use cases. However, having to setup the outline-regexp and to add a
defadvice seems a dirty hack.  Should Emacs provide better defaults for
xref and other modes (like Gnus) for an easier integration with
outline-minor-mode ?

As another suggestion, would be nice to add more keybidings, for
example, to navigate between headers. The name 'cycle', however, maybe
not be a good choice in case Emacs offers more keybidings for
outline-minor-mode.

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

[Juri Linkov]

> This is a great feature, thank you!  I could replace all my custom elisp
> code that handles outline cycle/highlight on my init.el with the new
> minor-modes, and everything has been working fine so far.
>
> I think that having only the variables is fine, I can't see any special
> need for the minor-modes.
>
>> 4. (advice-add 'xref--insert-xrefs :after
>>             (lambda (&rest _args)
>>               (setq-local outline-regexp "/")
>>               (outline-cycle-minor-mode +1)))
>>    using file names as headings where S-TAB could provide
>>    an overview of all found files
>
> The use of outline-minor-mode + cycle on xref buffers is one of my main
> use cases. However, having to setup the outline-regexp and to add a
> defadvice seems a dirty hack.  Should Emacs provide better defaults for
> xref and other modes (like Gnus) for an easier integration with
> outline-minor-mode ?

Gnus has own outline-like commands like 'T H' that hides all threads.
But in xref it should be easy to set the outline-regexp by default,
and to add a hook to call when the xref output buffer is ready.

> As another suggestion, would be nice to add more keybidings, for
> example, to navigate between headers.

Maybe bind more org-like bindings in outline-mode-cycle-map,
e.g. ‘C-c C-n’ like ‘org-next-visible-heading’
and ‘C-c C-p’ like ‘org-previous-visible-heading’.

> The name 'cycle', however, maybe not be a good choice in case Emacs
> offers more keybidings for outline-minor-mode.

Indeed, after adding more keybindings it's not only about cycling anymore.

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

[Juri Linkov]

>> This is a great feature, thank you!  I could replace all my custom elisp
>> code that handles outline cycle/highlight on my init.el with the new
>> minor-modes, and everything has been working fine so far.
>>
>> I think that having only the variables is fine, I can't see any special
>> need for the minor-modes.
>>
>>> 4. (advice-add 'xref--insert-xrefs :after
>>>             (lambda (&rest _args)
>>>               (setq-local outline-regexp "/")
>>>               (outline-cycle-minor-mode +1)))
>>>    using file names as headings where S-TAB could provide
>>>    an overview of all found files
>>
>> The use of outline-minor-mode + cycle on xref buffers is one of my main
>> use cases. However, having to setup the outline-regexp and to add a
>> defadvice seems a dirty hack.  Should Emacs provide better defaults for
>> xref and other modes (like Gnus) for an easier integration with
>> outline-minor-mode ?
>
> Gnus has own outline-like commands like 'T H' that hides all threads.
> But in xref it should be easy to set the outline-regexp by default,
> and to add a hook to call when the xref output buffer is ready.

Now this should be added in bug#46992.

>> As another suggestion, would be nice to add more keybidings, for
>> example, to navigate between headers.
>
> Maybe bind more org-like bindings in outline-mode-cycle-map,
> e.g. ‘C-c C-n’ like ‘org-next-visible-heading’
> and ‘C-c C-p’ like ‘org-previous-visible-heading’.

Actually it's easy to customize such keys, e.g.:

(let ((map outline-mode-cycle-map)
      (cmds '(("C-c C-n"  outline-next-visible-heading)
              ("C-c C-p"  outline-previous-visible-heading))))
  (dolist (command cmds)
    (define-key map (kbd (nth 0 command))
      `(menu-item
        "" ,(nth 1 command)
        ;; Only takes effect if point is on a heading.
        :filter ,(lambda (cmd)
                   (when (outline-on-heading-p) cmd))))))

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

[Juri Linkov]

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

Now I removed these modes, and replaced them with `defcustom`s.

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

I'm not sure about the default values - the cycling keys still
get in the way in some cases.