* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings [not found] ` <20210303191237.2B2D720E1B@vcs0.savannah.gnu.org> @ 2021-03-03 20:13 ` Stefan Monnier 2021-03-03 20:38 ` Juri Linkov 2021-03-07 18:53 ` Juri Linkov 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2021-03-03 20:13 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-03 20:13 ` master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings Stefan Monnier @ 2021-03-03 20:38 ` Juri Linkov 2021-03-03 21:44 ` Stefan Monnier 2021-03-04 0:31 ` Gabriel do Nascimento Ribeiro 2021-03-07 18:53 ` Juri Linkov 1 sibling, 2 replies; 20+ messages in thread From: Juri Linkov @ 2021-03-03 20:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-03 20:38 ` Juri Linkov @ 2021-03-03 21:44 ` Stefan Monnier 2021-03-04 8:58 ` Juri Linkov 2021-03-04 17:03 ` Daniele Nicolodi 2021-03-04 0:31 ` Gabriel do Nascimento Ribeiro 1 sibling, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2021-03-03 21:44 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-03 21:44 ` Stefan Monnier @ 2021-03-04 8:58 ` Juri Linkov 2021-03-04 13:20 ` Stefan Monnier 2021-03-04 17:03 ` Daniele Nicolodi 1 sibling, 1 reply; 20+ messages in thread From: Juri Linkov @ 2021-03-04 8:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel >> ;;; 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 8:58 ` Juri Linkov @ 2021-03-04 13:20 ` Stefan Monnier 2021-03-04 18:12 ` Juri Linkov 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2021-03-04 13:20 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 13:20 ` Stefan Monnier @ 2021-03-04 18:12 ` Juri Linkov 2021-03-04 19:07 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Juri Linkov @ 2021-03-04 18:12 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > [ 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 18:12 ` Juri Linkov @ 2021-03-04 19:07 ` Stefan Monnier 0 siblings, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2021-03-04 19:07 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel >> [ 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-03 21:44 ` Stefan Monnier 2021-03-04 8:58 ` Juri Linkov @ 2021-03-04 17:03 ` Daniele Nicolodi 2021-03-04 18:06 ` Stefan Monnier 2021-03-04 18:17 ` Juri Linkov 1 sibling, 2 replies; 20+ messages in thread From: Daniele Nicolodi @ 2021-03-04 17:03 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 17:03 ` Daniele Nicolodi @ 2021-03-04 18:06 ` Stefan Monnier 2021-03-04 20:38 ` Juri Linkov 2021-03-04 18:17 ` Juri Linkov 1 sibling, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2021-03-04 18:06 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 18:06 ` Stefan Monnier @ 2021-03-04 20:38 ` Juri Linkov 0 siblings, 0 replies; 20+ messages in thread From: Juri Linkov @ 2021-03-04 20:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: Daniele Nicolodi, emacs-devel >> 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 ;-) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 17:03 ` Daniele Nicolodi 2021-03-04 18:06 ` Stefan Monnier @ 2021-03-04 18:17 ` Juri Linkov 2021-03-04 19:37 ` Daniele Nicolodi 1 sibling, 1 reply; 20+ messages in thread From: Juri Linkov @ 2021-03-04 18:17 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 18:17 ` Juri Linkov @ 2021-03-04 19:37 ` Daniele Nicolodi 2021-03-04 20:35 ` Juri Linkov 0 siblings, 1 reply; 20+ messages in thread From: Daniele Nicolodi @ 2021-03-04 19:37 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 19:37 ` Daniele Nicolodi @ 2021-03-04 20:35 ` Juri Linkov 2021-03-04 20:44 ` Daniele Nicolodi 2021-03-04 22:57 ` Stefan Monnier 0 siblings, 2 replies; 20+ messages in thread From: Juri Linkov @ 2021-03-04 20:35 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 20:35 ` Juri Linkov @ 2021-03-04 20:44 ` Daniele Nicolodi 2021-03-04 20:53 ` Juri Linkov 2021-03-04 22:57 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Daniele Nicolodi @ 2021-03-04 20:44 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 20:44 ` Daniele Nicolodi @ 2021-03-04 20:53 ` Juri Linkov 0 siblings, 0 replies; 20+ messages in thread From: Juri Linkov @ 2021-03-04 20:53 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 20:35 ` Juri Linkov 2021-03-04 20:44 ` Daniele Nicolodi @ 2021-03-04 22:57 ` Stefan Monnier 1 sibling, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2021-03-04 22:57 UTC (permalink / raw) To: Juri Linkov; +Cc: Daniele Nicolodi, emacs-devel > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-03 20:38 ` Juri Linkov 2021-03-03 21:44 ` Stefan Monnier @ 2021-03-04 0:31 ` Gabriel do Nascimento Ribeiro 2021-03-04 9:05 ` Juri Linkov 1 sibling, 1 reply; 20+ messages in thread From: Gabriel do Nascimento Ribeiro @ 2021-03-04 0:31 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 0:31 ` Gabriel do Nascimento Ribeiro @ 2021-03-04 9:05 ` Juri Linkov 2021-03-07 18:54 ` Juri Linkov 0 siblings, 1 reply; 20+ messages in thread From: Juri Linkov @ 2021-03-04 9:05 UTC (permalink / raw) To: Gabriel do Nascimento Ribeiro; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-04 9:05 ` Juri Linkov @ 2021-03-07 18:54 ` Juri Linkov 0 siblings, 0 replies; 20+ messages in thread From: Juri Linkov @ 2021-03-07 18:54 UTC (permalink / raw) To: Gabriel do Nascimento Ribeiro; +Cc: emacs-devel >> 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)))))) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings 2021-03-03 20:13 ` master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings Stefan Monnier 2021-03-03 20:38 ` Juri Linkov @ 2021-03-07 18:53 ` Juri Linkov 1 sibling, 0 replies; 20+ messages in thread From: Juri Linkov @ 2021-03-07 18:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2021-03-07 18:54 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20210303191236.24697.93201@vcs0.savannah.gnu.org> [not found] ` <20210303191237.2B2D720E1B@vcs0.savannah.gnu.org> 2021-03-03 20:13 ` master 6458e16: New mode outline-cycle-minor-mode with Orgmode-like TAB cycling on headings Stefan Monnier 2021-03-03 20:38 ` Juri Linkov 2021-03-03 21:44 ` Stefan Monnier 2021-03-04 8:58 ` Juri Linkov 2021-03-04 13:20 ` Stefan Monnier 2021-03-04 18:12 ` Juri Linkov 2021-03-04 19:07 ` Stefan Monnier 2021-03-04 17:03 ` Daniele Nicolodi 2021-03-04 18:06 ` Stefan Monnier 2021-03-04 20:38 ` Juri Linkov 2021-03-04 18:17 ` Juri Linkov 2021-03-04 19:37 ` Daniele Nicolodi 2021-03-04 20:35 ` Juri Linkov 2021-03-04 20:44 ` Daniele Nicolodi 2021-03-04 20:53 ` Juri Linkov 2021-03-04 22:57 ` Stefan Monnier 2021-03-04 0:31 ` Gabriel do Nascimento Ribeiro 2021-03-04 9:05 ` Juri Linkov 2021-03-07 18:54 ` Juri Linkov 2021-03-07 18:53 ` Juri Linkov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.