Re: Emphasize the character to be typed next in *Completions*

Re: Emphasize the character to be typed next in *Completions*

[Lars Hansen]

>That could be a clever idea.  Others: do you like this feature?
>  
>
IMHO it would be better with a highlighting like the one in incremental 
search, i.e. highlight the part of the possible completions that match 
what is in the minibuffer. It gives the same information to the user, 
but is more familiar.

I don't think Emacs should try to tell the user "what to type next", 
Emacs does not know that. Emacs should tell the user what Emacs does 
know: Which possible completions are found so far.

Re: Emphasize the character to be typed next in *Completions*

[Lars Hansen]

Lars Hansen wrote:

> Emacs should tell the user what Emacs does know: Which possible 
> completions are found so far.
>
I didn't get it right the first time:

Emacs should tell the user what Emacs does know: *Why* there are more 
possible completions: Because they all match.

That can be done by highlighting the match like incremental search do.

Re: Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

> >That could be a clever idea.  Others: do you like this feature?
> >  
> >
> IMHO it would be better with a highlighting like the one in incremental 
> search, i.e. highlight the part of the possible completions that match 
> what is in the minibuffer. It gives the same information to the user, 
> but is more familiar.

I also implemented a version which highlights the common perfix string
in completions. And I felt that the visual feedback is too strong.
The situation is similar to incremental search a space; all the spaces
are highlighted in the buffer; too many part of a buffer is highlighted.
The user may feel where one's eyes focus on in the completions buffer.

I also implemented a version which drops shadow on the common perfix
string in completions. Dropping shadow means put a face which
foreground is dark gray on the string. I felt that it is just indistinct.

Putting bold face on a character has good balance between too much
highlighting and indistinct representation.

>From my view, Using box face property or underline face property may
be good...but I have not tried yet.

Should I provide all versions and make them choose-able?

Re: Emphasize the character to be typed next in *Completions*

[Lars Hansen]

Masatake YAMATO wrote:

>I also implemented a version which highlights the common perfix string
>in completions. And I felt that the visual feedback is too strong.
>  
>
Ok, I haven't actually tried it out, but you have.

>Should I provide all versions and make them choose-able?
>  
>
That may solve the problem.

Re: Emphasize the character to be typed next in *Completions*

[David Kastrup]

Lars Hansen <larsh@math.ku.dk> writes:

> Masatake YAMATO wrote:
> 
> >I also implemented a version which highlights the common perfix string
> >in completions. And I felt that the visual feedback is too strong.
> >  
> Ok, I haven't actually tried it out, but you have.
> 
> >Should I provide all versions and make them choose-able?
> >  
> That may solve the problem.

Increasing the number of dissatisfactory choices is not really a
substitute for a good solution.  Only when it becomes obvious that a
good solution is impossible and the available choices are comparably
dissatisfactory, can one justify shifting the responsibility to the
taste of the user.

But I'd not call that solving a problem.  It is just giving in to the
inevitable at one point.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emphasize the character to be typed next in *Completions*

[Lars Hansen]

David Kastrup wrote:

>Increasing the number of dissatisfactory choices is not really a
>substitute for a good solution.
>  
>
I agree.

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    > IMHO it would be better with a highlighting like the one in incremental 
    > search, i.e. highlight the part of the possible completions that match 
    > what is in the minibuffer. It gives the same information to the user, 
    > but is more familiar.

    I also implemented a version which highlights the common perfix string
    in completions. And I felt that the visual feedback is too strong.

I agree.  To emphasize the part that is not informative is not a
useful feature.

We want to keep various Emacs features coherent, all else being equal,
but we should not make a user interface hard to use merely to follow
some other feature.

    Putting bold face on a character has good balance between too much
    highlighting and indistinct representation.

    >From my view, Using box face property or underline face property may
    be good...but I have not tried yet.

    Should I provide all versions and make them choose-able?

Please implement the ideas that you think might be good to use,
then try them and see if they are good.

Please don't bother supporting the bad interfaces.

Re: Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

>     Putting bold face on a character has good balance between too much
>     highlighting and indistinct representation.
> 
>     >From my view, Using box face property or underline face property may
>     be good...but I have not tried yet.
> 
>     Should I provide all versions and make them choose-able?
> 
> Please implement the ideas that you think might be good to use,
> then try them and see if they are good.

I tried box face property and underline face property, but bold was better
than them. With the attached patch, You can try another face.

cvs diff: warning: unrecognized response `access control disabled, clients can connect from any host' from cvs server
Index: lisp/simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.633
diff -u -r1.633 simple.el
--- lisp/simple.el	18 Mar 2004 02:57:32 -0000	1.633
+++ lisp/simple.el	23 Mar 2004 10:37:30 -0000
@@ -4117,6 +4117,16 @@
 ;; This function goes in completion-setup-hook, so that it is called
 ;; after the text of the completion list buffer is written.
 
+(defface completion-emphasis 
+  '((t (:inherit bold)))
+  "Face used to emphasis the completions in *Completions*.")
+  
+
+(defcustom completion-emphasis-region 'first-different-character
+  "Region emphasized in the completions in *Completions*."
+  :type '(choice (const first-different-character)
+		 (const common-prefix)))
+
 (defun completion-setup-function ()
   (save-excursion
     (let ((mainbuf (current-buffer))
@@ -4145,6 +4155,26 @@
 	(save-match-data
 	  (if (minibufferp mainbuf)
 	      (setq completion-base-size 0))))
+       ;; Emphasis the first uncommon character in completions.
+      (if completion-base-size
+ 	  (let ((common-string-length (length
+				       (substring mbuf-contents 
+						  completion-base-size)))
+ 		(element-start (next-single-property-change (point-min) 'mouse-face))
+ 		element-common-end)
+ 	    (while element-start
+ 	      (setq element-common-end  (+ element-start common-string-length))
+ 	      (when (and (get-char-property element-start 'mouse-face)
+ 			 (get-char-property element-common-end 'mouse-face))
+		(case completion-emphasis-region
+		  (common-prefix
+		   (put-text-property element-start element-common-end
+				      'font-lock-face 'completion-emphasis))
+		  (first-different-character
+		   (put-text-property element-common-end (1+ element-common-end)
+				      'font-lock-face 'completion-emphasis))))
+ 	      (setq element-start (next-single-property-change element-start 'mouse-face)))))
+      ;; Insert help string.
       (goto-char (point-min))
       (if (display-mouse-p)
 	  (insert (substitute-command-keys

Re: Emphasize the character to be typed next in *Completions*

[Kim F. Storm]

Masatake YAMATO <jet@gyve.org> writes:

Looks good!
But:

> +		(case completion-emphasis-region

Isn't `case' a CL-ism ?  It shouldn't be used in simple.el ...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emphasize the character to be typed next in *Completions*

[Stefan Monnier]

>> +		(case completion-emphasis-region
> Isn't `case' a CL-ism ?  It shouldn't be used in simple.el ...

Why not?  It's a macro, so just add

   (eval-when-compile (require 'cl))


        Stefan

Re: Emphasize the character to be typed next in *Completions*

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> +		(case completion-emphasis-region
> > Isn't `case' a CL-ism ?  It shouldn't be used in simple.el ...
> 
> Why not?  It's a macro, so just add
> 
>    (eval-when-compile (require 'cl))

I know, but I had the impression that RMS didn't want cl-isms in the
"core" files...

In any case, I don't see why we cannot just use cond instead of case.

Re: Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

> > >> +		(case completion-emphasis-region
> > > Isn't `case' a CL-ism ?  It shouldn't be used in simple.el ...
> > 
> > Why not?  It's a macro, so just add
> > 
> >    (eval-when-compile (require 'cl))
> 
> I know, but I had the impression that RMS didn't want cl-isms in the
> "core" files...
> 
> In any case, I don't see why we cannot just use cond instead of case.

Ok. I will replace case with cond when I can install my patch. Is it
ready to install? (completion-emphasis and completion-emphasis-region
are now customizable.)  To which group completion-emphasis and
completion-emphasis-region members sholud be belonging ?

BTW, I think it is good to provide `customize-face-under-the-next-mouse-click'.
Even if one wants to customize a face, it is not easy to know the name of face
from the display. Is there such function or a function useful to implement such
function in emacs?

Re: Emphasize the character to be typed next in *Completions*

[Miles Bader]

Masatake YAMATO <jet@gyve.org> writes:
> BTW, I think it is good to provide
> `customize-face-under-the-next-mouse-click'.  Even if one wants to
> customize a face, it is not easy to know the name of face from the
> display. Is there such function or a function useful to implement such
> function in emacs?

`customize-face' defaults to the face underneath the cursor, so you can
just type `M-x customize-face RET RET'.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: Emphasize the character to be typed next in *Completions*

[Kim F. Storm]

Masatake YAMATO <jet@gyve.org> writes:

> > > >> +		(case completion-emphasis-region
> > > > Isn't `case' a CL-ism ?  It shouldn't be used in simple.el ...
> > > 
> > > Why not?  It's a macro, so just add
> > > 
> > >    (eval-when-compile (require 'cl))
> > 
> > I know, but I had the impression that RMS didn't want cl-isms in the
> > "core" files...
> > 
> > In any case, I don't see why we cannot just use cond instead of case.
> 
> Ok. I will replace case with cond when I can install my patch. Is it
> ready to install? (completion-emphasis and completion-emphasis-region
> are now customizable.)  

Please do.

>                         To which group completion-emphasis and
> completion-emphasis-region members sholud be belonging ?

completion seems like a good choice ... ?

> 
> BTW, I think it is good to provide `customize-face-under-the-next-mouse-click'.
> Even if one wants to customize a face, it is not easy to know the name of face
> from the display. Is there such function or a function useful to implement such
> function in emacs?

If you suggest that if some command prompts you for a face name, you may
just click on the face you want on the screen, it sounds "interesting",
but as Miles points out, M-x customize-face already defaults to the
face at point.

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    +(defcustom completion-emphasis-region 'first-different-character
    +  "Region emphasized in the completions in *Completions*."
    +  :type '(choice (const first-different-character)
    +		 (const common-prefix)))

I don't want to include this option.  It isn't useful.  Would you
please make a simplified version which does not have this?

To support every alternative that anybody has suggested
is NOT a design goal for Emacs.

Re: Emphasize the character to be typed next in *Completions*

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     +(defcustom completion-emphasis-region 'first-different-character
>     +  "Region emphasized in the completions in *Completions*."
>     +  :type '(choice (const first-different-character)
>     +		 (const common-prefix)))
> 
> I don't want to include this option.  It isn't useful.  Would you
> please make a simplified version which does not have this?

So who decides which of those _highly different_ options is the best?
I like one approach, others like the other approach.

> 
> To support every alternative that anybody has suggested
> is NOT a design goal for Emacs.

That's a good principle, but in this case the two alternatives are
both sensible -- but it is a highly personal choice which one is
preferable.  

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emphasize the character to be typed next in *Completions*

[Robert J. Chassell]

       I also implemented a version which highlights the common perfix string
       in completions. And I felt that the visual feedback is too strong.

   I agree.  To emphasize the part that is not informative is not a
   useful feature.

Please do not think in terms of any single characteristic such as
`bold'.  Not everyone uses the same monitor you do.

I never use bold because it looks bad on the monitor I mostly use.
Instead for isearch-lazy-highlight-face, I put the color "blue" in the
background.

For a compilation highlight face, I would use the color "green" or
some other color.

Different faces in different contexts.

Thank you.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Emphasize the character to be typed next in *Completions*

[Juri Linkov]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> Please do not think in terms of any single characteristic such as
> `bold'.  Not everyone uses the same monitor you do.
>
> I never use bold because it looks bad on the monitor I mostly use.

I fully agree that developers can't make assumptions about user's
display characteristics.  For example, bold faces are hardly readable
with small font sizes.

To be able to remove bold properties from all used faces and to make
other transformations that fit faces into used displays, I propose
to add a new hook `custom-define-face-hook'.  Note that existing hook
`custom-define-hook' can't be used because it's called too often
(from defcustom and defgroup).

Example of usage:

(defun my-fonts-set (&optional frame)
  (mapc (lambda (face)
          ;; My font makes bold texts unreadable,
          ;; so remove bold property from every face
          (when (face-bold-p face frame)
            (set-face-bold-p face nil frame)
            (set-face-underline-p face t frame))
          ;; Fonts with different height decrease the amount of lines
          ;; visible on screen, so remove the height properties
          (when (numberp (face-attribute face :height frame))
            (set-face-attribute face frame :height 'unspecified))
          ;; Fonts with different width decrease the amount of characters
          ;; on the line, so remove the width properties
          (when (numberp (face-attribute face :width frame))
            (set-face-attribute face frame :width 'unspecified)))
        (face-list)))

(add-to-list 'custom-define-face-hook 'my-fonts-set)

Any objections to this patch?

Index: emacs/lisp/cus-face.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cus-face.el,v
retrieving revision 1.33
diff -c -r1.33 cus-face.el
*** emacs/lisp/cus-face.el	1 Sep 2003 15:45:09 -0000	1.33
--- emacs/lisp/cus-face.el	23 Mar 2004 18:10:16 -0000
***************
*** 32,37 ****
--- 32,40 ----
  
  ;;; Declaring a face.
  
+ (defvar custom-define-face-hook nil
+   "Hook called after defining face.")
+ 
  ;;;###autoload
  (defun custom-declare-face (face spec doc &rest args)
    "Like `defface', but FACE is evaluated as a normal argument."
***************
*** 57,63 ****
      (when (and doc (null (face-documentation face)))
        (set-face-documentation face (purecopy doc)))
      (custom-handle-all-keywords face args 'custom-face)
!     (run-hooks 'custom-define-hook))
    face)
  
  ;;; Face attributes.
--- 60,67 ----
      (when (and doc (null (face-documentation face)))
        (set-face-documentation face (purecopy doc)))
      (custom-handle-all-keywords face args 'custom-face)
!     (run-hooks 'custom-define-hook)
!     (run-hooks 'custom-define-face-hook))
    face)
  
  ;;; Face attributes.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emphasize the character to be typed next in *Completions*

[Robert J. Chassell]

   To be able to remove bold properties from all used faces and to make
   other transformations that fit faces into used displays, I propose
   to add a new hook `custom-define-face-hook'.  

I like this approach, but on testing it, I find that your patch fails
on my screen, with its 135 dpi resolutionboth for
bold properties in the buffer list and in the mode line.

This is with a 10x20 font:

    -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO8859-1

The default font works fine.  However, I don't use it because it is
too small for this resolution -- just as you say.

I have never been able to figure out what to do, but am using the
patch that Miles produced more than a year ago, which works fine and
does not exhibit any race conditions, which Miles worried about.  (I
think the patch could be committed to CVS, but do not dare do it
myself.)

The old messages are in email entitled: 

    Bold by moving pixels problem
    starting on 20 Nov 2002

    signal handling bogosities
    starting on 19 Dec 2002

The patch I am using is from 

    From: Miles Bader <miles@lsi.nec.co.jp>
    Subject: Re: Bold by moving pixels problem
    Date: 18 Dec 2002 19:01:01 +0900

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Emphasize the character to be typed next in *Completions*

[Juri Linkov]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> I have never been able to figure out what to do, but am using the
> patch that Miles produced more than a year ago, which works fine and
> does not exhibit any race conditions, which Miles worried about.  (I
> think the patch could be committed to CVS, but do not dare do it
> myself.)

I have been using Miles's patch for two days now, and it
works very fine.  I haven't encountered any crashes yet.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emphasize the character to be typed next in *Completions*

[Juri Linkov]

>    I also implemented a version which highlights the common perfix string
>    in completions. And I felt that the visual feedback is too strong.
>
> I agree.  To emphasize the part that is not informative is not a
> useful feature.

To emphasize the non-informative part is not useful, but a different
face could be used to *de-emphasize* it.  (Even if emphasizing the
word "de-emphasize" looks paradoxical, it's appropriate here :-)
For example, if the default foreground color is black, displaying
the common prefix string in gray will make it more unnoticeable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emphasize the character to be typed next in *Completions*

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> >    I also implemented a version which highlights the common perfix string
> >    in completions. And I felt that the visual feedback is too strong.
> >
> > I agree.  To emphasize the part that is not informative is not a
> > useful feature.
> 
> To emphasize the non-informative part is not useful, but a different
> face could be used to *de-emphasize* it.  (Even if emphasizing the
> word "de-emphasize" looks paradoxical, it's appropriate here :-)
> For example, if the default foreground color is black, displaying
> the common prefix string in gray will make it more unnoticeable.

file-name-shadow-mode does something like this, so one could take the
faces from there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emphasize the character to be typed next in *Completions*

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> Juri Linkov <juri@jurta.org> writes:
>> >    I also implemented a version which highlights the common perfix string
>> >    in completions. And I felt that the visual feedback is too strong.
>> >
>> > I agree.  To emphasize the part that is not informative is not a
>> > useful feature.
>> 
>> To emphasize the non-informative part is not useful, but a different
>> face could be used to *de-emphasize* it.  (Even if emphasizing the
>> word "de-emphasize" looks paradoxical, it's appropriate here :-)
>> For example, if the default foreground color is black, displaying
>> the common prefix string in gray will make it more unnoticeable.
>
> file-name-shadow-mode does something like this, so one could take the
> faces from there.

It makes sense to use `file-name-shadow' face to de-emphasize files
with ignored extensions in dired buffers.

Index: emacs/lisp/dired.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/dired.el,v
retrieving revision 1.276
diff -c -r1.276 dired.el
*** emacs/lisp/dired.el	25 Mar 2004 10:40:59 -0000	1.276
--- emacs/lisp/dired.el	25 Mar 2004 21:10:00 -0000
***************
*** 334,340 ****
       ;; It is quicker to first find just an extension, then go back to the
       ;; start of that file name.  So we do this complex MATCH-ANCHORED form.
       (list (concat "\\(" (regexp-opt completion-ignored-extensions) "\\|#\\)$")
! 	   '(".+" (dired-move-to-filename) nil (0 font-lock-string-face)))))
    "Additional expressions to highlight in Dired mode.")
  \f
  ;;; Macros must be defined before they are used, for the byte compiler.
--- 345,351 ----
       ;; It is quicker to first find just an extension, then go back to the
       ;; start of that file name.  So we do this complex MATCH-ANCHORED form.
       (list (concat "\\(" (regexp-opt completion-ignored-extensions) "\\|#\\)$")
! 	   '(".+" (dired-move-to-filename) nil (0 'file-name-shadow)))))
    "Additional expressions to highlight in Dired mode.")
  \f
  ;;; Macros must be defined before they are used, for the byte compiler.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    To emphasize the non-informative part is not useful, but a different
    face could be used to *de-emphasize* it.  (Even if emphasizing the
    word "de-emphasize" looks paradoxical, it's appropriate here :-)

That is true.  So perhaps what it should do is put one face on that part
and another face on the rest.

This way, there is no option to customize, but there are two faces
to customize.

Re: Emphasize the character to be typed next in *Completions*

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     To emphasize the non-informative part is not useful, but a different
>     face could be used to *de-emphasize* it.  (Even if emphasizing the
>     word "de-emphasize" looks paradoxical, it's appropriate here :-)
> 
> That is true.  So perhaps what it should do is put one face on that part
> and another face on the rest.
> 
> This way, there is no option to customize, but there are two faces
> to customize.

That's definitely a better approach.  Setting either face variable to nil
should mean "don't decorate this part".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    That's definitely a better approach.  Setting either face variable to nil
    should mean "don't decorate this part".

I don't think these variables are necessary.  The user can customize
the face to a no-op.

We started having variables to specify which face to use
back when customizing a face was much less convenient and less
flexible than it is now.

Re: Emphasize the character to be typed next in *Completions*

[Stefan Monnier]

> We started having variables to specify which face to use
> back when customizing a face was much less convenient and less
> flexible than it is now.

It was (and still is) also to get a poor man's approximation of
buffer-local faces.


        Stefan

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    It was (and still is) also to get a poor man's approximation of
    buffer-local faces.

Where do you use them that way?

Re: Emphasize the character to be typed next in *Completions*

[Stefan Monnier]

>     It was (and still is) also to get a poor man's approximation of
>     buffer-local faces.
> Where do you use them that way?

In my .emacs for some modes where I don't want comments in
font-lock-comment-face (for example).  I first used it in dired-mode where
font-lock-FOO-face was misused for unrelated concepts.  But even when it's
used for the right concept, I've found some modes where I find that
comments play different roles or where I find keywords more or less
important, or that I want functions headers to stand out more, ...


        Stefan

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    In my .emacs for some modes where I don't want comments in
    font-lock-comment-face (for example).

I think that is something you would only need for font lock.  So it
would be unnecessary to have a variable to specify which font to use
for purposes other than font lock.

      I first used it in dired-mode where
    font-lock-FOO-face was misused for unrelated concepts.

Would you say there is still such a problem in Dired mode?
If so, what would you think of introducing new faces for Dired to use?

Re: Emphasize the character to be typed next in *Completions*

[Stefan Monnier]

>     In my .emacs for some modes where I don't want comments in
>     font-lock-comment-face (for example).

> I think that is something you would only need for font lock.  So it
> would be unnecessary to have a variable to specify which font to use
> for purposes other than font lock.

>       I first used it in dired-mode where
>     font-lock-FOO-face was misused for unrelated concepts.

> Would you say there is still such a problem in Dired mode?
> If so, what would you think of introducing new faces for Dired to use?

I think the problem shows up in various forms.  Some of them are due to
misuse of faces (like using font-lock-keyword-face to highlight unrelated
things like symlinks), but others are just nothing but user preference.

So maybe dired should introduce new faces (maybe it's done that already,
I haven't used it in a while now), but that was not my point: my point is
that buffer-local faces are useful for user customization and as long as we
don't really support them, we should try to keep using the "face-variables"
indirection used by font-lock: those variables are not obsolete.


        Stefan

Re: Emphasize the character to be typed next in *Completions*

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: 29 Mar 2004 16:24:58 -0500
> 
> So maybe dired should introduce new faces (maybe it's done that already,
> I haven't used it in a while now)

Dired still uses the standard font-lock faces, it does not define its
own faces.

I agree with Stefan that introducing Dired-specific faces is a good
idea.  Standard font-lock faces are suitable to programming
languages, not to something like file types.  Mode derived from Text
Mode, like Texinfo and Mail modes, should probably also define their
own faces.

Re: Emphasize the character to be typed next in *Completions*

[Juri Linkov]

Eli Zaretskii <eliz@elta.co.il> writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: 29 Mar 2004 16:24:58 -0500
>> 
>> So maybe dired should introduce new faces (maybe it's done that already,
>> I haven't used it in a while now)
>
> Dired still uses the standard font-lock faces, it does not define its
> own faces.
>
> I agree with Stefan that introducing Dired-specific faces is a good
> idea.  Standard font-lock faces are suitable to programming
> languages, not to something like file types.

I always wished dired would have its own faces.  How about the
following faces?

(defface dired-header
  '((t (:inherit font-lock-type-face)))
  :group 'dired)

(defface dired-mark
  '((t (:inherit font-lock-constant-face)))
  :group 'dired)

(defface dired-marked
  '((t (:inherit font-lock-warning-face)))
  :group 'dired)

(defface dired-warning
  '((t (:inherit font-lock-comment-face)))
  :group 'dired)

(defface dired-directory
  '((t (:inherit font-lock-function-name-face)))
  :group 'dired)

(defface dired-symlink
  '((t (:inherit font-lock-keyword-face)))
  :group 'dired)

(defface dired-ignored
  '((t (:inherit font-lock-string-face)))
  :group 'dired)

> Mode derived from Text Mode, like Texinfo and Mail modes, should
> probably also define their own faces.

Faces that have no semantic relation to the standard font-lock faces
should define their own faces.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    I haven't used it in a while now), but that was not my point: my point is
    that buffer-local faces are useful for user customization and as long as we
    don't really support them, we should try to keep using the "face-variables"
    indirection used by font-lock: those variables are not obsolete.

I agree, as regards font lock faces.  However, when a face is used
only in a specific mode, then this motivation for customizing it would
be rare.

Re: Emphasize the character to be typed next in *Completions*

[Stefan Monnier]

>     I haven't used it in a while now), but that was not my point: my point
>     is that buffer-local faces are useful for user customization and as
>     long as we don't really support them, we should try to keep using the
>     "face-variables" indirection used by font-lock: those variables are
>     not obsolete.

> I agree, as regards font lock faces.  However, when a face is used
> only in a specific mode, then this motivation for customizing it would
> be rare.

I don't see any reason why similar issues wouldn't come up.
You might want to use different faces for "dired on /etc" than "dired on
/home/foo".

Other examples: header-line face, default face, ... I'd love to have
different settings for those in different buffers (or at least in different
modes).


        Stefan

Re: Emphasize the character to be typed next in *Completions*

[Miles Bader]

On Tue, Mar 30, 2004 at 08:32:03PM -0500, Stefan Monnier wrote:
> > I agree, as regards font lock faces.  However, when a face is used
> > only in a specific mode, then this motivation for customizing it would
> > be rare.
> 
> I don't see any reason why similar issues wouldn't come up.  You might want
> to use different faces for "dired on /etc" than "dired on /home/foo".

Yeah, but it's proably an awful lot less likely (not that I have any proof,
but ...).

> Other examples: header-line face, default face, ... I'd love to have
> different settings for those in different buffers (or at least in different
> modes).

Of course this is definitely true.

I posted an idea for per-buffer faces a while ago (a buffer-local variable
containing an alist of face name remappings; face lookup filters requests
through this alist), which Richard seemed to think was all right; I think
I'll take a shot at a simple implementation.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Emphasize the character to be typed next in *Completions*

[Lars Hansen]

>So perhaps what it should do is put one face on that part
>and another face on the rest.
>
>This way, there is no option to customize, but there are two faces
>to customize.
>  
>
That sounds nice to me.

Re: Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

Thank you for many suggestions.
I installed the patch with following new faces:

(defface completion-emphasis 
  '((t (:inherit bold)))
  "Face put on the first uncommon character in completions in *Completions* buffer."
  :group 'completion)

(defface completion-de-emphasis 
  '((t (:inherit default)))
  "Face put on the common prefix substring in completions in *Completions* buffer."
  :group 'completion)

If you hit on better face names, let me know.
Masatake YAMATO

Re: Emphasize the character to be typed next in *Completions*

[Glenn Morris]

Masatake YAMATO wrote:

> I installed the patch with following new faces:
>
> (defface completion-emphasis 
[...]
> (defface completion-de-emphasis 

How about a NEWS entry for this feature?

Re: Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

> > I installed the patch with following new faces:
> >
> > (defface completion-emphasis 
> [...]
> > (defface completion-de-emphasis 
> 
> How about a NEWS entry for this feature?

Thank you. I've added the following item.

    ** Visual feedback of *Completions* buffer is enhanced.
    Faces are put on the common prefix substrings and the first uncommon
    charachters of each completion candidate in the *Completions* buffer.
    `completion-de-emphasis' is put on the common prefix substrings as the
    face; and `completion-emphasis' is put on the first uncommon
    charachters. By default `completion-de-emphasis' is inherited from
    `default' face. `completion-emphasis' is inherited from `bold' face.

Masatake YAMATO

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

    Date: Mon, 12 Apr 2004 03:12:27 +0900 (JST)
    To: gmorris+emacs@ast.cam.ac.uk
    From: Masatake YAMATO <jet@gyve.org>
    In-Reply-To: <41vfka1lfy.fsf@xpc14.ast.cam.ac.uk>
    Cc: emacs-devel@gnu.org
    Subject: Re: Emphasize the character to be typed next in *Completions*
    Sender: emacs-devel-bounces+rms=gnu.org@gnu.org

    > > I installed the patch with following new faces:
    > >
    > > (defface completion-emphasis 
    > [...]
    > > (defface completion-de-emphasis 
    > 
    > How about a NEWS entry for this feature?

    Thank you. I've added the following item.

	** Visual feedback of *Completions* buffer is enhanced.
	Faces are put on the common prefix substrings and the first uncommon
	charachters of each completion candidate in the *Completions* buffer.
	`completion-de-emphasis' is put on the common prefix substrings as the
	face; and `completion-emphasis' is put on the first uncommon
	charachters. By default `completion-de-emphasis' is inherited from
	`default' face. `completion-emphasis' is inherited from `bold' face.

That is clear, thanks.  This rewrite says the same thing but is easier
to read:

	** Enhanced visual feedback in *Completions* buffer.

	Completions lists use faces to highlight what all completions
	have in common and where they begin to differ.

	The common prefix shared by all possible completions uses
	the face `completion-de-emphasis', while the first character
	that isn't the same uses the face `completion-emphasis'.
	By default, `completion-de-emphasis' inherits from `default',
	and `completion-emphasis' inherits from `bold'.  The idea	
	of `completion-de-emphasis' is that you can use it to make
	the common parts less visible than normal, so that the rest
	of the differing parts is, by contrast, slightly highlighted.

However, looking at these names, it seems to me that maybe they should
be changed to `completions-common-part' and
`completions-first-difference'.  That says where they are used, which
is more useful; whether to use them for emphasis or counteremphasis is
then up to the user.  Do you agree?

Re: Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

> However, looking at these names, it seems to me that maybe they should
> be changed to `completions-common-part' and
> `completions-first-difference'.  That says where they are used, which
> is more useful; whether to use them for emphasis or counteremphasis is
> then up to the user.  Do you agree?

I completely agree with you. If no objection, I will install the improved
version in a few days.

Masatake YAMATO

Re: Emphasize the character to be typed next in *Completions*

[Juri Linkov]

Masatake YAMATO <jet@gyve.org> writes:
>> However, looking at these names, it seems to me that maybe they should
>> be changed to `completions-common-part' and
>> `completions-first-difference'.  That says where they are used, which
>> is more useful; whether to use them for emphasis or counteremphasis is
>> then up to the user.  Do you agree?
>
> I completely agree with you. If no objection, I will install the improved
> version in a few days.

I agree that new names are better because they more clearly represent
the essence of these faces.  However, their docstrings should also
suggest their possible use.

BTW, this feature sometimes fails in the *Completions* buffer.

For example, type

    M-x info RET
    g (/usr/share/ TAB

with a sufficiently long directory path and it fails with the following bt:

Debugger entered--Lisp error: (args-out-of-range 4505 4505)
  get-char-property(4505 mouse-face)
  (and (get-char-property element-start (quote mouse-face)) (get-char-property element-common-end (quote mouse-face)))
  (if (and (get-char-property element-start ...) (get-char-property element-common-end ...)) (progn (put-text-property element-start element-common-end ... ...) (put-text-property element-common-end ... ... ...)))
  (when (and (get-char-property element-start ...) (get-char-property element-common-end ...)) (put-text-property element-start element-common-end (quote font-lock-face) (quote completion-de-emphasis)) (put-text-property element-common-end (1+ element-common-end) (quote font-lock-face) (quote completion-emphasis)))
  (while element-start (setq element-common-end (+ element-start common-string-length)) (when (and ... ...) (put-text-property element-start element-common-end ... ...) (put-text-property element-common-end ... ... ...)) (setq element-start (next-single-property-change element-start ...)))
  (let ((common-string-length ...) (element-start ...) element-common-end) (while element-start (setq element-common-end ...) (when ... ... ...) (setq element-start ...)))
  (progn (let (... ... element-common-end) (while element-start ... ... ...)))
  (if completion-base-size (progn (let ... ...)))
  (when completion-base-size (let (... ... element-common-end) (while element-start ... ... ...)))
  (let ((mainbuf ...) (mbuf-contents ...)) (if minibuffer-completing-file-name (with-current-buffer mainbuf ...)) (set-buffer standard-output) (completion-list-mode) (make-local-variable (quote completion-reference-buffer)) (setq completion-reference-buffer mainbuf) (if minibuffer-completing-file-name (setq completion-base-size ...) (save-match-data ...)) (when completion-base-size (let ... ...)) (goto-char (point-min)) (if (display-mouse-p) (insert ...)) (insert (substitute-command-keys "In this buffer, type \\[choose-completion] to select the completion near point.\n\n")))
  (save-excursion (let (... ...) (if minibuffer-completing-file-name ...) (set-buffer standard-output) (completion-list-mode) (make-local-variable ...) (setq completion-reference-buffer mainbuf) (if minibuffer-completing-file-name ... ...) (when completion-base-size ...) (goto-char ...) (if ... ...) (insert ...)))
  completion-setup-function()
  run-hooks(completion-setup-hook)
  minibuffer-complete()
  call-interactively(minibuffer-complete)
  completing-read("Go to node: " Info-read-node-name-1 nil t)
  (let* ((completion-ignore-case t) (Info-read-node-completion-table ...) (nodename ...)) (if (equal nodename "") (or default ...) nodename))
  Info-read-node-name("Go to node: ")
  (list (Info-read-node-name "Go to node: ") current-prefix-arg)
  call-interactively(Info-goto-node)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

> Masatake YAMATO <jet@gyve.org> writes:
> >> However, looking at these names, it seems to me that maybe they should
> >> be changed to `completions-common-part' and
> >> `completions-first-difference'.  That says where they are used, which
> >> is more useful; whether to use them for emphasis or counteremphasis is
> >> then up to the user.  Do you agree?
> >
> > I completely agree with you. If no objection, I will install the improved
> > version in a few days.
>
> I agree that new names are better because they more clearly represent
> the essence of these faces.  However, their docstrings should also
> suggest their possible use.

As RMS suggested, I cnaged the name of faces. NEWS is also upated.

> BTW, this feature sometimes fails in the *Completions* buffer.
>
> For example, type
>
>     M-x info RET
>     g (/usr/share/ TAB
>
> with a sufficiently long directory path and it fails with the following bt:

Thank you. I have suppressed the error and installed the code to the CVS
repository.

Masatake YAMATO

Emphasize the character to be typed next in *Completions*

[Masatake YAMATO]

This patch improves visual feedback of *Completions* buffer. So 
the user can know the character to be typed next in mini buffer
more easily.

Consider you type "C-x C-f ChangeLog. tab tab" at emacs/lisp directory.
The minibuffer looks like:

    Find file: ~/hack/emacs/lisp/ChangeLog

and *Completions* buffer looks like:

    Click <mouse-2> on a completion to select it.
    In this buffer, type RET to select the completion near point.

    Possible completions are:
    ChangeLog.1                    ChangeLog.10
    ChangeLog.2                    ChangeLog.3
    ChangeLog.4                    ChangeLog.5
    ChangeLog.6                    ChangeLog.7
    ChangeLog.8                    ChangeLog.9

You will look into *Completions* buffer to find the file
name which you want to load into emacs.

My patch make the first different character in all completions
bold. In above example, characters marked by ^ is made bold.

    ChangeLog.1                    ChangeLog.10
              ^                              ^
    ChangeLog.2                    ChangeLog.3
              ^                              ^
    ChangeLog.4                    ChangeLog.5
              ^                              ^
    ChangeLog.6                    ChangeLog.7
              ^                              ^
    ChangeLog.8                    ChangeLog.9
              ^                              ^
So the user can know which key should be typed to choose
a completion easily.

Masatake YAMATO

Index: lisp/simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.633
diff -u -r1.633 simple.el
--- lisp/simple.el	18 Mar 2004 02:57:32 -0000	1.633
+++ lisp/simple.el	21 Mar 2004 14:53:54 -0000
@@ -4145,6 +4145,19 @@
 	(save-match-data
 	  (if (minibufferp mainbuf)
 	      (setq completion-base-size 0))))
+      ;; Emphasis the first uncommon character in completions.
+      (if completion-base-size
+	  (let ((common-string-length 
+		 (length (substring mbuf-contents completion-base-size)))
+		(element-start (next-single-property-change (point-min) 'mouse-face))
+		element-common-start)
+	    (while element-start
+	      (setq element-common-start (+ element-start common-string-length))
+	      (when (and (get-char-property element-start 'mouse-face)
+			 (get-char-property element-common-start 'mouse-face))
+		(put-text-property element-common-start (+ element-common-start 1) 'face 'bold))
+	      (setq element-start (next-single-property-change element-start 'mouse-face)))))
+      ;; Insert help string.
       (goto-char (point-min))
       (if (display-mouse-p)
 	  (insert (substitute-command-keys

Re: Emphasize the character to be typed next in *Completions*

[Richard Stallman]

That could be a clever idea.  Others: do you like this feature?

Re: Emphasize the character to be typed next in *Completions*

[Tak Ota]

Mon, 22 Mar 2004 00:25:30 -0500: Richard Stallman <rms@gnu.org> wrote:

> That could be a clever idea.  Others: do you like this feature?

I agree.  It is clever and useful as long as the appearance does not
make too much clutter.

-Tak

Re: Emphasize the character to be typed next in *Completions*

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> That could be a clever idea.  Others: do you like this feature?
> 

I like the idea, but I'm less positive with the actual choice.  I've
been experimenting with some of the other options proposed.  Here is
my preferred method:

*** simple.el.~1.633.~	2004-03-18 13:01:21.000000000 +0100
--- simple.el	2004-03-23 01:13:19.000000000 +0100
***************
*** 4145,4150 ****
--- 4145,4165 ----
  	(save-match-data
  	  (if (minibufferp mainbuf)
  	      (setq completion-base-size 0))))
+       ;; Emphasis the first uncommon character in completions.
+       (if (and completion-base-size
+ 	       (boundp 'font-lock-comment-face))
+ 	  (let ((common-string-length 
+ 		 (length (substring mbuf-contents completion-base-size)))
+ 		(element-start (next-single-property-change (point-min) 'mouse-face))
+ 		element-common-start)
+ 	    (while element-start
+ 	      (setq element-common-start (+ element-start common-string-length))
+ 	      (when (and (get-char-property element-start 'mouse-face)
+ 			 (get-char-property element-common-start 'mouse-face))
+ 		(put-text-property element-start element-common-start
+ 				   'face 'font-lock-comment-face))
+ 	      (setq element-start (next-single-property-change element-start 'mouse-face)))))
+       ;; Insert help string.
        (goto-char (point-min))
        (if (display-mouse-p)
  	  (insert (substitute-command-keys

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk