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