GNU bug report logs - #9432
24.0.50; doc string of `next-error-highlight'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9432 in the body.
You can then email your comments to 9432 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; doc string of `next-error-highlight'
Date: Sat, 3 Sep 2011 18:16:01 -0700

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'
 

Message #8 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Mon, 05 Sep 2011 11:45:54 +0300

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

Message #11 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>
Cc: 9432 <at> debbugs.gnu.org
Subject: RE: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Mon, 5 Sep 2011 06:55:12 -0700

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

Message #14 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Tue, 06 Sep 2011 12:42:12 +0300

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

Message #17 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>
Cc: 9432 <at> debbugs.gnu.org
Subject: RE: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Tue, 6 Sep 2011 06:47:21 -0700

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

Message #20 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Wed, 07 Sep 2011 14:48:33 +0300

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.

Message #23 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Wed, 07 Sep 2011 09:34:54 -0400

> 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

Message #26 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>
Cc: 9432 <at> debbugs.gnu.org
Subject: RE: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Wed, 7 Sep 2011 07:05:23 -0700

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

Message #29 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 08 Sep 2011 02:52:54 +0300

> 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

Message #32 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 9432 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Wed, 07 Sep 2011 21:42:45 -0400

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

Message #35 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>
Cc: 9432 <at> debbugs.gnu.org
Subject: RE: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 8 Sep 2011 06:15:52 -0700

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

Message #38 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Juri Linkov'" <juri <at> jurta.org>
Cc: 9432 <at> debbugs.gnu.org
Subject: RE: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 8 Sep 2011 06:17:28 -0700

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

Message #41 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9432 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 08 Sep 2011 23:09:53 +0300

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

Message #44 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 9432 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 08 Sep 2011 22:17:43 -0400

> 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

Message #49 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, Drew Adams <drew.adams <at> oracle.com>,
 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 28 Apr 2016 13:20:16 +0200

Stefan Monnier <monnier <at> 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

Message #52 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: 9432 <at> debbugs.gnu.org
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 13 Jun 2019 13:26:04 +0200

Lars Ingebrigtsen <larsi <at> 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

Message #55 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: larsi <at> gnus.org, monnier <at> iro.umontreal.ca, 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 13 Jun 2019 15:44:09 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Thu, 13 Jun 2019 13:26:04 +0200
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>
> 
> Lars Ingebrigtsen <larsi <at> 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.

Message #62 received at 9432 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 9432 <at> debbugs.gnu.org
Subject: Re: bug#9432: 24.0.50; doc string of `next-error-highlight'
Date: Thu, 13 Jun 2019 15:07:29 +0200

Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.