* bug#9432: 24.0.50; doc string of `next-error-highlight' @ 2011-09-04 1:16 Drew Adams 2011-09-05 8:45 ` Juri Linkov 2019-06-13 11:26 ` Stefan Kangas 0 siblings, 2 replies; 18+ messages in thread From: Drew Adams @ 2011-09-04 1:16 UTC (permalink / raw) To: 9432 The doc string correctly describes the length of time of highlighting for each of the values that does highlighting... EXCEPT for the value `fringe-arrow'. In that case the doc only says WHERE the "highlighting"/indication occurs; it does not say UNTIL WHEN it occurs. The doc string should say that the fringe indication is moved when some other locus replaces it - just as it says this for a value of `t'. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2011-08-29 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.5) --no-opt' ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-04 1:16 bug#9432: 24.0.50; doc string of `next-error-highlight' Drew Adams @ 2011-09-05 8:45 ` Juri Linkov 2011-09-05 13:55 ` Drew Adams 2019-06-13 11:26 ` Stefan Kangas 1 sibling, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-09-05 8:45 UTC (permalink / raw) To: Drew Adams; +Cc: 9432 > The doc string correctly describes the length of time of highlighting > for each of the values that does highlighting... EXCEPT for the value > `fringe-arrow'. In that case the doc only says WHERE the > "highlighting"/indication occurs; it does not say UNTIL WHEN it occurs. > > The doc string should say that the fringe indication is moved when some > other locus replaces it - just as it says this for a value of `t'. Is this better? === modified file 'lisp/simple.el' --- lisp/simple.el 2011-07-28 14:05:07 +0000 +++ lisp/simple.el 2011-09-05 08:44:02 +0000 @@ -73,7 +73,8 @@ (defcustom next-error-highlight 0.5 If t, highlight the locus until the next command is executed, or until some other locus replaces it. If nil, don't highlight the locus in the source buffer. -If `fringe-arrow', indicate the locus by the fringe arrow." +If `fringe-arrow', indicate the locus by the fringe arrow +indefinitely until some other locus replaces it." :type '(choice (number :tag "Highlight for specified time") (const :tag "Semipermanent highlighting" t) (const :tag "No highlighting" nil) @@ -86,7 +87,8 @@ (defcustom next-error-highlight-no-selec If number, highlight the locus in `next-error' face for given time in seconds. If t, highlight the locus indefinitely until some other locus replaces it. If nil, don't highlight the locus in the source buffer. -If `fringe-arrow', indicate the locus by the fringe arrow." +If `fringe-arrow', indicate the locus by the fringe arrow +indefinitely until some other locus replaces it." :type '(choice (number :tag "Highlight for specified time") (const :tag "Semipermanent highlighting" t) (const :tag "No highlighting" nil) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-05 8:45 ` Juri Linkov @ 2011-09-05 13:55 ` Drew Adams 2011-09-06 9:42 ` Juri Linkov 0 siblings, 1 reply; 18+ messages in thread From: Drew Adams @ 2011-09-05 13:55 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: 9432 > > The doc string should say that the fringe indication is > > moved when some other locus replaces it - just as it says > > this for a value of `t'. > > Is this better? > > +If `fringe-arrow', indicate the locus by the fringe arrow > +indefinitely until some other locus replaces it." Yes, thanks. (And FWIW I still think we should also have a value `until-move' that does the same thing - stay until some other locus replaces it - but using highlighting instead of fringe. I've been using that for years myself, so I obviously prefer it - I generally don't show the fringe.) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-05 13:55 ` Drew Adams @ 2011-09-06 9:42 ` Juri Linkov 2011-09-06 13:47 ` Drew Adams 0 siblings, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-09-06 9:42 UTC (permalink / raw) To: Drew Adams; +Cc: 9432 > (And FWIW I still think we should also have a value `until-move' that does the > same thing - stay until some other locus replaces it - but using highlighting > instead of fringe. I've been using that for years myself, so I obviously prefer > it - I generally don't show the fringe.) But the value `t' already does that - it highlights the locus until some other locus replaces it. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-06 9:42 ` Juri Linkov @ 2011-09-06 13:47 ` Drew Adams 2011-09-07 11:48 ` Juri Linkov 2011-09-07 13:34 ` Stefan Monnier 0 siblings, 2 replies; 18+ messages in thread From: Drew Adams @ 2011-09-06 13:47 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: 9432 > > (And FWIW I still think we should also have a value > > `until-move' that does the same thing - stay until some > > other locus replaces it - but using highlighting > > instead of fringe. I've been using that for years myself, > > so I obviously prefer it - I generally don't show the fringe.) > > But the value `t' already does that - it highlights the locus > until some other locus replaces it. 1. No, it does not. It highlights only until the next command (which is silly, IMHO). Move the cursor and poof! it's gone. Only the fringe has a reasonable behavior (IMO). 2. FWIW2, the behavior I *actually* prefer is what I implemented for Emacs 20-21, before there was any such highlighting in Emacs: just show the highlighting forever (or until I remove it - on-demand). That makes it easy to notice and compare multiple locations in the source buffer. It makes it clear where you've been, which hits you have already visited. I did not bother with that after Emacs finally added highlighting, since the highlighting used a different means etc. Value `until-move' is good enough (second best). And I still use Emacs 20 much of the time (since I maintain code that supports it), and there I enjoy the behavior I prefer. But IMHO it should also be possible for vanilla Emacs users to keep the highlighting until some user action (a particular key/command, not just the *next* command). One choice for such a key might be `C-0 C-x `' (next-error with 0 prefix arg). 3. FWIW3: in Emacs -Q, even if I already have the target source file in a separate frame (e.g. from `C-x 5 b' after having shown it once in the same frame), and even if that is the *only* place it is currently displayed, `C-x `' or hit `RET' or click a hit in *grep* still pops up the source file in the same frame as *grep* and highlights the hit there (does not even highlight it in both places). The already displayed source buffer should obviously be used, instead of multiplying things unnecessarily. Or the behavior should be optional, under user control, and the default should be to show hits in a window already displaying the source buffer. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-06 13:47 ` Drew Adams @ 2011-09-07 11:48 ` Juri Linkov 2011-09-07 14:05 ` Drew Adams 2011-09-07 13:34 ` Stefan Monnier 1 sibling, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-09-07 11:48 UTC (permalink / raw) To: Drew Adams; +Cc: 9432 Version: 24.2 Severity: wishlist > But IMHO it should also be possible for vanilla Emacs users to keep the > highlighting until some user action (a particular key/command, not just the > *next* command). One choice for such a key might be `C-0 C-x `' (next-error > with 0 prefix arg). Permanent highlighting for `next-error-highlight' is a new feature, so it should be postponed to 24.2. > 3. FWIW3: in Emacs -Q, even if I already have the target source file in a > separate frame (e.g. from `C-x 5 b' after having shown it once in the same > frame), and even if that is the *only* place it is currently displayed, `C-x `' > or hit `RET' or click a hit in *grep* still pops up the source file in the same > frame as *grep* and highlights the hit there (does not even highlight it in both > places). > > The already displayed source buffer should obviously be used, instead of > multiplying things unnecessarily. Or the behavior should be optional, under > user control, and the default should be to show hits in a window already > displaying the source buffer. This should be customizable with `display-buffer-alist'. > > Is this better? > > +If `fringe-arrow', indicate the locus by the fringe arrow > > +indefinitely until some other locus replaces it." > Yes, thanks. Fixed. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-07 11:48 ` Juri Linkov @ 2011-09-07 14:05 ` Drew Adams 2011-09-07 23:52 ` Juri Linkov 0 siblings, 1 reply; 18+ messages in thread From: Drew Adams @ 2011-09-07 14:05 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: 9432 > Permanent highlighting for `next-error-highlight' is a new feature, > so it should be postponed to 24.2. Sure, great. But please do not call it "permanent" in the doc. There would be several times/actions that removed such highlighting; that's all: next command, next locus change, explicit user command (e.g. `C-0 C-x `'). > > The already displayed source buffer should obviously be > > used, instead of multiplying things unnecessarily. Or the > > behavior should be optional, under user control, and the > > default should be to show hits in a window already > > displaying the source buffer. > > This should be customizable with `display-buffer-alist'. sm> It's optional, controlled by display-buffer-reuse-frames. sm> The default is nil, largely for historical reasons. Users should not have to customize anything to get unbugged behavior using emacs -Q. If the source file is already showing, why pop it up again in a new window, by _default_? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-07 14:05 ` Drew Adams @ 2011-09-07 23:52 ` Juri Linkov 2011-09-08 1:42 ` Stefan Monnier 2011-09-08 13:15 ` Drew Adams 0 siblings, 2 replies; 18+ messages in thread From: Juri Linkov @ 2011-09-07 23:52 UTC (permalink / raw) To: Drew Adams; +Cc: 9432 > Users should not have to customize anything to get unbugged behavior > using emacs -Q. If the source file is already showing, why pop it up > again in a new window, by _default_? When using virtual frames on a single-window xterm, such behavior is annoying: displaying the source file has no visual effect at all because it's displayed on a hidden virtual frame. Please see more at http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01638.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-07 23:52 ` Juri Linkov @ 2011-09-08 1:42 ` Stefan Monnier 2011-09-08 13:17 ` Drew Adams 2011-09-08 20:09 ` Juri Linkov 2011-09-08 13:15 ` Drew Adams 1 sibling, 2 replies; 18+ messages in thread From: Stefan Monnier @ 2011-09-08 1:42 UTC (permalink / raw) To: Juri Linkov; +Cc: 9432 >> Users should not have to customize anything to get unbugged behavior >> using emacs -Q. If the source file is already showing, why pop it up >> again in a new window, by _default_? > When using virtual frames on a single-window xterm, such behavior is > annoying: displaying the source file has no visual effect at all > because it's displayed on a hidden virtual frame. Please see more at > http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01638.html I'd argue that such use-case is sufficiently rare that we shouldn't base the default on it. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-08 1:42 ` Stefan Monnier @ 2011-09-08 13:17 ` Drew Adams 2011-09-08 20:09 ` Juri Linkov 1 sibling, 0 replies; 18+ messages in thread From: Drew Adams @ 2011-09-08 13:17 UTC (permalink / raw) To: 'Stefan Monnier', 'Juri Linkov'; +Cc: 9432 > I'd argue that such use-case is sufficiently rare that we > shouldn't base the default on it. 1+ You put it more succinctly than I. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-08 1:42 ` Stefan Monnier 2011-09-08 13:17 ` Drew Adams @ 2011-09-08 20:09 ` Juri Linkov 2011-09-09 2:17 ` Stefan Monnier 1 sibling, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-09-08 20:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9432 >> When using virtual frames on a single-window xterm, such behavior is >> annoying: displaying the source file has no visual effect at all >> because it's displayed on a hidden virtual frame. Please see more at >> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01638.html > > I'd argue that such use-case is sufficiently rare that we shouldn't base > the default on it. Yes, this use-case is rare, but there are other use-cases where something more than `display-buffer-reuse-frames' is necessary like described in http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00267.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-08 20:09 ` Juri Linkov @ 2011-09-09 2:17 ` Stefan Monnier 2016-04-28 11:20 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2011-09-09 2:17 UTC (permalink / raw) To: Juri Linkov; +Cc: 9432 > Yes, this use-case is rare, but there are other use-cases where > something more than `display-buffer-reuse-frames' is necessary > like described in http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00267.html I don't see how that goes against changing the default of display-buffer-reuse-frames. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-09 2:17 ` Stefan Monnier @ 2016-04-28 11:20 ` Lars Ingebrigtsen 0 siblings, 0 replies; 18+ messages in thread From: Lars Ingebrigtsen @ 2016-04-28 11:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9432 Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Yes, this use-case is rare, but there are other use-cases where >> something more than `display-buffer-reuse-frames' is necessary >> like described in http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00267.html > > I don't see how that goes against changing the default of > display-buffer-reuse-frames. The doc string of this variable is included below. Has whatever this bug report is talking about been fixed now? ---- display-buffer-reuse-frames is a variable defined in ‘window.el’. Its value is nil This variable is obsolete since 24.3; use a `reusable-frames' alist entry in `display-buffer-alist'. Documentation: Non-nil means ‘display-buffer’ should reuse frames. If the buffer in question is already displayed in a frame, raise that frame. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-07 23:52 ` Juri Linkov 2011-09-08 1:42 ` Stefan Monnier @ 2011-09-08 13:15 ` Drew Adams 1 sibling, 0 replies; 18+ messages in thread From: Drew Adams @ 2011-09-08 13:15 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: 9432 > > Users should not have to customize anything to get unbugged behavior > > using emacs -Q. If the source file is already showing, why > > pop it up again in a new window, by _default_? > > When using virtual frames on a single-window xterm, such > behavior is annoying: > displaying the source file has no visual effect at all > because it's displayed > on a hidden virtual frame. Please see more at > http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01638.html Sounds like a corner case that should be handled specially. No, I'm no expert on this, and yes, I can imagine that someone might sometimes like the current behavior (even outside a xterm virtual frames context). Still, in general it seems like a bad default behavior. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-06 13:47 ` Drew Adams 2011-09-07 11:48 ` Juri Linkov @ 2011-09-07 13:34 ` Stefan Monnier 1 sibling, 0 replies; 18+ messages in thread From: Stefan Monnier @ 2011-09-07 13:34 UTC (permalink / raw) To: Drew Adams; +Cc: 9432 > 3. FWIW3: in Emacs -Q, even if I already have the target source file > in a separate frame (e.g. from `C-x 5 b' after having shown it once in > the same frame), and even if that is the *only* place it is currently > displayed, `C-x `' or hit `RET' or click a hit in *grep* still pops up > the source file in the same frame as *grep* and highlights the hit > there (does not even highlight it in both places). > The already displayed source buffer should obviously be used, instead of > multiplying things unnecessarily. Or the behavior should be optional, under > user control, and the default should be to show hits in a window already > displaying the source buffer. It's optional, controlled by display-buffer-reuse-frames. The default is nil, largely for historical reasons. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2011-09-04 1:16 bug#9432: 24.0.50; doc string of `next-error-highlight' Drew Adams 2011-09-05 8:45 ` Juri Linkov @ 2019-06-13 11:26 ` Stefan Kangas 2019-06-13 12:44 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Stefan Kangas @ 2019-06-13 11:26 UTC (permalink / raw) To: 9432; +Cc: Lars Ingebrigtsen, Stefan Monnier Lars Ingebrigtsen <larsi@gnus.org> writes: > Has whatever this bug report is talking about been fixed now? No update in three years. Does anyone object to closing it? Thanks, Stefan Kangas ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2019-06-13 11:26 ` Stefan Kangas @ 2019-06-13 12:44 ` Eli Zaretskii 2019-06-13 13:07 ` Stefan Kangas 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-06-13 12:44 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, monnier, 9432 > From: Stefan Kangas <stefan@marxist.se> > Date: Thu, 13 Jun 2019 13:26:04 +0200 > Cc: Lars Ingebrigtsen <larsi@gnus.org>, > Stefan Monnier <monnier@iro.umontreal.ca> > > Lars Ingebrigtsen <larsi@gnus.org> writes: > > Has whatever this bug report is talking about been fixed now? > > No update in three years. Does anyone object to closing it? Time to close, indeed. The original issue was solved long ago. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9432: 24.0.50; doc string of `next-error-highlight' 2019-06-13 12:44 ` Eli Zaretskii @ 2019-06-13 13:07 ` Stefan Kangas 0 siblings, 0 replies; 18+ messages in thread From: Stefan Kangas @ 2019-06-13 13:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, Stefan Monnier, 9432 Eli Zaretskii <eliz@gnu.org> writes: > > No update in three years. Does anyone object to closing it? > > Time to close, indeed. The original issue was solved long ago. Done. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-06-13 13:07 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-04 1:16 bug#9432: 24.0.50; doc string of `next-error-highlight' Drew Adams 2011-09-05 8:45 ` Juri Linkov 2011-09-05 13:55 ` Drew Adams 2011-09-06 9:42 ` Juri Linkov 2011-09-06 13:47 ` Drew Adams 2011-09-07 11:48 ` Juri Linkov 2011-09-07 14:05 ` Drew Adams 2011-09-07 23:52 ` Juri Linkov 2011-09-08 1:42 ` Stefan Monnier 2011-09-08 13:17 ` Drew Adams 2011-09-08 20:09 ` Juri Linkov 2011-09-09 2:17 ` Stefan Monnier 2016-04-28 11:20 ` Lars Ingebrigtsen 2011-09-08 13:15 ` Drew Adams 2011-09-07 13:34 ` Stefan Monnier 2019-06-13 11:26 ` Stefan Kangas 2019-06-13 12:44 ` Eli Zaretskii 2019-06-13 13:07 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).