[friedman@splode.com: some other observations on pcomplete]

[friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

I think someone is fixing the first of these problems,
but the rest seem severe enough that I think we should
revert the change and put Shell mode completion back the
way it was.

Could someone please make that change?

------- Start of forwarded message -------
From: Noah Friedman <friedman@splode.com>
To: johnw@gnu.org
CC: rms@gnu.org
Subject: some other observations on pcomplete
Reply-To: Noah Friedman <friedman@splode.com>
Date: Sat, 09 Mar 2002 16:31:22 -0800 (PST)

Some other things I've observed about the new completion behavior:

* It doesn't complete command names or variable names anymore, e.g. I
  cannot type "$HOME/ma<TAB>" and have it complete to "$HOME/mail".

  As far as I can tell this is because the tab key has been rebound in the
  new version from comint-dynamic-complete to shell-pcomplete, but I don't
  know if shell-pcomplete was supposed to be using the old variable/command
  completion helpers.

* It's inconsistent with the rest of emacs.  Instead of doing partial
  completion and then showing me a list of completing matches, it sometimes
  does a full completion of just one alternative, which may lead me to
  believe that is the only match.

* It's not even consistent with itself.  Sometimes it does a full
  completion (if there are only a small number of possible completions) but
  other times it displays a completion buffer.  That goes even further to
  reinforce my expectation that when a full completion is made, that's the
  only available completion!

* Sometimes I want to cd into a directory so I type some prefix of the
  directory name.  Because of the two points above, I don't know if that's
  the only match or not so I hit tab twice.  Now, since that is the only
  match, I get a list of completions in the subdirectory.

  So completion on a directory name sometimes replaces a directory name
  with another complete match, and sometimes it descends into the directory
  and produces a completion list on files below.  Behavior is surprising.

Overall I find the new behavior confusing and surprising.  Perhaps this new
mode emulates the completion behavior of some shell I've never used, but I
think emacs should be more self-consistent.  I would suggest changing the
defaults to behave as much as possible in a manner consistent with
completion in the rest of emacs.
------- End of forwarded message -------

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[John Wiegley]

>>>>> On Sun Mar 10, RMS writes:

> * It's inconsistent with the rest of emacs.  Instead of doing
>   partial completion and then showing me a list of completing
>   matches, it sometimes does a full completion of just one
>   alternative, which may lead me to believe that is the only match.

> * It's not even consistent with itself.  Sometimes it does a full
>   completion (if there are only a small number of possible
>   completions) but other times it displays a completion buffer.
>   That goes even further to reinforce my expectation that when a
>   full completion is made, that's the only available completion!

> * Sometimes I want to cd into a directory so I type some prefix of
>   the directory name.  Because of the two points above, I don't know
>   if that's the only match or not so I hit tab twice.  Now, since
>   that is the only match, I get a list of completions in the
>   subdirectory.

>   So completion on a directory name sometimes replaces a directory
>   name with another complete match, and sometimes it descends into
>   the directory and produces a completion list on files below.
>   Behavior is surprising.

These behaviors are all configurable.  Perhaps we should simple tell
shell.el to configure pcomplete so that it behaves like Emacs'
standard (and dumb yet straightforward) completion.

Noah, just set `pcomplete-cycle-completions' to nil.

John

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Miles Bader]

John Wiegley <johnw@gnu.org> writes:
> These behaviors are all configurable.  Perhaps we should simple tell
> shell.el to configure pcomplete so that it behaves like Emacs'
> standard (and dumb yet straightforward) completion.

This seems like the wrong answer -- the `cycling' behavior is potentially
very convenient, it's just that the implementation has some rough edges.

For instance, how about if, when in `cycling mode', pcomplete were to
display a note saying how many more completions there are left to cycle
through.  Then you would know that it's cycling, and wouldn't think that
there's only one completion.

It could either display these messages in the minibuffer, or perhaps as
a temporary `tag' following the completed entry like completion in the
minibuffer does, e.g.:

   If the buffer contains (_ is the cursor):

     $ cat /tmp/fo_

   and /tmp contains `foo1' and `foo2', then hitting TAB at eob would display:

     $ cat /tmp/foo1_  [1 more completion]

   at this point, hitting any key except TAB (or just waiting a while
   would result in the message going away, and whatever state pcomplete
   holds for cycling to be reset).  However, hitting TAB before that
   time would cycle to `foo2':

     $ cat /tmp/foo2_  [No more completions]

I think that would be kind of whizzy...  :-,

-Miles
-- 
We live, as we dream -- alone....

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[John Wiegley]

>>>>> On Sun Mar 10, Miles writes:

> For instance, how about if, when in `cycling mode', pcomplete were
> to display a note saying how many more completions there are left to
> cycle through.  Then you would know that it's cycling, and wouldn't
> think that there's only one completion.

> It could either display these messages in the minibuffer, or perhaps
> as a temporary `tag' following the completed entry like completion
> in the minibuffer does, e.g.:

Hey, I like that minibuffer idea.  I'll have to try it out.  Should be
very cheap to implement.

John

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Stefan Monnier]

> John Wiegley <johnw@gnu.org> writes:
> > These behaviors are all configurable.  Perhaps we should simple tell
> > shell.el to configure pcomplete so that it behaves like Emacs'
> > standard (and dumb yet straightforward) completion.
> 
> This seems like the wrong answer -- the `cycling' behavior is potentially
> very convenient, it's just that the implementation has some rough edges.

Indeed, there are two issues:
- should the default behavior be to cycle or should it be the same
  as in the rest of Emacs ?  (I personally don't like cycling too much,
  but maybe we can have non-cycling completion bound to TAB and cycling
  bound to M-TAB).
- when using the sometimes-cycling-sometimes-not behavior (which depends
  on the total number of possible completions IIUC), it should tell the
  user what actually happened in a unambiguous way.

>    and /tmp contains `foo1' and `foo2', then hitting TAB at eob would display:
> 
>      $ cat /tmp/foo1_  [1 more completion]

I agree, but last time I looked at it, I found it difficult to implement
because the completion might be done in the middle of the line and because
the "[1 more completion]" message might wrap around forcing the rest of
the display to temporarily scroll down by one line.
It seems to me that this "[1 more completion]" message should be an
overlay text which only hides other parts of the display but doesn't
cause anything else to move (it's overwritten rather than inserted).
But Emacs doesn't seem to offer any such form of "overlay text".
The closest seems to be tooltip frames.
Although maybe using overwrite-mode one could get something good enough
(problem is, it's difficult to undo the overwrite 100% because it messes
up markers).


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    These behaviors are all configurable.  Perhaps we should simple tell
    shell.el to configure pcomplete so that it behaves like Emacs'
    standard (and dumb yet straightforward) completion.

That could be an ok solution if it really achieves the effect.  But
why have the overhead of loading pcomplete just to get the same
results as before?  It seems better just to revert the change; people
who want pcomplete behavior can rebind those characters to run pcomplete
easily enough.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[John Wiegley]

>>>>> On Mon Mar 11, RMS writes:

> That could be an ok solution if it really achieves the effect.  But
> why have the overhead of loading pcomplete just to get the same
> results as before?  It seems better just to revert the change;
> people who want pcomplete behavior can rebind those characters to
> run pcomplete easily enough.

Mainly because people could then configure them back on.  But it's
fine with me if we revert.  I was just hoping to promote pcomplete as
a general-purpose completion library, reducing the amount of
duplicated algorithms.

John

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Colin Walters]

On Sun, 2002-03-10 at 16:32, Richard Stallman wrote:
> I think someone is fixing the first of these problems,
> but the rest seem severe enough that I think we should
> revert the change and put Shell mode completion back the
> way it was.
> 
> Could someone please make that change?

I will do it.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> That could be an ok solution if it really achieves the effect.  But
> why have the overhead of loading pcomplete just to get the same
> results as before?

I've noticed that pcomplete-ified shell is better than the old code in
other (small) ways too.  For instance, the completion-choices window
goes away if you start typing again (restoring the previous window
configuration); I find this very nice -- before I was often annoyed when
shell completion screwed up my window arrangement.

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Kai Großjohann]

John Wiegley <johnw@gnu.org> writes:

>>>>>> On Mon Mar 11, RMS writes:
>
>> That could be an ok solution if it really achieves the effect.  But
>> why have the overhead of loading pcomplete just to get the same
>> results as before?  It seems better just to revert the change;
>> people who want pcomplete behavior can rebind those characters to
>> run pcomplete easily enough.
>
> Mainly because people could then configure them back on.

I agree.  With pcomplete turned on but configured to behave like the
old completion, Custom is good enough to change it.

With TAB bound to the old function, people need to write Lisp in their
init files.  (Since global-set-key is not available via Custom.)

Maybe it would also be a good idea to configure pcomplete in the same
way everywhere (by default), to get uniform behavior.

Also, I gather that with pcomplete it's possible to complete on
command arguments, as well.¹  That's très cool.  The old completion
doesn't offer that.

kai

¹ For instance, "lpr -P" followed by TAB would list all available
  printers.
-- 
Silence is foo!

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Stefan Monnier]

> I think someone is fixing the first of these problems,
> but the rest seem severe enough that I think we should
> revert the change and put Shell mode completion back the
> way it was.
> 
> Could someone please make that change?

The three other points are all due to the choice of default behavior
(half-cycling).  Changing that default is trivial.
The use of pcomplete.el has several advantages, even if you make
it behave "almost as the old code", so I think it would be an error
to revert the change.
But I agree that the default should be changed to match the previous
non-cycling behavior (which is also the behavior used throughout Emacs).


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Noah Friedman]

>The three other points are all due to the choice of default behavior
>(half-cycling).  Changing that default is trivial.
>The use of pcomplete.el has several advantages, even if you make
>it behave "almost as the old code", so I think it would be an error
>to revert the change.
>But I agree that the default should be changed to match the previous
>non-cycling behavior (which is also the behavior used throughout Emacs).

I was definitely not suggesting pulling out pcomplete; just changing its
default behavior as you describe.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[John Wiegley]

>>>>> On Tue Mar 12, Kai writes:

> Maybe it would also be a good idea to configure pcomplete in the
> same way everywhere (by default), to get uniform behavior.

This is not a bad idea.  Although, with the minibuffer prompting
recommended earlier, would that be enough to allow cycling to be the
default?  Cycling is so much easier to use once you get used to it.

> Also, I gather that with pcomplete it's possible to complete on
> command arguments, as well.  That's tres cool.  The old completion
> doesn't offer that.

Yes, pcomplete search for a plain Lisp function, pcomplete/NAME, for
every command.  This function's responsibility is to return a list of
possible completions for the current argument index (with full access
to all previous arguments, and the text before point).  If more people
start using pcomplete, I would hope to see more customized completion
written for Emacs.  Already it is very smart with regard to GNU make,
tar and cvs.

John

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    The use of pcomplete.el has several advantages, even if you make
    it behave "almost as the old code", so I think it would be an error
    to revert the change.

Could someone tell me what they are?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    This is not a bad idea.  Although, with the minibuffer prompting
    recommended earlier, would that be enough to allow cycling to be the
    default?

Completion in Shell mode should by default use the same interface as
completion elsewhere in Emacs.  That I will insist on.



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     The use of pcomplete.el has several advantages, even if you make
>     it behave "almost as the old code", so I think it would be an error
>     to revert the change.
>
> Could someone tell me what they are?

I'm not an expert on this, but two things at least come to my mind:

* pcomplete can offer context-sensitive completion, depending on the
  shell command.  For instance, "make a<TAB>" reads the Makefile and
  offers all make targets starting with "a".  Filename completion
  after the "xdvi" command could be restricted to *.dvi files.  (Not
  sure if this is in pcomplete already, but it could be added easily.)

* After hitting TAB to pop up a *Completions* buffer, typing makes the
  buffer (window, actually) go away.

Additionally, if everything uses pcomplete, then the user just needs
to frob one option to get the cycling behavior, everywhere.  Same for
the other options that pcomplete allows.

kai
-- 
Silence is foo!

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Colin Walters]

On Wed, 2002-03-13 at 05:58, Richard Stallman wrote:
>     This is not a bad idea.  Although, with the minibuffer prompting
>     recommended earlier, would that be enough to allow cycling to be the
>     default?
> 
> Completion in Shell mode should by default use the same interface as
> completion elsewhere in Emacs.  That I will insist on.

Well, I think the idea is to eventually make pcomplete *the* Emacs
completion facility.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[John Wiegley]

>>>>> On Wed Mar 13, Kai writes:

>> Could someone tell me what [pcomplete's features] are?

> I'm not an expert on this, but two things at least come to my mind:

> * pcomplete can offer context-sensitive completion...

> * After hitting TAB to pop up a *Completions* buffer, typing makes
>   the buffer (window, actually) go away.

Here are a few others:

* It has several modes of prompting you with possible completions.  It
  can show you the list on first TAB, second TAB, or it can cycle.

* It can optionally expand the arguments that it completes, when
  variable references are involved.  Thus, calling pcomplete-expand on
  $HOME/.zsh<TAB> will yield /home/johnw/.zshrc.  This is not used by
  default.

* It offers context-sensitive help, as well as completion lists.  Try
  calling `M-x pcomplete-help' when you are at "cvs add ".  It will
  pop up the info page for adding files to cvs.

* It will optionally pare members of completion lists, if that
  argument has already been seen.  For example, if I type "ls .zshrc
  .zsh<TAB>", then .zshrc will not be in the second argument's
  completion list.

* Last but not least, writing new context-sensitive completion
  functions is EASY.  Granted, the process needs documentation, but
  basically you just call `pcomplete-here' and pass it a list, which
  will set the completion list for that argument position.  Take a
  look at pcomplete/tar.

John

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    Well, I think the idea is to eventually make pcomplete *the* Emacs
    completion facility.

I have yet to be convinced this is an acceptable change.  It might be,
but people will have to show me.

What I can say now is that, if this is a good idea, it is not as
important as a number of the items in the TODO list.  I think it is
misdirected effort to work on this while those other improvements that
are really needed are left for later.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[John Wiegley]

>>>>> On Thu Mar 14, RMS writes:

> What I can say now is that, if this is a good idea, it is not as
> important as a number of the items in the TODO list.  I think it is
> misdirected effort to work on this while those other improvements
> that are really needed are left for later.

I agree with that.  Pcomplete is already part of Emacs 21, so it will
be there whenever anybody has time to integrate it.

John

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

It looks like pcomplete potentially has useful features.
But it is not ready for adoption now as the default.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

I think these are the most important tasks in etc/TODO.
I will move them to the top.


Small but important fixes in existing features:

* Bring back the feature of showing the part of the buffer that is a problem
  for the use of the preferred coding systems.

* Make compile.el record the markers that point to error loci
  on text properties in the error message lines.

Important features:

* Provide user-friendly ways to list all available font families,
  display a font as a sample, etc.

* Program Enriched mode to read and save in RTF.  [Is there actually a
  decent single definition of RTF?]

* Implement something better than the current Refill mode.  This
  probably needs some primitive support.

* Implement primitive and higher-level functions to allow filling
  properly with variable-pitch faces.

* Implement a smoother vertical scroll facility.

* Implement other text formatting properties.
** Footnotes that can appear either in place or at the end of the page.
** text property that says "don't break line in middle of this".
   Don't break the line between two characters that have the
   same value of this property.
** Discretionary hyphens that are not visible when they are at end of line.

* Make movemail work with IMAP.

* Port Emacs to GTK+.  (Relevant work has been done already.)

* Make the Lucid menu widget display multilingual text.

* Remove the limitation that window and frame widths and heights can
  be only full columns/lines.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> * Provide user-friendly ways to list all available font families,
>   display a font as a sample, etc.

I have still not got my head around the face customization code to
try to slot this in there.  But I have got this working for
mouse-set-font.  The code follows for people to try out, suggestions
are welcome.

-- 
Jason Rumney


;;; Experimental font selection with a dialog.

(defcustom x-select-font-command-line-alist
  '(("gfontsel" "--print" "-f" nil)
    ("xfontsel" "-print" nil "-pattern"))
  "*Programs and associated arguments suitable for `x-select-font-command'.
The format of each entry is

 (PROGRAM STANDARD-ARGUMENTS INITIAL-SWITCH FILTER-SWITCH)

where PROGRAM is the name of the program, STANDARD-ARGUMENTS are any
arguments required to make the program behave as `x-select-font' or the user
expects, INITIAL-SWITCH is a switch to specify the font initially selected
in the dialog, and FILTER-SWITCH is a switch that can be supplied to limit
the fonts the user may choose from.

If PROGRAM does not support setting the initial font or filtering the list
of fonts, the corresponding switch should be set to nil.
If PROGRAM accepts a filter or an initial font on the command-line without
a preceding switch, then the corresponding switch should be set to t."
  :type '(alist
	  :key-type (file :tag "Program")
	  :value-type (group (string :tag "Fixed Args")
			     (choice :tag "Initial Font Switch"
				     (const :tag "Unsupported" nil)
				     (other :tag "No switch" t)
				     string)
			     (choice :tag "Filter Switch"
				     (const :tag "Unsupported" nil)
				     (other :tag "No switch" t)
				     string)))
  :group 'x)

(defcustom x-select-font-command (if (executable-find "gfontsel")
				     "gfontsel"
				   "xfontsel")
  "*The command used by `x-select-font' to select a font.
The command should be one of those listed in
`x-select-font-command-line-alist'."
  :type `(choice
	  ,@(mapcar (lambda (entry)
		      (list 'const :format "%v\n" (car entry)))
		    x-select-font-command-line-alist)
	  (string :tag "other"))
  :group 'x)

(defun x-select-font (&optional initial filter)
  "Select a font using `x-select-font-command'.
The font initially selected in the font dialog can optionally be set
with INITIAL if supported by `x-font-select-font-command'.  The range of
fonts to choose from can be limited by providing a FILTER, if supported.
The filter should be a partially qualified XLFD font name."
  (with-temp-buffer
    (let* ((command-line
	    (assoc x-select-font-command x-select-font-command-line-alist))
	   (fixed-args (if command-line (nth 1 command-line)))
	   (initial-switch (if command-line (nth 2 command-line)))
	   (filter-switch (if command-line (nth 3 command-line)))
	   (args (append (list fixed-args)
			 (if (and filter filter-switch)
			     (if (stringp filter-switch)
				 (list filter-switch filter)
			       filter))
			 (if (and initial initial-switch)
			     (if (stringp initial-switch)
				 (list initial-switch initial)
			       initial)))))
      (apply 'call-process x-select-font-command nil t nil args)
      (buffer-string))))

(defcustom x-select-font-refine-menu-limit 20
  "*Limit on the size of the font refine menu.
When `x-select-font' is used to choose a font in a context that requires
a single font to match, there is a possibility that the pattern returned
from `x-select-font' matches multiple fonts.  This variable sets an upper
limit on the number of fonts that can be matched by the return value
of `x-select-font' before an error is thrown."
  :type 'integer
  :group 'x)

(defun x-select-font-refine-with-menu (fonts menu-pos)
  "Refine a list of fonts by popping up a menu."
  (let ((font-list fonts)
	font-refine-menu
	this-font)
    (while font-list
      (setq this-font (car font-list) font-list (cdr font-list))
      (setq font-refine-menu (cons (list this-font this-font)
				   font-refine-menu)))
    (setq font-refine-menu (cons "Refine Font"
				 (list (append '("Font List")
					       font-refine-menu))))
    (x-popup-menu menu-pos font-refine-menu)))

(defun x-select-single-font (&optional initial filter)
  "Select a single font, using `x-select-font-command'.
If neccesary, pop up a menu to refine the choices further."
  (interactive)
  ;; Take note of the mouse position now while the frame is active.
  ;; Translate it to what x-popup-menu expects.
  (let* ((menu-pos (mouse-pixel-position))
	 (menu-pos-window (car menu-pos))
	 (menu-pos-x (car (cdr menu-pos)))
	 (menu-pos-y (cdr (cdr menu-pos)))
	 (menu-pos-expected-format (list
				    (list (if menu-pos-x menu-pos-x
					    0)
					  (if menu-pos-y menu-pos-y
					    0))
				    menu-pos-window))
	 (font-list (x-list-fonts (x-select-font initial filter)))
	 (nfonts (length font-list)))
    (cond ((eq font-list nil)
	   (error "No fonts match."))
	  ((eq nfonts 1)
	   (car font-list))
	  ((< nfonts x-select-font-refine-menu-limit)
	   (car (x-select-font-refine-with-menu
		 font-list menu-pos-expected-format)))
	  (t
	   (error "Too many fonts match.")))))


;; Replacement mouse-set-font ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; The following adds an extra submenu with a single option, which
;; launches the font dialog.  It would be nicer to do this with
;; an item on the main menu instead of a submenu, but that involves
;; more code changes.

(setq x-fixed-font-alist (append x-fixed-font-alist '(("More fonts" ("Choose..." . x-select-single-font)))))

(defun mouse-set-font (&rest fonts)
  "Select an emacs font from a list of known good fonts and fontsets."
  (interactive
   (and (display-multi-font-p)
	(let ((selected-font (x-popup-menu
			      last-nonmenu-event
			      ;; Append list of fontsets currently defined.
			      (append x-fixed-font-alist
				      (list (generate-fontset-menu))))))
	  (if (functionp selected-font)
	      (list (call-interactively selected-font))
	    selected-font))))
  (if fonts
      (let (font)
	(while fonts
	  (condition-case nil
	      (progn
		(set-default-font (car fonts))
		(setq font (car fonts))
		(setq fonts nil))
	    (error
	     (setq fonts (cdr fonts)))))
	(if (null font)
	    (error "Font not found")))
    (message "Cannot change fonts on this display")))


;; Customize Faces ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Customize options that are relevant.
;; :family :width :height :weight :slant
;;
;; Ideas so far.
;; Can use x-compose-font-name, x-decompose-font-name
;; How to get current values of widgets?
;; How to change widget values?


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> I think these are the most important tasks in etc/TODO.

Thanks for the list.  Another highly missing feature is Native Language
Support.  Please, consider to add to the list:

*** TODO.~1.37.~	Sat Mar 16 11:05:54 2002
--- TODO	Sun Mar 17 10:13:41 2002
***************
*** 117,123 ****
  
  * Investigate using the language environment (or locale?) to set up
    more things, such as the default Ispell dictionary, calendar
!   holidays...
  
  * Improve the GC (generational, incremental).  (We may be able to use
    the Boehm collector.)
--- 117,125 ----
  
  * Investigate using the language environment (or locale?) to set up
    more things, such as the default Ispell dictionary, calendar
!   holidays, quoting characters...
! 
! * Add Native Language Support (NLS).
  
  * Improve the GC (generational, incremental).  (We may be able to use
    the Boehm collector.)

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> It looks like pcomplete potentially has useful features.
> But it is not ready for adoption now as the default.

I'm a little surprised by this conclusion.  So far, it appeared to me
that some of the pcomplete variables had the wrong default values,
but I don't recall anything that couldn't be fixed by frobbing some
variables.

How about giving John a chance to frob the variables to make the
behavior more similar to the old completion behavior?

kai
-- 
Silence is foo!

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    I have still not got my head around the face customization code to
    try to slot this in there.  But I have got this working for
    mouse-set-font.

Can you first arrange for this to operate on a specified face?  Then
you could hook it into list-faces-display, so that you click on the
line which displays a particular face and it would operate on that
face.

Then it would be nice also to be able to specify colors, underline,
and other face attributes.  Then this feature will be complete.

I wonder, though, what interface do other word processors provide
for doing this job?


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Eli Zaretskii]

On Sun, 17 Mar 2002, Richard Stallman wrote:

>     I have still not got my head around the face customization code to
>     try to slot this in there.  But I have got this working for
>     mouse-set-font.
> 
> Can you first arrange for this to operate on a specified face?  Then
> you could hook it into list-faces-display, so that you click on the
> line which displays a particular face and it would operate on that
> face.

It could be useful, in addition, to be able to click on text in some 
special way (e.g., with some modifier, like M-mouse-1), and be able to 
customize the face(s) of that text.  That would help users who don't know 
about list-faces-display.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    How about giving John a chance to frob the variables to make the
    behavior more similar to the old completion behavior?

Everyone has a chance to do this, but I don't want it installed
until people report to me that it really is the right behavior.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    ! * Add Native Language Support (NLS).

I agree.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Richard Stallman]

    It could be useful, in addition, to be able to click on text in some 
    special way (e.g., with some modifier, like M-mouse-1), and be able to 
    customize the face(s) of that text.  That would help users who don't know 
    about list-faces-display.

That seems like a useful feature.  The same command could do this job
and also handle clicking on a line in list-faces-display.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [friedman@splode.com: some other observations on pcomplete]

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     How about giving John a chance to frob the variables to make the
>     behavior more similar to the old completion behavior?
>
> Everyone has a chance to do this, but I don't want it installed
> until people report to me that it really is the right behavior.

Noah,

does the new completion in shell mode do the right thing when you
(setq pcomplete-cycle-completions nil)?

kai
-- 
Silence is foo!

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel