all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: RE: next-error-highlight = t - highlighting doesn't stay untilyoumoveto the next locus
Date: Mon, 26 Mar 2007 08:56:55 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMAEDDDAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwvwt149g0u.fsf-monnier+emacs@gnu.org>

> > The doc string description of the value t, and the behavior I prefer, is
> > that the highlighting goes away when it is replaced by the next
> > hit visit (`next-error').  Yes, this does always leave one
> > occurrence highlighted. That doesn't bother me. If it did, I would
> > make it go away by re-fontifying the buffer.
>
> Since next-error uses an overlay, re-fontifying wouldn't help.

As I said, leaving the last occurrence highlighted doesn't bother me.
Different people use Emacs differently and have different preferences.

As I said in my initial post:

> For example, if I use pop-up-frames, and I click in the source buffer
> (frame), the highlighting disappears. If the source-buffer frame
> is slightly behind the *grep* frame, then I can't see where the hit
> is - as soon as I click the frame, the highlighting disappears.

Your eyes might be quicker or better than mine, but highlighting that
disappears before I can even notice it is useless to me.

> > I've been using a similar highlighting in my own code for
> > years, and I in fact leave all of the visited occurences
> > highlighted, "forever". That makes it very easy to compare
> > bits of code - a bit like `occur' in context.
>
> >> To make it bearable, you'd need at the very least a special way to make
> >> it go away when you don't want it any more.
>
> > Yes, I have a key that removes such highlighting (in the case of my own
> > highlighting, which is of each visited hit).
>
> But then it looks more and more like a new feature, i.e. not fit
> for Emacs-22.

I'm not asking that multiple occurrences remain highlighted as in my own
code. I'm asking only that the implementation respect the doc string for
`t', that users have an option value that will leave the occurrence
highlighted until `next-error'.

  reply	other threads:[~2007-03-26 15:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-20 23:20 next-error-highlight = t - highlighting doesn't stay until you move to the next locus Drew Adams
2007-03-24 16:13 ` Eli Zaretskii
2007-03-24 16:50   ` next-error-highlight = t - highlighting doesn't stay until you moveto " Drew Adams
2007-03-24 17:43     ` Eli Zaretskii
2007-03-24 20:59       ` Drew Adams
2007-03-26  3:52         ` Richard Stallman
2007-03-26  5:41           ` next-error-highlight = t - highlighting doesn't stay until youmoveto " Drew Adams
2007-03-26  6:06             ` Miles Bader
2007-03-26 13:13             ` Stefan Monnier
2007-03-26 15:00               ` Drew Adams
2007-03-26 15:34                 ` Stefan Monnier
2007-03-26 15:56                   ` Drew Adams [this message]
2007-03-26 16:41                     ` next-error-highlight = t - highlighting doesn't stay untilyoumoveto " Chong Yidong
2007-03-26 16:51                       ` Drew Adams
2007-03-26 17:49                         ` Chong Yidong
2007-03-28  4:56                           ` Richard Stallman
2007-03-28 16:10                             ` next-error-highlight = t - highlighting doesn't stayuntilyoumoveto " Drew Adams
2007-03-28 18:52                               ` Chong Yidong
2007-03-29 15:33                               ` Richard Stallman
2007-03-28 18:36                             ` next-error-highlight = t - highlighting doesn't stay untilyoumoveto " Chong Yidong
2007-03-26 23:13             ` next-error-highlight = t - highlighting doesn't stay until youmoveto " Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EIENLHALHGIMHGDOLMIMAEDDDAAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.