emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#14015: closed (Feature request: highlight partial


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#14015: closed (Feature request: highlight partial matches in Info's index-search)
Date: Sat, 23 Mar 2013 00:45:02 +0000

Your message dated Sat, 23 Mar 2013 02:40:11 +0200
with message-id <address@hidden>
and subject line Re: bug#14015: Feature request: highlight partial matches in 
Info's index-search
has caused the debbugs.gnu.org bug report #14015,
regarding Feature request: highlight partial matches in Info's index-search
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
14015: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14015
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Feature request: highlight partial matches in Info's index-search Date: Thu, 21 Mar 2013 19:24:00 +0200
When 'i foo RET' yields a partial match, e.g., finding "foobar" in the
index, the stand-alone Info reader "highlights" the part that matched,
like this:

   Found FOObar in Some Node. (`,' tries to find next.)

(The stand-alone reader is a text-mode program, so it changes the
letter-case to emphasize the part that matched.)

It would be nice if Emacs did something similar, although it is
probably better to use colors if available.  (We could also use bold
or italic, but at least bold might cause annoying movement of the mode
line, to allow for slightly larger font.)



--- End Message ---
--- Begin Message --- Subject: Re: bug#14015: Feature request: highlight partial matches in Info's index-search Date: Sat, 23 Mar 2013 02:40:11 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu)
>> +(defcustom Info-index-match-face 'match
>> +  "Face used by \\[Info-index] to show the text that matches.
>> +If the value is nil, don't highlight the matching portions specially."
>> +  :type 'face
>> +  :group 'info
>> +  :version "24.4")
>
> Nowadays, we usually prefer to define a new face that inherits from
> `match'.

I installed with defface that inherits from `match' instead of using defcustom.
All other Info faces are defined with defface too, so a new defface will be
consistent with other Info faces.

However, a new face `list-matching-lines-prefix-face' that I proposed
in bug#14017 is better to define with defcustom for consistency with other
occur-related faces `list-matching-lines-buffer-name-face' and
`list-matching-lines-face' that are defined with defcustom:

  (defcustom list-matching-lines-face 'match
    "Face used by \\[list-matching-lines] to show the text that matches.
  If the value is nil, don't highlight the matching portions specially."
    :type 'face
    :group 'matching)

  (defcustom list-matching-lines-buffer-name-face 'underline
    "Face used by \\[list-matching-lines] to show the names of buffers.
  If the value is nil, don't highlight the buffer names specially."
    :type 'face
    :group 'matching)

I'm not sure whether they should be turned info defface as well
because this will also require converting more related faces to defface,
e.g. grep faces:

  (defvar grep-match-face       'match
    "Face name to use for grep matches.")

  (defvar grep-context-face 'shadow
    "Face name to use for grep context lines.")

And even after adding deffaces for them these old variables should still remain
for backward compatibility with definitions like:

  (defcustom list-matching-lines-face 'occur-match

  (defvar grep-match-face 'grep-match


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]