Re: Assignment of misc packages for emacs

Re: Assignment of misc packages for emacs

[Kim F. Storm]

I've CC:ed this to emacs-devel [I've offered a number of packages for
inclusion with emacs], as there are some requests for comments from
the other developers.

Richard Stallman <rms@gnu.org> writes:

>     - - struct.el [medium]
>     which is a structed binary data packing/unpacking package, primarily
>     for usage with the networking part of emacs.  I wrote this while
>     enhancing the networking part of emacs to support async connections
>     and datagrams.  I don't know whether this is covered by my general
>     assignment, or you need separate papers?
> 
>     - - kmacro.el [medium]
>     which is a more user friendly front-end to emacs' keyboard macro
>     feature with added features.
> 
> Could you tell me more?  This might be interesting.

It basically works by placing all keyboard macro commands on two
function keys -- for easy access.  Before doing this, I rarely used
keyboard macros, but after moving them to function keys, I use them
all the time:

To start recording a keyboard macro, use F5  [like C-x (].
To end a keyboard macro, use F6  [like C-x )].

.. this is the first simplification -- using single keys to start and
end keyboard macros makes it much easier to use them also for minor
changes.

To call the last keyboard macro, use F6  [like C-x e].

.. this is the second simplification -- to execute the macro
immediately (I often do this if the same change applies to a number of
successive lines), just press the same key which ended the last
keyboard macro.  And to repeat it again, press F6 again.  etc.  [works
with numeric prefix arg as well].


Now, while defining the keyboard macro, F5 will insert 0.  The first
time the macro is called, it will insert a 1 instead of the 0; a 2 is
inserts on the second call, etc.

The initial value to be inserted can be set via a numeric prefix
argument to F5 (when starting the keyboard macro), and each use of F5
inside the keyboard macro will increase the internal counter by 1 - or
by the numeric prefix argument to F5.

The macro counter can also be set directly with C-F1.

The default format for the inserted number is %d, but can
be redefined using S-F6.

The previous keyboard macro is available on S-F6, i.e. you can
define two keyboard macros and execute the latest with F6 and the
other with S-F6.

The last keyboard macro can be edited with M-F6  [C-x C-k].

Finally, kmacro maintains a keymacro ring which can be rotated
(and displayed) using C-F6.

> 
>     - - ido.el [large]
>     which is a package similar to iswitchb.el, but allowing both
>     buffer switching and opening of files with a minimum of keystrokes.
> 
> I think we have plenty of things like this.

Yes, but ido.el is still unique in the sense that it does for
opening files what iswitchb does for switching buffers [but it is
implemented as a superset of iswitchb to unify switching buffers
and files].

I get very positive feedback from the users of ido!!!

I know that some of the other people on emacs-devel use ido --
please speak up if you find it useful.


> 
>     - - match.el [large]
>     which is a menu-based alternative to the grep package with more
>     features and a simpler interface
> 
> Could you tell me more?

The first visible difference between M-x grep and M-x match is the
way it is called.

Where M-x grep prompts for a command line, M-x match prompts for a
search pattern (offering the current word from the selected buffer as
default), a file pattern (with predefined abbreviations, e.g. `ch'
searches all .c and .h files), and a base directory where to start the
recursive search.

Match will then recurse through all subdirectories of the specified
directory, grepping for the specified search pattern in the specified
files.

As a result, it presents a buffer with all the matching lines [like
M-x grep does], but it has a command set which is specifically
tailored to navigating through the matches, e.g.

SPC, n - shows the next match in the other window (but keeps the match
buffer active).  It temporarily highlights the matching text in the
other window.

b - shows the previous match (i.e. n/b goes forward/backward through
the matches).

TAB - skips over remaining matches in the current file, and shows the
first match in the next file in the list of matches.

left / right - scroll other window backward/forward (this is a
convenient way to look at the context of the current match).

/ <string> - replaces the current match with <string>

 - replaces the current match with the last string defined by /

        ... i.e. using n n . n n n . n n . n  etc  is a simple
        way to replace selected matches in multiple files.

RET - jump to the current match in the other window (so it can be edited).

H-n / H-b - jump to next/previous match (can be used in any buffer).

S-H-n - jump to the match menu buffer.

The mouse can also be used to navigate using the match menu buffer.


> 
>     - - find-char.el [small]
>     which provides find char forward and backward commands similar
>     to vi's f and b commands.
> 
> It can't hurt to have these functions available in Emacs for those
> who prefer them.
> 
>     - - begendol.el [small]
>     which provides alternatives to the interactive beginning-of-line and
>     end-of-line with added functionality (e.g. repeating C-a will jump
>     between the left margin and the indentation).
> 
> This would be interesting if and only if we would want to make it the
> default.  How about asking people on emacs-devel whether they like
> this change?

Ok, then let me explain more of the functionality:

Enhanced C-a:

The first C-a always jumps to the beginning of the line (even if the cursor is
already there -- this is so keyboard macros can consistenly depend on
where C-a moves).

The second C-a jumps over any indentation on the current line.

Subsequent C-a's will jump between the beginning of the line and the indentation.

.. I find this very convenient.

Enhanced C-e:

The first C-e always jumps to the end of the line (for the same reason
as explained above).

Subsequent C-e's moves one character backwards on the line until the
cursor reaches the beginning of the line (in which case it jumps to
the end of the line).

If I regret the multiple C-e's I use C-a C-e to go to the end of the
line (but C-u C-e will also work -- or any other movement).

... I often find I need to go to a character near the end of the 
line (e.g. before a `)' or a `.', and I find it very convenient to
simply do a few C-e C-e C-e's to get there.

What do other people think?

> 
>     - - minimenu.el [small]
>     which provides simple menu prompting in the minibuffer
> 
> Could you tell me more?

It makes it easy for other packages to prompt with something like

EMACS file: c)ommon u)ser i)nit p)re .)emacs cus(t)om l)isp e(x)ec s)rc

in the minibuffer and then take different actions depending on whether
the user enters c, u, i, p, ., t, l, x, or s.

(This example is a quick emacs navigation function I have bound to C-x C-g
which I use all the time, e.g.

        C-x C-g .

opens my .emacs file.
        

> 
>     - - colordif.el [small]
>     which adds color to (vc) diff output
> 
> Do we want to install this unconditionally in diff.el?
> If so, it is good.

It is fully customizable, so I don't see why not.

> 
>     - - copy-above.el [small]
>     which allows easy copying of chars, words, and to end of line 
>     from the line above the current line.
> 
> It can't hurt to have these functions available in Emacs for those
> who prefer them.
> 
> 

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

Re: Assignment of misc packages for emacs

[Alex Schroeder]

storm@cua.dk (Kim F. Storm) writes:

>>     - - kmacro.el [medium]

Reading the description, it seems like an easier user interface.
Perhaps the keys need to be changed, but having the autoincrement
stuff available that easily would help a lot of non-elisp users.

Other people could probably do this by using a keyboardmarco and then
calling query-replace-regexp-eval.  For newbies, Kim's UI seems
better.

>>     - - ido.el [large]

I tried it, and did not like it.  It is mentioned a lot on newsgroups
and #emacs, however, thus I assume that a lot of people use it.

>>     - - match.el [large]

Yes, a better user interface to grep and friends is needed.  The best
I usually recommend to newbies is dired, include subdirectories into
the buffer, and then use dired-do-query-replace-regexp.  Since the
recursion is not automatic, this involves too many steps.  Kim's UI
seems better.  Plus he seems to have better navigation (which we might
want to add to plain grep and compile buffers anyway).

>>     - - find-char.el [small]

Hm, I never zap to characters, thus in those rare cases when I need to
do it, I just use isearch.  A bit more keys, but who cares...  Vi
lovers can use viper, IMHO.  :)

>>     - - begendol.el [small]

Seems like an interesting addition.  I would prefer to try it first,
though.

>>     - - minimenu.el [small]

I think this is only usefull for elisp programmers, and those people
might want to add for a better user interface.  Personally, I got used
to these multi-letter minimenus in query-replace, but I don't really
"like" them.  It would be better to make such things available via
menus, or completion, IMHO.  The example cited by Kim is good, I
guess, but what newbies would like is some functionality like
"favorite files" (a better interface to bookmarks) or "recent
documents" (make recentf the default), I think.  Or perhaps even an
augmented bookmark interface that allows you to "bookmark" keyboard
macros.  Thus you could "bookmark" C-x C-f ~/.emacs as well as M-x
gnus-no-server.

>>     - - colordif.el [small]

VC diff output is already colored in my Emacs.  Plain diff is not,
however.  Thus I think that the mechanism used for VC diff should be
used for plain diff as well.  Perhaps colordif does exactly that, but
introducing new diff faces, for example, would be confusing.

>>     - - copy-above.el [small]

I don't see a need for that, I rarely do similar task using kill/yank.
Thus assume this is not too important.



The most important part is, I believe, the UI improvements to some of
the features Emacs already provides.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: Assignment of misc packages for emacs

[Miles Bader]

Alex Schroeder <alex@emacswiki.org> writes:
> >>     - - colordif.el [small]
> 
> VC diff output is already colored in my Emacs.  Plain diff is not,
> however.  Thus I think that the mechanism used for VC diff should be
> used for plain diff as well.

Also note that `diff-mode', which is what VC diffs are `colorized' with,
also offers many useful features for manipulating diffs -- navigation,
applying/unapplying of hunks, format conversion, direction reversal, and
even sane editing of the diff file [it automatically adjusts the line
counts for you].  It's quite snazzy...

There was some small issue that interfered with it being used for `M-x
diff' output, but my vague memory is that it was pretty trivial (my
recollection is that I thought the proper solution was to say `fuck it'
and use diff-mode anyway).

Perhaps Stefan can fill in the details.

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> Also note that `diff-mode', which is what VC diffs are `colorized' with,
> also offers many useful features for manipulating diffs -- navigation,
> applying/unapplying of hunks, format conversion, direction reversal, and
> even sane editing of the diff file [it automatically adjusts the line
> counts for you].  It's quite snazzy...
> 
> There was some small issue that interfered with it being used for `M-x
> diff' output, but my vague memory is that it was pretty trivial (my
> recollection is that I thought the proper solution was to say `fuck it'
> and use diff-mode anyway).

I personally use the patch below but never bothered to try and
make it into something good enough to install.  I don't even know
what is missing (if anything).
I don't have it high on my todo list, so if anybody wants to see
it happen, he'd better do it himself,


	Stefan


Index: diff.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/diff.el,v
retrieving revision 1.43
diff -u -r1.43 diff.el
--- diff.el	11 Oct 2001 01:20:16 -0000	1.43
+++ diff.el	8 May 2002 01:44:00 -0000
@@ -91,11 +91,8 @@
   ;; Don't reparse diffs already seen at last parse.
   (if compilation-parsing-end (goto-char compilation-parsing-end))
 
-  ;; Construct in REGEXP a regexp composed of all those in dired-regexp-alist.
-  (let ((regexp (mapconcat (lambda (elt)
-			     (concat "\\(" (car elt) "\\)"))
-			   diff-regexp-alist
-			   "\\|"))
+  ;; Construct in REGEXP a regexp composed of all those in diff-regexp-alist.
+  (let ((regexp (mapconcat 'car diff-regexp-alist "\\|"))
 	;; (GROUP-IDX OLD-IDX NEW-IDX)
 	(groups (let ((subexpr 1))
 		  (mapcar (lambda (elt)
@@ -190,7 +187,7 @@
   "Find and display the differences between OLD and NEW files.
 Interactively the current buffer's file name is the default for NEW
 and a backup file for NEW is the default for OLD.
-With prefix arg, prompt for diff switches."
+With prefix arg, prompt for diff SWITCHES."
   (interactive
    (nconc
     (let (oldf newf)
@@ -247,16 +244,23 @@
 				  "No more differences" "Diff"
 				  'diff-parse-differences))
 	  (set-buffer buf)
+	  ;; Replace compilation-mode with diff-mode + compilation-minor-mode.
+	  (diff-mode)
+	  (compilation-shell-minor-mode -1) ;diff-mode turned it on.
+	  (compilation-minor-mode 1)
+	  (set (make-local-variable 'compilation-parse-errors-function)
+	       'diff-parse-differences)
+	  (set (make-local-variable 'compilation-error-message)
+	       "No more differences")
+	  ;; Continue as if nothing had happened.
 	  (set (make-local-variable 'diff-old-file) old)
 	  (set (make-local-variable 'diff-new-file) new)
 	  (set (make-local-variable 'diff-old-temp-file) old-alt)
 	  (set (make-local-variable 'diff-new-temp-file) new-alt)
 	  (set (make-local-variable 'compilation-finish-function)
-	       (function (lambda (buff msg)
-			   (if diff-old-temp-file
-			       (delete-file diff-old-temp-file))
-			   (if diff-new-temp-file
-			       (delete-file diff-new-temp-file)))))
+	       (lambda (buff msg)
+		 (if diff-old-temp-file (delete-file diff-old-temp-file))
+		 (if diff-new-temp-file (delete-file diff-new-temp-file))))
 	  ;; When async processes aren't available, the compilation finish
 	  ;; function doesn't get chance to run.  Invoke it by hand.
 	  (or (fboundp 'start-process)

Re: Assignment of misc packages for emacs

[Richard Stallman]

    There was some small issue that interfered with it being used for `M-x
    diff' output, but my vague memory is that it was pretty trivial (my
    recollection is that I thought the proper solution was to say `fuck it'
    and use diff-mode anyway).

It seems strange to have a Diff mode and not use it for M-x diff-mode.
Could someone please find out or figure out what drawback discouraged
us from doing this before?

Re: Assignment of misc packages for emacs

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> Yes, but ido.el is still unique in the sense that it does for
> opening files what iswitchb does for switching buffers [but it is
> implemented as a superset of iswitchb to unify switching buffers
> and files].
>
> I get very positive feedback from the users of ido!!!
>
> I know that some of the other people on emacs-devel use ido --
> please speak up if you find it useful.

Will do :-)  Yes, if iswitchb is in Emacs, then ido is the obvious
extension.  I guess that people who like iswitchb will also like
ido.  It makes the completion of C-x b and C-x C-f more similar.

kai
-- 
Silence is foo!

Re: Assignment of misc packages for emacs

[Richard Stallman]

If ido fits well as an extension of iswitchb, then let's install it.

Re: Assignment of misc packages for emacs

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> >     - - struct.el [medium]

This sounds like a nice feature, but I think (as I've mentioned before)
that it should be renamed, since `struct' is generally used to refer to
refer to lisp structures, such as those created by `defstruct' (in cl).

> >     - - begendol.el [small]
> 
> Enhanced C-a: Subsequent C-a's will jump between the beginning of the line and the indentation.
> Enhanced C-e: Subsequent C-e's moves one character backwards on the line.

This sounds far too wierd to be any kind of default.  [I'm even
skeptical whether they'd ever get used; they seem like very `personal'
definitions.]

> >     - - colordif.el [small]
> >     which adds color to (vc) diff output
> > 
> > Do we want to install this unconditionally in diff.el?  If so, it is good.
>
> It is fully customizable, so I don't see why not.

I agree with Alex, that it's better to use the existing `diff-mode' for
`M-x diff' output (it's already used for VC diff output).

All the other packages you mentioned sound reasonable.

-Miles
-- 
I have seen the enemy, and he is us.  -- Pogo

Re: Assignment of misc packages for emacs

[Thien-Thi Nguyen]

Miles Bader <miles@lsi.nec.co.jp> writes:

   This sounds far too wierd to be any kind of default.  [I'm even
   skeptical whether they'd ever get used; they seem like very `personal'
   definitions.]

well, i use codeline.el which is similar.  if you get some huge defun that
flows like a river through many screenfuls, this kind of thing is useful for
jumping to the banks and back, for commenting stuff out, etc.  i agree that
the specifics are personal muscle-memory preferences, however...

thi

Re: Assignment of misc packages for emacs

[Richard Stallman]

The keyboard macro changes sound good.  Let's install them
(once you send papers).

Re: Assignment of misc packages for emacs

[Richard Stallman]

    Where M-x grep prompts for a command line, M-x match prompts for a
    search pattern (offering the current word from the selected buffer as
    default), a file pattern (with predefined abbreviations, e.g. `ch'
    searches all .c and .h files), and a base directory where to start the
    recursive search.

Others have suggested such an interface, but I am not sure it is
really more convenient than the current interface.  Why do you find it
better?

I am not sure it is worth reading the directory rather than just using
the current directory.

    As a result, it presents a buffer with all the matching lines [like
    M-x grep does], but it has a command set which is specifically
    tailored to navigating through the matches, e.g.

    SPC, n - shows the next match in the other window (but keeps the match
    buffer active).  It temporarily highlights the matching text in the
    other window.

This feature seems to be orthogonal to the command argument interface.
Perhaps you can add such features to Compilation mode.  It would be
better not to use printing characters as commands, though.

    Enhanced C-a:

    The first C-a always jumps to the beginning of the line (even if the cursor is
    already there -- this is so keyboard macros can consistenly depend on
    where C-a moves).

I don't like this.

    >     - - minimenu.el [small]
    >     which provides simple menu prompting in the minibuffer
    > 
    > Could you tell me more?

    It makes it easy for other packages to prompt with something like

    EMACS file: c)ommon u)ser i)nit p)re .)emacs cus(t)om l)isp e(x)ec s)rc

    in the minibuffer and then take different actions depending on whether
    the user enters c, u, i, p, ., t, l, x, or s.

This sounds like the existing feature for handling menus on character
ttys.  Could you see how they compare?

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Where M-x grep prompts for a command line, M-x match prompts for a
>     search pattern (offering the current word from the selected buffer as
>     default), a file pattern (with predefined abbreviations, e.g. `ch'
>     searches all .c and .h files), and a base directory where to start the
>     recursive search.
> 
> Others have suggested such an interface, but I am not sure it is
> really more convenient than the current interface.  Why do you find it
> better?

I find it much easier to use (that's why I wrote it :-).
Let me give you an example (based on CVS emacs sources):

I'm visiting  ~/fsf/emacs/lwlib/xlwmenu.c
On line 1625, there is a call to the function x_free_dpy_colors.
I want find out where it is defined & used elsewhere.

I place the cursor on the name of the function and enters M-x match
(I've bound it to H-m).

It prompts me for the word to search for.  Since the current word is
the default, I just hit RET.

It prompts me for the files to search in.  It suggests `ch' (or whatever
I used last), meaning all *.[ch] files.  This is what I want, so I just
hit RET again.

It now prompts for the directory to base the search:
The default is ~/fsf/emacs/lwlib/, but I want to search in all
the emacs source files, so I use M-DEL to get ~/fsf/emacs/ and
hit RET.

As a result, it shows me this menu:

 cd ~/fsf/ebuild/
 
>./lwlib/xlwmenu.c:69:extern void x_free_dpy_colors __P ((Display *, Screen *, Colormap,
 ./lwlib/xlwmenu.c:1625:		  x_free_dpy_colors (dpy, screen, cmap,
 ./lwlib/xlwmenu.c:1635:		  x_free_dpy_colors (dpy, screen, cmap,
 ./lwlib/xlwmenu.c:1650:	  x_free_dpy_colors (dpy, screen, cmap, &mw->menu.top_shadow_color, 1);
 ./lwlib/xlwmenu.c:1661:	  x_free_dpy_colors (dpy, screen, cmap,
 ./lwlib/xlwmenu.c:1696:    x_free_dpy_colors (dpy, screen, cmap, px, i);
 ./src/xfaces.c:708:x_free_dpy_colors (dpy, screen, cmap, pixels, npixels)
 ./src/xterm.c:3478:      x_free_dpy_colors (DisplayOfScreen (screen), screen, cmap,
 ./src/xterm.h:1088:extern void x_free_dpy_colors P_ ((Display *, Screen *, Colormap,

I find this very easy to use; compare:

        M-x match RET RET RET M-DEL RET

to using e.g
        
        M-x grep-find RET x_free_dpy_colors RET

The latter doesn't (easily) allow you to start the search in another
directory, and it finds (duplicate) matches in backup files (such as
xterm.c~), and IMO the prompt is _completely obscure_ unless you are a
UNIX shell expert...

> 
> I am not sure it is worth reading the directory rather than just using
> the current directory.

This is VERY useful (I use it very often), and to use the current
directory, just hit RET.

> 
>     As a result, it presents a buffer with all the matching lines [like
>     M-x grep does], but it has a command set which is specifically
>     tailored to navigating through the matches, e.g.
> 
>     SPC, n - shows the next match in the other window (but keeps the match
>     buffer active).  It temporarily highlights the matching text in the
>     other window.
> 
> This feature seems to be orthogonal to the command argument interface.

Yes, you could argue that this is a separate issue -- but I think the 
menu need to be efficient to get the maximum usability...

> Perhaps you can add such features to Compilation mode.  It would be
> better not to use printing characters as commands, though.

I could do that, but we had a lengthy discussion a while back on
what commands to add to compilation mode, and I think there was
some resistence to "improve" it.  But I'll check up on that,
and see what can be done  (M-x match does use compile-internal).

> 
>     Enhanced C-a:
> 
>     The first C-a always jumps to the beginning of the line (even if the cursor is
>     already there -- this is so keyboard macros can consistenly depend on
>     where C-a moves).
> 
> I don't like this.

What don't you like?
That C-a jumps between the beginning of line and indentation,
or the specific behaviour you quote above.


> 
>     >     - - minimenu.el [small]
>     >     which provides simple menu prompting in the minibuffer
>     > 
>     > Could you tell me more?
> 
>     It makes it easy for other packages to prompt with something like
> 
>     EMACS file: c)ommon u)ser i)nit p)re .)emacs cus(t)om l)isp e(x)ec s)rc
> 
>     in the minibuffer and then take different actions depending on whether
>     the user enters c, u, i, p, ., t, l, x, or s.
> 
> This sounds like the existing feature for handling menus on character
> ttys.  Could you see how they compare?

I can see the similarity in functionality, but for the simple use for
which it is intended, I like mine better, as it is less intrusive and
more similar to a keymap "with intermediate help in echo area".

E.g. I have the following mini-menu bound to F8:

        QUERY: r)egexp s)tring t)ags  ALL: R)egexp S)tring

I.e. I only have to member that "replace" is on F8, instead of
the following commands:

F8 r => C-M-% (query-replace-regexp)
F8 s => M-% (query-replace)
F8 t => M-x tags-query-replace
F8 R => M-x replace-regexp
F8 S => M-x replace-string

To achieve this, I use the following code:

(defvar replace-mini-menu '(
  (:tag "QUERY:")
  (?r "r)egexp"	query-replace-regexp)
  (?s "s)tring"	query-replace)
  (?t "t)ags"	tags-query-replace)
  (:tag " ALL:")
  (?R "R)egexp"	replace-regexp)
  (?S "S)tring"	replace-string)))

(defun replace-menu ()
 "Run a replace command specified in replace-commands."
 (interactive)
 (mini-menu replace-mini-menu))

Re: Assignment of misc packages for emacs

[Miles Bader]

no-spam@cua.dk (Kim F. Storm) writes:
> E.g. I have the following mini-menu bound to F8:
> 
>         QUERY: r)egexp s)tring t)ags  ALL: R)egexp S)tring
> 
> (defvar replace-mini-menu '(...))

So it's basically equivalent to 

(defun mini-menu (menu)
  (message (mapconcat #'cadr menu "  "))
  (call-interactively (or (nth 2 (assoc (read-char) menu)) 
                          (error "Unknown key"))))

?

I'm not sure this warrants a whole separate package...  [does it do more?]

-MIles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> no-spam@cua.dk (Kim F. Storm) writes:
> > E.g. I have the following mini-menu bound to F8:
> > 
> >         QUERY: r)egexp s)tring t)ags  ALL: R)egexp S)tring
> > 
> > (defvar replace-mini-menu '(...))
> 
> So it's basically equivalent to 
> 
> (defun mini-menu (menu)
>   (message (mapconcat #'cadr menu "  "))
>   (call-interactively (or (nth 2 (assoc (read-char) menu)) 
>                           (error "Unknown key"))))

Essentially, yes.  There are a few more twists to it, but you got
the essentials right!

However, I was advocating for adding a very simple way for packages
to query the user for "trivial" selections as an alternative to
using keymaps and adding prompting at the same time...

> I'm not sure this warrants a whole separate package...  [does it do more?]

No, it could be added to simple.el if people agree.

However, there are a couple of functions using the mini-menu, two of
which have already been mentioned here:

F8 -> QUERY: r)egexp s)tring t)ags  ALL: R)egexp S)tring
C-x C-g -> EMACS file: .)emacs c)ustom l)isp s(i)te-lisp e(x)ec s)rc

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

Re: Assignment of misc packages for emacs

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I was advocating for adding a very simple way for packages to query
> the user for "trivial" selections as an alternative to using keymaps
> and adding prompting at the same time...

Sure.  There already quite a few existing `mini menus' in emacs, e.g.,
the query-replace `what should I do' prompt, and the various things in
Gnus (the gnus implemenation is particularly nice, I think).

They are generally slightly different than your code in that they don't
usually call a function based on the result, but rather just do some
dispatch on their own, but the concept is similar.  Additionally, most
of them seem to have a help function, so if you hit `?' or `C-h', a help
buffer is popped up.

So, perhaps we should think of unifying these all in some way, rather
than adding yet-another different implementation of the same thing.
Since most of the other cases (that I can think of) don't do a funcall,
what you want could be a layer on top of some shared `menu display and
prompting' function.

Maybe such a merge isn't a good idea, but I think it should at least be
thought about...

-Miles
-- 
Would you like fries with that?

Re: Assignment of misc packages for emacs

[Richard Stallman]

    > So it's basically equivalent to 
    > 
    > (defun mini-menu (menu)
    >   (message (mapconcat #'cadr menu "  "))
    >   (call-interactively (or (nth 2 (assoc (read-char) menu)) 
    >                           (error "Unknown key"))))

    Essentially, yes.  There are a few more twists to it, but you got
    the essentials right!

Are you saying that this new feature is implemented using the
HierarKey menu feature, as above?  That is good.

    However, I was advocating for adding a very simple way for packages
    to query the user for "trivial" selections as an alternative to
    using keymaps and adding prompting at the same time...

Could you send me the actual code?

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > So it's basically equivalent to 
>     > 
>     > (defun mini-menu (menu)
>     >   (message (mapconcat #'cadr menu "  "))
>     >   (call-interactively (or (nth 2 (assoc (read-char) menu)) 
>     >                           (error "Unknown key"))))
> 
>     Essentially, yes.  There are a few more twists to it, but you got
>     the essentials right!
> 
> Are you saying that this new feature is implemented using the
> HierarKey menu feature, as above?  That is good.

Since I wasn't aware of the HierarKey feature, it isn't...  (neither
is the above code).  But I'll change it to do that.

BTW, I've searched the documentation, lisp files, and source files,
it is very vague about these HierarKey menues...

> 
>     However, I was advocating for adding a very simple way for packages
>     to query the user for "trivial" selections as an alternative to
>     using keymaps and adding prompting at the same time...
> 
> Could you send me the actual code?

I'll play some more with the HierarKey feature before I do that.

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

Re: Assignment of misc packages for emacs

[Richard Stallman]

    C-x C-g -> EMACS file: .)emacs c)ustom l)isp s(i)te-lisp e(x)ec s)rc

Are you saying that CUA defines C-x C-g to do something other than
quit?  That is a very grave inconsistency.  Please reserve C-g for
quitting, and nothing but quitting.

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     C-x C-g -> EMACS file: .)emacs c)ustom l)isp s(i)te-lisp e(x)ec s)rc
> 
> Are you saying that CUA defines C-x C-g to do something other than
> quit?  That is a very grave inconsistency.  Please reserve C-g for
> quitting, and nothing but quitting.

This has nothing to do with CUA.

It is related to my mini-menu package which defines a command
"find-emacs-file-mini-menu" which shows the "EMACS...." prompt.

My personal binding for that command is C-x C-g, but I would never
suggest that as a default binding for anyone else.  

I.e. to open my .emacs file, I just enter C-x C-g . and to open
an emacs lisp file, e.g. simple.el, I use C-x C-g l simple.el RET

But it could be on any other key ...  It was just to illustrate
the simplicity of the mini menu interface.

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

Re: Assignment of misc packages for emacs

[Richard Stallman]

    So it's basically equivalent to 

    (defun mini-menu (menu)
      (message (mapconcat #'cadr menu "  "))
      (call-interactively (or (nth 2 (assoc (read-char) menu)) 
			      (error "Unknown key"))))

    ?

    I'm not sure this warrants a whole separate package...  [does it do more?]

If it does more than the built-in keyboard-based menu handling, I
think we should extend or improve the built-in keyboard-based menu
handling rather than providing two alternative similar features.

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     So it's basically equivalent to 
> 
>     (defun mini-menu (menu)
>       (message (mapconcat #'cadr menu "  "))
>       (call-interactively (or (nth 2 (assoc (read-char) menu)) 
> 			      (error "Unknown key"))))
> 
>     ?
> 
>     I'm not sure this warrants a whole separate package...  [does it do more?]
> 
> If it does more than the built-in keyboard-based menu handling, I
> think we should extend or improve the built-in keyboard-based menu
> handling rather than providing two alternative similar features.
> 

As I said in another mail, the HierarKey function could be
simplified, e.g. hitting M-g produces this prompt (my
frame is 132 character wide):

  Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 

With mini-menu, this would be much simpler, e.g.

  Set face: d)efault b)old i)talic bo(l)d-italic u)ndeline o)ther ...

I guess we could hack the HierarKey menus to look like that --
then mini-menu would definitely have no purpose at all!

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

Re: Assignment of misc packages for emacs

[Eli Zaretskii]

On 15 May 2002 no-spam@cua.dk wrote:

> I'm visiting  ~/fsf/emacs/lwlib/xlwmenu.c
> On line 1625, there is a call to the function x_free_dpy_colors.
> I want find out where it is defined & used elsewhere.
> 
> I place the cursor on the name of the function and enters M-x match
> (I've bound it to H-m).

Isn't this a job for ID-utils (which have an Emacs interface)?  Once 
you've created the ID database by running mkid, the searches are 
lightning-fast and very accurate (because mkid knows about tokens in 
various programming languages including C).

Perhaps we should make the ID-utils interface part of Emacs, and expand 
it to present a menu of possibilities.

Re: Assignment of misc packages for emacs

[Andreas Schwab]

Eli Zaretskii <eliz@is.elta.co.il> writes:

|> Perhaps we should make the ID-utils interface part of Emacs, and expand 
|> it to present a menu of possibilities.

We already have etags, which is pretty similar.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Assignment of misc packages for emacs

[Eli Zaretskii]

On Wed, 15 May 2002, Andreas Schwab wrote:

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> |> Perhaps we should make the ID-utils interface part of Emacs, and expand 
> |> it to present a menu of possibilities.
> 
> We already have etags, which is pretty similar.

No.  etags only records _definitions_ of functions, macros, typedefs, 
etc.  It does not record where they are _used_, and it by default doesn't 
record local variables.

By contrast, mkid records _all_ tokens, no matter what their usage is.  
So if you want to know where is some function _called_ etags won't help, 
but ID will.

I always think about ID-utils as a language-aware Grep.

Re: Assignment of misc packages for emacs

[Andreas Schwab]

Eli Zaretskii <eliz@is.elta.co.il> writes:

|> By contrast, mkid records _all_ tokens, no matter what their usage is.  
|> So if you want to know where is some function _called_ etags won't help, 
|> but ID will.

Thanks, I didn't know about this feature.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 15 May 2002 no-spam@cua.dk wrote:
> 
> > I'm visiting  ~/fsf/emacs/lwlib/xlwmenu.c
> > On line 1625, there is a call to the function x_free_dpy_colors.
> > I want find out where it is defined & used elsewhere.
> > 
> > I place the cursor on the name of the function and enters M-x match
> > (I've bound it to H-m).
> 
> Isn't this a job for ID-utils (which have an Emacs interface)?  Once 
> you've created the ID database by running mkid, the searches are 
> lightning-fast and very accurate (because mkid knows about tokens in 
> various programming languages including C).

Yes, ID-utils is a great package, and I would love to see it come
standard with emacs!

But even when I use ID-utils, I often find I fall back to using M-x match.

> 
> Perhaps we should make the ID-utils interface part of Emacs, and expand 
> it to present a menu of possibilities.

Good idea.  And do the same for etags (I already have code
for this, but unfortunately using a different tags program)!

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

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> I'm visiting  ~/fsf/emacs/lwlib/xlwmenu.c
> On line 1625, there is a call to the function x_free_dpy_colors.
> I want find out where it is defined & used elsewhere.

Note that apart from M-x grep and M-x match there's also M-x igrep that
tries to solve the same kind of problem(s).

> I find this very easy to use; compare:
>         M-x match RET RET RET M-DEL RET
> to using e.g
>         M-x grep-find RET x_free_dpy_colors RET

I personally use

	C-u M-x grep RET <edit things to look like ../**/*.[ch]> RET

> The latter doesn't (easily) allow you to start the search in another
> directory, and it finds (duplicate) matches in backup files (such as
> xterm.c~), and IMO the prompt is _completely obscure_ unless you are a
> UNIX shell expert...

Agreed, that's why I prefer zsh's ** construct.  I think C-u M-x grep RET
should be more aggressive in its choice of initial command (it only
chooses the files' extension for you the first time you invoke it).
The reason why it's so conservative was because I wanted to install
my code without having to convince anybody that the new behavior was better
so I kept 100% compatibility with the old behavior.

> > I am not sure it is worth reading the directory rather than just using
> > the current directory.
> This is VERY useful (I use it very often), and to use the current
> directory, just hit RET.

I must say that I generally prefer the C-u M-x grep approach which does
not force you into a series of questions, but just presents you with
the "complete default" and lets you edit it to your liking.

> >     As a result, it presents a buffer with all the matching lines [like
> >     M-x grep does], but it has a command set which is specifically
> >     tailored to navigating through the matches, e.g.
> > 
> >     SPC, n - shows the next match in the other window (but keeps the match
> >     buffer active).  It temporarily highlights the matching text in the
> >     other window.
> > 
> > This feature seems to be orthogonal to the command argument interface.
> 
> Yes, you could argue that this is a separate issue -- but I think the 
> menu need to be efficient to get the maximum usability...

You're probably right that we should improve the compilation-mode's support
for such browsing.  Maybe only for *grep* buffers, but maybe not.
But that just means rebinding next-error (and previous-error) to more
keys than just C-x `.

> I can see the similarity in functionality, but for the simple use for
> which it is intended, I like mine better, as it is less intrusive and
> more similar to a keymap "with intermediate help in echo area".

I'm still not clear how it compares to HierarKey menus
(see PCL-CVS's `d' prefix or the M-g prefix in the global map).
Hmm... they don't seem to work here any more.  Maybe I messed something
up with some of my keymap.c changes.  Anyway, you can try it
on Emacs-21.2 where it still works.


	Stefan

Re: Assignment of misc packages for emacs

[Andreas Schwab]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

|> > I'm visiting  ~/fsf/emacs/lwlib/xlwmenu.c
|> > On line 1625, there is a call to the function x_free_dpy_colors.
|> > I want find out where it is defined & used elsewhere.
|> 
|> Note that apart from M-x grep and M-x match there's also M-x igrep that
|> tries to solve the same kind of problem(s).
|> 
|> > I find this very easy to use; compare:
|> >         M-x match RET RET RET M-DEL RET
|> > to using e.g
|> >         M-x grep-find RET x_free_dpy_colors RET
|> 
|> I personally use
|> 
|> 	C-u M-x grep RET <edit things to look like ../**/*.[ch]> RET

Another easy interface is M-x tags-search if you already have a TAGS file.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Assignment of misc packages for emacs

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

Re: M-x match --

> 
> I personally use
> 
> 	C-u M-x grep RET <edit things to look like ../**/*.[ch]> RET
> 
> > The latter doesn't (easily) allow you to start the search in another
> > directory, and it finds (duplicate) matches in backup files (such as
> > xterm.c~), and IMO the prompt is _completely obscure_ unless you are a
> > UNIX shell expert...
> 
> Agreed, that's why I prefer zsh's ** construct.  I think C-u M-x grep RET
> should be more aggressive in its choice of initial command (it only
> chooses the files' extension for you the first time you invoke it).
> The reason why it's so conservative was because I wanted to install
> my code without having to convince anybody that the new behavior was better
> so I kept 100% compatibility with the old behavior.

I've never liked M-x grep for the very reason that I have to edit the command.

> 
> > > I am not sure it is worth reading the directory rather than just using
> > > the current directory.
> > This is VERY useful (I use it very often), and to use the current
> > directory, just hit RET.
> 
> I must say that I generally prefer the C-u M-x grep approach which does
> not force you into a series of questions, but just presents you with
> the "complete default" and lets you edit it to your liking.

One additional trick is that M-x match prompts you for the directory
using ido-read-directory, meaning that it is very easy to navigate to
a completely different base directory.

> > Yes, you could argue that this is a separate issue -- but I think the 
> > menu need to be efficient to get the maximum usability...
> 
> You're probably right that we should improve the compilation-mode's support
> for such browsing.  Maybe only for *grep* buffers, but maybe not.
> But that just means rebinding next-error (and previous-error) to more
> keys than just C-x `.

Right.  I'll look at the new grep code (I wasn't aware that grep had been
rewritten) as well as my own code again to see whether I can enhance the
standard code rather than add a separate package.

BTW, M-x match uses jit-lock to fontify the matches in the *Match*
buffer.  And when you visit a match, it is temporarily highlighted in
the target buffer (using an overlay).


Re: mini-menu --

> 
> > I can see the similarity in functionality, but for the simple use for
> > which it is intended, I like mine better, as it is less intrusive and
> > more similar to a keymap "with intermediate help in echo area".
> 
> I'm still not clear how it compares to HierarKey menus
> (see PCL-CVS's `d' prefix or the M-g prefix in the global map).

I wasn't aware of the HierarKey feature (it's a very well hidden "fact").

It compares almost 1:1 ... except I don't like HierarKey menus
to show the full key bindings, e.g.

  Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 

With mini-menu, this would be much simpler, e.g.

  Set face: d)efault b)old i)talic bo(l)d-italic u)ndeline o)ther ...

I guess we could hack the HierarKey menus to look like that --
then mini-menu would definitely have no purpose at all!

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

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> I've never liked M-x grep for the very reason that I have to edit the command.

I like it precisely because I can write any command I want ;-)
For example, I can use grep, egrep, fgrep, with/without case
sensitivity, with/without context lines, ...

> > > > I am not sure it is worth reading the directory rather than just using
> > > > the current directory.
> > > This is VERY useful (I use it very often), and to use the current
> > > directory, just hit RET.
> > 
> > I must say that I generally prefer the C-u M-x grep approach which does
> > not force you into a series of questions, but just presents you with
> > the "complete default" and lets you edit it to your liking.
> 
> One additional trick is that M-x match prompts you for the directory
> using ido-read-directory, meaning that it is very easy to navigate to
> a completely different base directory.

Hopefully we can merge some of that functionality into eshell's
command completion and use eshell's completion for M-x grep (and
M-! and M-| and M-x compile and ...).

> Right.  I'll look at the new grep code (I wasn't aware that grep had been
> rewritten) as well as my own code again to see whether I can enhance the
> standard code rather than add a separate package.

It hasn't been rewritten at all.  I've just slightly improved the default
command offered when you hit C-u M-x grep.  A couple one-liners at most.

> BTW, M-x match uses jit-lock to fontify the matches in the *Match*
> buffer.

It would be great to use jit-lock for *compilation* buffers as well,
but a lot more work than for the specific case you're dealing with :-(

> And when you visit a match, it is temporarily highlighted in
> the target buffer (using an overlay).

That might be a good feature as well.  I have a similar feature for
sml-mode where the compiler's output includes a start and end point
for errors (the type-inference algorithm used by the language means
that some type errors are difficult for the compiler to locate).
But it's an ugly hack.  We should make such support more widespread
for all compilation buffers.

> I wasn't aware of the HierarKey feature (it's a very well hidden "fact").
> It compares almost 1:1 ... except I don't like HierarKey menus
> to show the full key bindings, e.g.
> 
>   Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 

I tend to agre.  Maybe we should just change it.  Or move the M-g prefix
to the beginning of the line (so it appears only once).


	Stefan

Re: Assignment of misc packages for emacs

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
> Date: Thu, 16 May 2002 18:49:21 -0400
> 
> I like it precisely because I can write any command I want ;-)
> For example, I can use grep, egrep, fgrep, with/without case
> sensitivity, with/without context lines, ...

Same here.

> Hopefully we can merge some of that functionality into eshell's
> command completion and use eshell's completion for M-x grep (and
> M-! and M-| and M-x compile and ...).

Yes, please!  I'm a completion maniac, so the absence of completion
in these commands drives me crazy.  I've long ago rebound M-! to
eshell-command, for that very reason.

Re: Assignment of misc packages for emacs

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> Yes, please!  I'm a completion maniac, so the absence of completion
> in these commands drives me crazy.  I've long ago rebound M-! to
> eshell-command, for that very reason.

Hmmm... I just do

  (autoload 'comint-dynamic-complete "comint" nil t)
  (define-key minibuffer-local-map [?\t] 'comint-dynamic-complete)

which I guess is slightly dodgy since lots of non-file-name input uses
minibuffer-local-map, but I don't seem to type tab there very often, so
it hasn't caused any problems...

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

Re: Assignment of misc packages for emacs

[Andreas Schwab]

Miles Bader <miles@lsi.nec.co.jp> writes:

|> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
|> > Yes, please!  I'm a completion maniac, so the absence of completion
|> > in these commands drives me crazy.  I've long ago rebound M-! to
|> > eshell-command, for that very reason.
|> 
|> Hmmm... I just do
|> 
|>   (autoload 'comint-dynamic-complete "comint" nil t)
|>   (define-key minibuffer-local-map [?\t] 'comint-dynamic-complete)

Doesn't work for me:

Symbol's value as variable is void: comint-last-input-start

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Assignment of misc packages for emacs

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
> |>   (autoload 'comint-dynamic-complete "comint" nil t)
> |>   (define-key minibuffer-local-map [?\t] 'comint-dynamic-complete)
> 
> Doesn't work for me:
> 
> Symbol's value as variable is void: comint-last-input-start

Odd.... maybe there's something in my .emacs that makes it work for me...

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Assignment of misc packages for emacs

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 17 May 2002 16:10:18 +0900
> 
>   (autoload 'comint-dynamic-complete "comint" nil t)
>   (define-key minibuffer-local-map [?\t] 'comint-dynamic-complete)

I don't like comint because it's so huge, and because it won't even
load on systems without async subprocesses.

I don't think shell-style completion of commands should depend on
comint, anyway.

Re: Assignment of misc packages for emacs

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> I don't like comint because it's so huge, and because it won't even
> load on systems without async subprocesses.
> 
> I don't think shell-style completion of commands should depend on
> comint, anyway.

I agree on both counts; I was really just pointing out my personal quick
hack.

Perhaps pcomplete would be appropriate -- would the problems encountered
before when trying to use it with comint affect minibuf usage (I can't
rightly remember what they were)?

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: Assignment of misc packages for emacs

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > I've never liked M-x grep for the very reason that I have to edit the command.
> 
> I like it precisely because I can write any command I want ;-)

Sure -- that's fine when you need it.
But most of the time, I dislike the interface...

I think the consensus is that it would be ok to provide an alternative 
user interface (to grep-find) which prompts in a more "user friendly" way.

> > One additional trick is that M-x match prompts you for the directory
> > using ido-read-directory, meaning that it is very easy to navigate to
> > a completely different base directory.
> 
> Hopefully we can merge some of that functionality into eshell's
> command completion and use eshell's completion for M-x grep (and
> M-! and M-| and M-x compile and ...).


> 
> > Right.  I'll look at the new grep code (I wasn't aware that grep had been
> > rewritten) as well as my own code again to see whether I can enhance the
> > standard code rather than add a separate package.
> 
> It hasn't been rewritten at all.  I've just slightly improved the default
> command offered when you hit C-u M-x grep.  A couple one-liners at most.
> 
> > BTW, M-x match uses jit-lock to fontify the matches in the *Match*
> > buffer.
> 
> It would be great to use jit-lock for *compilation* buffers as well,
> but a lot more work than for the specific case you're dealing with :-(
> 
> > And when you visit a match, it is temporarily highlighted in
> > the target buffer (using an overlay).
> 
> That might be a good feature as well.  I have a similar feature for
> sml-mode where the compiler's output includes a start and end point
> for errors (the type-inference algorithm used by the language means
> that some type errors are difficult for the compiler to locate).
> But it's an ugly hack.  We should make such support more widespread
> for all compilation buffers.

That would be great.

If C-x ` could just (temporarily) highlight the error line, it would
be fine for most modes -- if other modes (like grep) wants to refine
this, it should be made simple.

It could be based on a "compile-highlight-target-regexp" which would
be something like "^.*$" by default.  And if it is set to a symbol,
that could a function to call to do the highlighting (or nil to turn
it off).

> 
> > I wasn't aware of the HierarKey feature (it's a very well hidden "fact").
> > It compares almost 1:1 ... except I don't like HierarKey menus
> > to show the full key bindings, e.g.
> > 
> >   Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 
> 
> I tend to agre.  Maybe we should just change it.  Or move the M-g prefix
> to the beginning of the line (so it appears only once).

I don't see the need to show the prefix at all  (I just typed
it to get the menu).

I'll make the change and see what people think [can always be reverted].

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

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> > > I've never liked M-x grep for the very reason that I have to edit the command.
> > I like it precisely because I can write any command I want ;-)
> 
> Sure -- that's fine when you need it.
> But most of the time, I dislike the interface...
> 
> I think the consensus is that it would be ok to provide an alternative
> user interface (to grep-find) which prompts in a more "user friendly" way.

I don't find it user-friendly at all to be forced to enter things
in a particular order and to type RET three times to confirm each
part of the command spearately.
Most of the time, the defaults are right, so I only need to do
C-u M-x grep RET RET which turns into C-u C-c g RET with the
appropriate binding.

But obviously this is a matter of taste.

> > >   Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 
> > I tend to agre.  Maybe we should just change it.  Or move the M-g prefix
> > to the beginning of the line (so it appears only once).
> I don't see the need to show the prefix at all  (I just typed
> it to get the menu).

If there was no such menu, the minibuffer would say "M-g " after a little
while, which is why I figured it might be good to keep the "M-g" prefix
somewhere.  But admittedly, the menu probably makes it clear enough
"where" one is.


	Stefan

Re: Assignment of misc packages for emacs

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> I don't find it user-friendly at all to be forced to enter things
> in a particular order and to type RET three times to confirm each
> part of the command spearately.

I agree; I particularly hate many-in-order-prompts types of user
interfaces (try `modify-face' for an extreme example).

Even if it's desirable to put a prettier face on `grep', I think it
should still have the same `feel' -- like a dialog box where you can
enter all the parameters and toggle the options in whatever order you
want (and only if you need to) and hit GO.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Assignment of misc packages for emacs

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Most of the time, the defaults are right, so I only need to do
> C-u M-x grep RET RET which turns into C-u C-c g RET with the
> appropriate binding.

With the appropriate bindings, I find H-m RET RET RET easier to type
than C-u C-c g RET :-)

> 
> But obviously this is a matter of taste.

.. which is why the "discussion" about it will never end :-)


> > I don't see the need to show the prefix at all  (I just typed
> > it to get the menu).
> 
> If there was no such menu, the minibuffer would say "M-g " after a little
> while, which is why I figured it might be good to keep the "M-g" prefix
> somewhere.  But admittedly, the menu probably makes it clear enough
> "where" one is.

Since I already got immediate feedback on typing M-g, I don't need it
to tell me what key I typed to get there (that's rather uncommon IMO).
C-s doesn't prompt you with:  C-s I-search:  either.

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

Re: Assignment of misc packages for emacs

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Since I already got immediate feedback on typing M-g, I don't need it
> to tell me what key I typed to get there (that's rather uncommon IMO).

I think this is right -- the general convention in GNU emacs seems to be
to not show the invoking keysequence before prompts (except when there's
no prompt, like M-x).

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Assignment of misc packages for emacs

[Richard Stallman]

    > I wasn't aware of the HierarKey feature (it's a very well hidden "fact").
    > It compares almost 1:1 ... except I don't like HierarKey menus
    > to show the full key bindings, e.g.
    > 
    >   Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 

    I tend to agre.  Maybe we should just change it.  Or move the M-g prefix
    to the beginning of the line (so it appears only once).

What's right to do depends on the circumstances.  In the context of
setting the face, you are typing key sequences.  The point is to show
the whole equivalent key sequences for these commands.  For that
point, it needs to show the whole key binding.

Answering a question asked by a command is a different situation.  In
that context there are no equivalent key bindings that are normally
defined, so none should be shown.  If that doesn't work now, we would
want to make it work that way.

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > I wasn't aware of the HierarKey feature (it's a very well hidden "fact").
>     > It compares almost 1:1 ... except I don't like HierarKey menus
>     > to show the full key bindings, e.g.
>     > 
>     >   Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 
> 
>     I tend to agre.  Maybe we should just change it.  Or move the M-g prefix
>     to the beginning of the line (so it appears only once).
> 
> What's right to do depends on the circumstances.  In the context of
> setting the face, you are typing key sequences.  The point is to show
> the whole equivalent key sequences for these commands.  For that
> point, it needs to show the whole key binding.

I don't understand why it _needs_ to show that.

I have just pressed M-g, and emacs responds with a menu which
tells me that pressing d gives default, b gives bold, etc.

So why is it necessary to tell me that the complete key binding is
M-g d, M-g b, etc.  ?   IMO, that's duplicate information, which
is more confusing than informative.

My suggestion is to remove the duplicate information and instead
emphasize which key to press like this:

 Set face: d)efault b)old i)talic bo(l)d-italic u)nderline O)ther ...

IMO this is simpler to read, and actually fits in 80 columns!

> Answering a question asked by a command is a different situation.  In
> that context there are no equivalent key bindings that are normally
> defined, so none should be shown.  If that doesn't work now, we would
> want to make it work that way.

But what if the effect is the same ?

Let's say I write a command (select-face) which prints exactly the
same prompt as is produced by M-g, reads a character, and selects
default, bold, italic, etc face depending on that character.  I then
bind that command to M-g.

So now there is no explicit key binding for `M-g b', but from a user's
point of view, entering M-g b still selects bold face in exactly the
same way as the current code does.

Why does it make sense to show the key binding " (M-g b)" in the
prompt in the first case and not in the second case -- when the
_effect_ is exactly the same in both cases.

IMO, the key binding should be removed from the prompt, as it
doesn't give any useful information, and it makes the prompt
approx. twice as long as it needs to be...!

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

Re: Assignment of misc packages for emacs

[Richard Stallman]

    Let's say I write a command (select-face) which prints exactly the
    same prompt as is produced by M-g, reads a character, and selects
    default, bold, italic, etc face depending on that character.  I then
    bind that command to M-g.

This is an artificial example.  If you want this behavior, you should
use a keymap.  In real cases where functions ask questions, it's
because the behavior is something different, not resembling a prefix
key.

Re: Assignment of misc packages for emacs

[Stefan Monnier]

>     > I wasn't aware of the HierarKey feature (it's a very well hidden "fact").
>     > It compares almost 1:1 ... except I don't like HierarKey menus
>     > to show the full key bindings, e.g.
>     > 
>     >   Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  (M-g l), undeline  (M-g u), Other ...  (M-g o) 
> 
>     I tend to agre.  Maybe we should just change it.  Or move the M-g prefix
>     to the beginning of the line (so it appears only once).
> 
> What's right to do depends on the circumstances.  In the context of
> setting the face, you are typing key sequences.  The point is to show
> the whole equivalent key sequences for these commands.  For that
> point, it needs to show the whole key binding.

I don't really understand what you mean.  What's the point of saying
"you can get the same effect by hitting M-g d" when the user has
just hit M-g d anyway ?
In menubar entries, it makes sense because we list equivalent but
*different* key sequences.  For example, we never list
<menu-bar> <files> <kill-buffer> because that's not a different
binding and would thus be redundant.  Similarly, listing M-g in the
above HierarKey prompt is redundant.


	Stefan

Re: Assignment of misc packages for emacs

[Richard Stallman]

    I don't really understand what you mean.  What's the point of saying
    "you can get the same effect by hitting M-g d" when the user has
    just hit M-g d anyway ?

M-g doesn't output that prompt.  I am not actually sure how to get to
the state where that prompt appears--can someone tell me?

Re: Assignment of misc packages for emacs

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I wasn't aware of the HierarKey feature (it's a very well hidden "fact").

Me either...

I notice that docs say that the `HierarKey' (hate the name though) menu
is displayed one line at a time, with SPC showing subsequent
lines.... this seems rather annoying, especially if the menu is only two
or three lines long.  Why not just show the whole thing at once?
Expanding the echo area isn't particulary intrusive.

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

Re: Assignment of misc packages for emacs

[Richard Stallman]

    I notice that docs say that the `HierarKey' (hate the name though) menu
    is displayed one line at a time, with SPC showing subsequent
    lines.... this seems rather annoying, especially if the menu is only two
    or three lines long.  Why not just show the whole thing at once?

When the HierarKey menus were implemented, the echo area was not
expandable.

    Expanding the echo area isn't particulary intrusive.

That's true, now.  Would you like to change it to do so?

Re: Assignment of misc packages for emacs

[Miles Bader]

So can someone tell me how to define `HierarKey' menus?  The elisp
manual seems to suggest that the following should work:

  (progn
    (defvar menu-map)
    (setq menu-map (make-sparse-keymap "This is a prompt"))
    (local-set-key "&" menu-map)
    (define-key menu-map "1" '(menu-item "Insert 1" (lambda () (interactive) (insert "1"))))
    (define-key menu-map "2" '(menu-item "Insert 2" (lambda () (interactive) (insert "2")))))

and that then hitting the `&' key should give me a menu in the echo
area -- but it doesn't it just displays `&-' like any other key prefix.

Thanks,

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> So can someone tell me how to define `HierarKey' menus?  The elisp
> manual seems to suggest that the following should work:
> 
>   (progn
>     (defvar menu-map)
>     (setq menu-map (make-sparse-keymap "This is a prompt"))
>     (local-set-key "&" menu-map)
>     (define-key menu-map "1" '(menu-item "Insert 1" (lambda () (interactive) (insert "1"))))
>     (define-key menu-map "2" '(menu-item "Insert 2" (lambda () (interactive) (insert "2")))))
> 
> and that then hitting the `&' key should give me a menu in the echo
> area -- but it doesn't it just displays `&-' like any other key prefix.

Works for me.  As mentioned in one of my earlier messages, it didn't work
for the CVS head a few days ago (a mess up of mine), but it is now fixed.


	Stefan

Re: Assignment of misc packages for emacs

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> > So can someone tell me how to define `HierarKey' menus?  The elisp
> > manual seems to suggest that the following should work:
> 
> Works for me.  As mentioned in one of my earlier messages, it didn't work
> for the CVS head a few days ago (a mess up of mine), but it is now fixed.

Ah, that explains it, I'm a bit behind in my cvs updating (I tend to
avoid updating so often if I've changed any source files, because of
CVS's atrocious behavior over slow links in that case).

Thanks,

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Assignment of misc packages for emacs

[Miles Bader]

Ok, now that I've updated from CVS, I tried out hierarkey menus.  While
idea seems cool, the visual presentation is currently quite confusing.

Part of this is the one-line-at-a-time thing, which I guess is a
historical misfeature, and can just be fixed.

Part of it is that the way the menus are presented is just wierd,
e.g. using my previous example:

  (progn
    (defvar menu-map)
    (setq menu-map (make-sparse-keymap "This is a prompt"))
    (local-set-key "&" menu-map)
    (define-key menu-map "1" '(menu-item "Insert 1" (lambda () (interactive) (insert "1"))))
    (define-key menu-map "2" '(menu-item "Insert 2" (lambda () (interactive) (insert "2"))))
    (define-key menu-map "f" '(menu-item "foo" (lambda () (interactive) (insert "foo"))))
    (define-key menu-map "b" '(menu-item "Bar" (lambda () (interactive) (insert "Bar"))))
    )

I get the following two lines if I type `&':

  This is a prompt: Bar  (& b), foo  (& f), 2 = Insert 2  (& 2)...
  This is a prompt: 1 = Insert 1  (& 1)

The output is really `busy,' and hard to read.

I see the following problems:

  * The main question people are probably asking when they see this
    menu displayed is `what key do I hit to get my function'.

    With the current display format, it's not at all obvious.  Not only
    is the key to hit listed _after_ the description, which makes it
    harder to find, but I think Kim was right -- including the prefix
    key (`&' in this case) is not just superfluous, but actually makes
    it harder to understand the menu.

  * For keys where the selection key isn't the first letter of the menu
    entry string, it actually lists the binding _twice_ (but for those
    where it's not, it's only listed once).  Again, this sort of
    inconsistency makes it hard to see the answer to the main
    question, `what do I hit'.

I would suggest changing the formatting to remove these problems, by

(1) listing the `key to hit' _before_ each entry, and making it
    visually noticable,
(2) Only listing it once for each entry, and
(3) Not including the menu prefix, which is both unnecessary and confusing.

So the above example menu might become [alternative 1]:

  This is a prompt: b = Bar,  f = foo,  2 = Insert 2
  This is a prompt: 1 = Insert 1

Here's an another alternative that acts a bit more clever if the menu
string begins with the same letter as the associated binding
[altnernative 2]:

  This is a prompt: (B)ar,  (f)oo,  (2) Insert 2
  This is a prompt: (1) Insert 1

I find this style even easier to understand; this is the one I prefer.

What do people think?


Here's a real world example -- the `d' (diff) menu from pcl-cvs:

Current look:
   Diff: vendor  (d v), head  (d h), backup  (d b), diff  (=)
   Diff: 2 = other  (d 2), e = idiff  (d e), E = imerge  (d E)

[alternative 1]:
   Diff: v = vendor,  h = head,  b = backup,  = = diff
   Diff: 2 = other,  e = idiff,  E = imerge

[alternative 2]:
   Diff: (v)endor,  (h)ead,  (b)ackup,  (=) diff
   Diff: (2) other,  (e) idiff,  (E) imerge

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: Assignment of misc packages for emacs

[Alex Schroeder]

Miles Bader <miles@lsi.nec.co.jp> writes:

> [alternative 1]:
>    Diff: v = vendor,  h = head,  b = backup,  = = diff
>    Diff: 2 = other,  e = idiff,  E = imerge

I like this one best, because I can parse this faster -- alternative 2
requires that I scan for brackets, and these brackets can be part of
words or not, so I just waste a tiny bit of time thinking about it.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: Assignment of misc packages for emacs

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> [alternative 2]:
>    Diff: (v)endor,  (h)ead,  (b)ackup,  (=) diff
>    Diff: (2) other,  (e) idiff,  (E) imerge

Cool.

kai
-- 
Silence is foo!

Re: Assignment of misc packages for emacs

[Richard Stallman]

    Current look:
       Diff: vendor  (d v), head  (d h), backup  (d b), diff  (=)
       Diff: 2 = other  (d 2), e = idiff  (d e), E = imerge  (d E)

I already deleted the equivalent key bindings, so it would now be

    Current look:
       Diff: vendor, head, backup, diff, 2 = other, e = idiff
       Diff: E = imerge

(It appears that the key one types for `diff' is d, not =.
The key binding for that is =, not d =.)

So you are proposing these two alternatives (I have corrected an
apparent mistake for `diff'):

    [alternative 1]:
       Diff: v = vendor,  h = head,  b = backup,  d = diff
       Diff: 2 = other,  e = idiff,  E = imerge

    [alternative 2]:
       Diff: (v)endor,  (h)ead,  (b)ackup,  (d) diff
       Diff: (2) other,  (e) idiff,  (E) imerge

I think a better idea is to keep the current format
but put the keys you would type in bold face.  So it would look like

       Diff: vendor, head, backup, diff, 2 = other, e = idiff
       Diff: E = imerge

with the v, h, b, d, 2, e and E in bold.

Given this, the ='s could be deleted, giving

       Diff: vendor, head, backup, diff, 2 other, e idiff
       Diff: E imerge

with the v, h, b, d, 2, e and E in bold.

If the terminal does not support bold or any other suitable standout
mode, it could put in the ='s as a fallback.  It could do either

       Diff: vendor, head, backup, diff, 2 = other, e = idiff
       Diff: E = imerge

or

       Diff: v = vendor,  h = head,  b = backup,  d = diff
       Diff: 2 = other,  e = idiff,  E = imerge

Re: Assignment of misc packages for emacs

[Mario Lang]

Richard Stallman <rms@gnu.org> writes:

> If the terminal does not support bold or any other suitable standout
> mode, it could put in the ='s as a fallback.  It could do either
>
>        Diff: vendor, head, backup, diff, 2 = other, e = idiff
>        Diff: E = imerge
>
> or
>
>        Diff: v = vendor,  h = head,  b = backup,  d = diff
>        Diff: 2 = other,  e = idiff,  E = imerge

Please consider making this an option.

My terminal supports faces (Linux console), but as a 
blind braille user, it is quite unpleasant to work
with face information.  So an option would be nice here.

To save space, I'd prefer:

     Diff: v=vendor, h=head, b=backup, d=diff 2=other, e=idiff, E=imerge


-- 
CYa,
  Mario

Re: Assignment of misc packages for emacs

[Miles Bader]

Mario Lang <mlang@delysid.org> writes:
> Please consider making this an option.
> 
> My terminal supports faces (Linux console), but as a 
> blind braille user, it is quite unpleasant to work
> with face information.  So an option would be nice here.
> 
> To save space, I'd prefer:
> 
>      Diff: v=vendor, h=head, b=backup, d=diff 2=other, e=idiff, E=imerge

Is there any reason we couldn't make it call out to lisp to do the
formatting?  Then it would be simple to make it work in any way the user
wants.  It doesn't seem like a speed/consing criticial piece of code...

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Assignment of misc packages for emacs

[Richard Stallman]

    To save space, I'd prefer:

	 Diff: v=vendor, h=head, b=backup, d=diff 2=other, e=idiff, E=imerge

That could be a good point.

    My terminal supports faces (Linux console), but as a 
    blind braille user, it is quite unpleasant to work
    with face information.  So an option would be nice here.

It ought to be easy to turn off the feature by customizing the face
that it uses into a no-op.  The code could call
face-differs-from-default-p to decide which format to output.

Would that be ok?

Re: Assignment of misc packages for emacs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I think a better idea is to keep the current format
> but put the keys you would type in bold face.  So it would look like
> 
>        Diff: vendor, head, backup, diff, 2 = other, e = idiff
>        Diff: E = imerge

I tried that with actual bold characters, and it seems reasonable -- a
single bold character doesn't stand out all that much, but it can be
seen (using my fonts at least), and has the advantage of not obscuring
the actual labels like some puncuation does.

An alternative would be to use underlining, which would match what many
menu systems use to indicate key-to-letter-in-a-menu-label correspondences.
I also find that underlining makes the keys more obvious, also without
obscuring the labels.

One point about this style: I tried with both one and two spaces as
separators following the commas, and I found it much more readable with
two spaces.

-Miles

p.s., Here's the code I used to try it (the four lines at the end
      display the various styles):

(defun parenthify-entry (key label)
  (if (eq key (aref label 0))
      (format "(%c)%s" key (substring label 1))
    (format "(%c) %s" key label)))

(defun facify-entry (key label face)
  (if (eq key (aref label 0))
      (format "%s%s"
	      (propertize (char-to-string key) 'face face)
	      (substring label 1))
    (format "%s = %s" (propertize (char-to-string key) 'face face) label)))

(defun boldify-entry (key label)
  (facify-entry key label 'bold))
(defun undify-entry (key label)
  (facify-entry key label 'underline))

(defun equify-entry (key label)
  (format "%c = %s" key label))

(defun show-menu-string (format-fun)
  (let ((msg "Diff:" ) (sep "  ") (sep2 ",  "))
    (dolist (entry '((?v . "vendor") (?h . "head") (?b . "backup") 
		     (?d . "diff")
		     (?2 . "other")  (?e . "idiff")  (?E . "imerge")))
      (setq msg (concat msg sep (funcall format-fun (car entry) (cdr entry))))
      (setq sep sep2))
    (let ((minibuffer-prompt-properties nil))
      (read-string msg))))

(show-menu-string 'equify-entry)
(show-menu-string 'boldify-entry)
(show-menu-string 'undify-entry)
(show-menu-string 'parenthify-entry)


-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Assignment of misc packages for emacs

[Richard Stallman]

    I tried that with actual bold characters, and it seems reasonable -- a
    single bold character doesn't stand out all that much, but it can be
    seen (using my fonts at least), and has the advantage of not obscuring
    the actual labels like some puncuation does.

    An alternative would be to use underlining, which would match what many
    menu systems use to indicate key-to-letter-in-a-menu-label correspondences.
    I also find that underlining makes the keys more obvious, also without
    obscuring the labels.

Whether it is bold or underlined is just a matter of how
we define the face that it uses, right?

    One point about this style: I tried with both one and two spaces as
    separators following the commas, and I found it much more readable with
    two spaces.

Do you feel it needs two spaces *and* a comma?  What about
if we delete the spaces around the ='s, as Mario Lang suggested?

    Is there any reason we couldn't make it call out to lisp to do the
    formatting?

It's ok with me if someone finds it easy to do.

Re: Assignment of misc packages for emacs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Whether it is bold or underlined is just a matter of how
> we define the face that it uses, right?

Yup

>     One point about this style: I tried with both one and two spaces as
>     separators following the commas, and I found it much more readable with
>     two spaces.
> 
> Do you feel it needs two spaces *and* a comma?

Yes.  I tried the various other combinations, and while nothing really
looked _bad_, comma-space-space seemed the best.

The reason, I think, is that it emphasizes the fact that what's being
displayed is a list of separate entries -- the comma basically suggests
`list', and the wide whitespace suggests `separate'.  Using just
comma-space makes the menu look like a list of _words_ (an effect which
obviously gets worse if any label actually contains multiple words), and
using just space-space looks somehow not list-like enough.

So I think comma-space-space is the best, but that space-space is
better than comma-space.

> What about if we delete the spaces around the ='s, as Mario Lang
> suggested?

I don't like it, since it makes it harder to quickly identify which is
the key and which is the label.

>     Is there any reason we couldn't make it call out to lisp to do the
>     formatting?
> 
> It's ok with me if someone finds it easy to do.

I'll look at it.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Assignment of misc packages for emacs

[Mario Lang]

Miles Bader <miles@lsi.nec.co.jp> writes:

>> What about if we delete the spaces around the ='s, as Mario Lang
>> suggested?
>
> I don't like it, since it makes it harder to quickly identify which is
> the key and which is the label.
I feel the exact opposite. Making the list longer takes
me longer to read it, and therefore harder to use.

I know my case is very special here, and I can't comment on visual
appearance.  It would be nice if I could choose the representation
I like the most.  So maybe the lisp-level formatter?

>>     Is there any reason we couldn't make it call out to lisp to do the
>>     formatting?
>> 
>> It's ok with me if someone finds it easy to do.
>
> I'll look at it.

I'd be glad to use it.

-- 
CYa,
  Mario

Re: Assignment of misc packages for emacs

[Miles Bader]

Mario Lang <mlang@delysid.org> writes:
> I know my case is very special here, and I can't comment on visual
> appearance.  It would be nice if I could choose the representation
> I like the most.  So maybe the lisp-level formatter?

Yes, that seems the best thing.

Cheers,

-Miles
-- 
I'd rather be consing.

Re: Assignment of misc packages for emacs

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

Richard Stallman <rms@gnu.org> writes:
>     Is there any reason we couldn't make it call out to lisp to do the
>     formatting?
> 
> It's ok with me if someone finds it easy to do.

What do you think of the appended patch?  It moves all the formatting
and prompting for keyboard-menus to lisp (and in the process gets rid
of the one-line-at-a-time interface, since the lisp code just displays
the whole menu at once).

-Miles


Patch:



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch to move keyboard-menu prompting to lisp --]
[-- Type: text/x-patch, Size: 16743 bytes --]

src/ChangeLog:
2002-06-05  Miles Bader  <miles@gnu.org>

	* keyboard.c (Vkey_menu_prompt_function): New variable.
	(keys_of_keyboard): Initialize it.
	(read_char_minibuf_menu_prompt): Remove code which constructed
	a minibuffer prompt and interacted with the user.  Add code to
	construct a list of menu entries and call the lisp function
	`key-menu-prompt-function' instead.
	(read_char_minibuf_menu_text, read_char_minibuf_menu_width):
	Variables removed.

lisp/ChangeLog:
2002-06-05  Miles Bader  <miles@gnu.org>

	* subr.el (key-menu-prompt): New function.
	(key-menu-prompt-function): Set to `key-menu-prompt'.
	(key-menu-event-face, key-menu-initial-separator) 
	(key-menu-separator, key-menu-long-prompt-line-prefix): New variables.

diff -c src/keyboard.c.~1.679.~ src/keyboard.c
*** src/keyboard.c.~1.679.~	Sat May 25 13:38:14 2002
--- src/keyboard.c	Wed Jun  5 01:30:26 2002
***************
*** 660,665 ****
--- 660,670 ----
  
  Lisp_Object Vglobal_disable_point_adjustment;
  
+ /* A function to display keyboard-menus, and read the user's response.
+    If nil, keyboard menus are disabled.  */
+ 
+ Lisp_Object Vkey_menu_prompt_function;
+ 
  /* The time when Emacs started being idle.  */
  
  static EMACS_TIME timer_idleness_start_time;
***************
*** 7589,7600 ****
    return Qnil ;
  }
  
- /* Buffer in use so far for the minibuf prompts for menu keymaps.
-    We make this bigger when necessary, and never free it.  */
- static char *read_char_minibuf_menu_text;
- /* Size of that buffer.  */
- static int read_char_minibuf_menu_width;
- 
  static Lisp_Object
  read_char_minibuf_menu_prompt (commandflag, nmaps, maps)
       int commandflag ;
--- 7594,7599 ----
***************
*** 7603,7614 ****
  {
    int mapno;
    register Lisp_Object name;
-   int nlength;
-   int width = FRAME_WIDTH (SELECTED_FRAME ()) - 4;
    int idx = -1;
-   int nobindings = 1;
    Lisp_Object rest, vector;
!   char *menu;
  
    vector = Qnil;
    name = Qnil;
--- 7602,7614 ----
  {
    int mapno;
    register Lisp_Object name;
    int idx = -1;
    Lisp_Object rest, vector;
!   /* This is a list of the prompt and individual menu entries passed to
!      lisp for formatting and display.  The format is:
!        MENU_LIST : (MENU_PROMPT ENTRY...)
!        ENTRY     : (EVENT PROMPT [BINDING [TOGGLE_TYPE TOGGLE_STATE]])   */
!   Lisp_Object menu_list = Qnil;
  
    vector = Qnil;
    name = Qnil;
***************
*** 7616,7635 ****
    if (! menu_prompting)
      return Qnil;
  
-   /* Make sure we have a big enough buffer for the menu text.  */
-   if (read_char_minibuf_menu_text == 0)
-     {
-       read_char_minibuf_menu_width = width + 4;
-       read_char_minibuf_menu_text = (char *) xmalloc (width + 4);
-     }
-   else if (width + 4 > read_char_minibuf_menu_width)
-     {
-       read_char_minibuf_menu_width = width + 4;
-       read_char_minibuf_menu_text
- 	= (char *) xrealloc (read_char_minibuf_menu_text, width + 4);
-     }
-   menu = read_char_minibuf_menu_text;
- 
    /* Get the menu name from the first map that has one (a prompt string).  */
    for (mapno = 0; mapno < nmaps; mapno++)
      {
--- 7616,7621 ----
***************
*** 7642,7845 ****
    if (!STRINGP (name))
      return Qnil;
  
-   /* Prompt string always starts with map's prompt, and a space.  */
-   strcpy (menu, XSTRING (name)->data);
-   nlength = STRING_BYTES (XSTRING (name));
-   menu[nlength++] = ':';
-   menu[nlength++] = ' ';
-   menu[nlength] = 0;
- 
    /* Start prompting at start of first map.  */
    mapno = 0;
    rest = maps[mapno];
  
!   /* Present the documented bindings, a line at a time.  */
!   while (1)
      {
!       int notfirst = 0;
!       int i = nlength;
!       Lisp_Object obj;
!       int ch;
!       Lisp_Object orig_defn_macro;
! 
!       /* Loop over elements of map.  */
!       while (i < width)
! 	{
! 	  Lisp_Object elt;
! 
! 	  /* If reached end of map, start at beginning of next map.  */
! 	  if (NILP (rest))
! 	    {
! 	      mapno++;
! 	      /* At end of last map, wrap around to first map if just starting,
! 		 or end this line if already have something on it.  */
! 	      if (mapno == nmaps)
! 		{
! 		  mapno = 0;
! 		  if (notfirst || nobindings) break;
! 		}
! 	      rest = maps[mapno];
! 	    }
  
! 	  /* Look at the next element of the map.  */
! 	  if (idx >= 0)
! 	    elt = XVECTOR (vector)->contents[idx];
! 	  else
! 	    elt = Fcar_safe (rest);
  
! 	  if (idx < 0 && VECTORP (elt))
  	    {
! 	      /* If we found a dense table in the keymap,
! 		 advanced past it, but start scanning its contents.  */
! 	      rest = Fcdr_safe (rest);
! 	      vector = elt;
! 	      idx = 0;
  	    }
  	  else
  	    {
! 	      /* An ordinary element.  */
! 	      Lisp_Object event, tem;
! 
! 	      if (idx < 0)
! 		{
! 		  event = Fcar_safe (elt); /* alist */
! 		  elt = Fcdr_safe (elt);
! 		}
! 	      else
! 		{
! 		  XSETINT (event, idx); /* vector */
! 		}
! 
! 	      /* Ignore the element if it has no prompt string.  */
! 	      if (INTEGERP (event) && parse_menu_item (elt, 0, -1))
! 		{
! 		  /* 1 if the char to type matches the string.  */
! 		  int char_matches;
! 		  Lisp_Object upcased_event, downcased_event;
! 		  Lisp_Object desc = Qnil;
! 		  Lisp_Object s
! 		    = XVECTOR (item_properties)->contents[ITEM_PROPERTY_NAME];
! 
! 		  upcased_event = Fupcase (event);
! 		  downcased_event = Fdowncase (event);
! 		  char_matches = (XINT (upcased_event) == XSTRING (s)->data[0]
! 				  || XINT (downcased_event) == XSTRING (s)->data[0]);
! 		  if (! char_matches)
! 		    desc = Fsingle_key_description (event, Qnil);
! 
! #if 0  /* It is redundant to list the equivalent key bindings because
! 	  the prefix is what the user has already typed.  */
! 		  tem
! 		    = XVECTOR (item_properties)->contents[ITEM_PROPERTY_KEYEQ];
! 		  if (!NILP (tem))
! 		    /* Insert equivalent keybinding. */
! 		    s = concat2 (s, tem);
! #endif
! 		  tem
! 		    = XVECTOR (item_properties)->contents[ITEM_PROPERTY_TYPE];
! 		  if (EQ (tem, QCradio) || EQ (tem, QCtoggle))
! 		    {
! 		      /* Insert button prefix. */
! 		      Lisp_Object selected
! 			= XVECTOR (item_properties)->contents[ITEM_PROPERTY_SELECTED];
! 		      if (EQ (tem, QCradio))
! 			tem = build_string (NILP (selected) ? "(*) " : "( ) ");
! 		      else
! 			tem = build_string (NILP (selected) ? "[X] " : "[ ] ");
! 		      s = concat2 (tem, s);
! 		    }
! 		  
! 
! 		  /* If we have room for the prompt string, add it to this line.
! 		     If this is the first on the line, always add it.  */
! 		  if ((XSTRING (s)->size + i + 2
! 		       + (char_matches ? 0 : XSTRING (desc)->size + 3))
! 		      < width
! 		      || !notfirst)
! 		    {
! 		      int thiswidth;
! 
! 		      /* Punctuate between strings.  */
! 		      if (notfirst)
! 			{
! 			  strcpy (menu + i, ", ");
! 			  i += 2;
! 			}
! 		      notfirst = 1;
! 		      nobindings = 0 ;
! 
! 		      /* If the char to type doesn't match the string's
! 			 first char, explicitly show what char to type.  */
! 		      if (! char_matches)
! 			{
! 			  /* Add as much of string as fits.  */
! 			  thiswidth = XSTRING (desc)->size;
! 			  if (thiswidth + i > width)
! 			    thiswidth = width - i;
! 			  bcopy (XSTRING (desc)->data, menu + i, thiswidth);
! 			  i += thiswidth;
! 			  strcpy (menu + i, " = ");
! 			  i += 3;
! 			}
! 
! 		      /* Add as much of string as fits.  */
! 		      thiswidth = XSTRING (s)->size;
! 		      if (thiswidth + i > width)
! 			thiswidth = width - i;
! 		      bcopy (XSTRING (s)->data, menu + i, thiswidth);
! 		      i += thiswidth;
! 		      menu[i] = 0;
! 		    }
! 		  else
! 		    {
! 		      /* If this element does not fit, end the line now,
! 			 and save the element for the next line.  */
! 		      strcpy (menu + i, "...");
! 		      break;
! 		    }
! 		}
! 
! 	      /* Move past this element.  */
! 	      if (idx >= 0 && idx + 1 >= XVECTOR (vector)->size)
! 		/* Handle reaching end of dense table.  */
! 		idx = -1;
! 	      if (idx >= 0)
! 		idx++;
! 	      else
! 		rest = Fcdr_safe (rest);
  	    }
  	}
  
!       /* Prompt with that and read response.  */
!       message2_nolog (menu, strlen (menu), 
! 		      ! NILP (current_buffer->enable_multibyte_characters));
  
!       /* Make believe its not a keyboard macro in case the help char
! 	 is pressed.  Help characters are not recorded because menu prompting
! 	 is not used on replay.
! 	 */
!       orig_defn_macro = current_kboard->defining_kbd_macro;
!       current_kboard->defining_kbd_macro = Qnil;
!       do
! 	obj = read_char (commandflag, 0, 0, Qt, 0);
!       while (BUFFERP (obj));
!       current_kboard->defining_kbd_macro = orig_defn_macro;
  
!       if (!INTEGERP (obj))
! 	return obj;
!       else
! 	ch = XINT (obj);
! 
!       if (! EQ (obj, menu_prompt_more_char)
! 	  && (!INTEGERP (menu_prompt_more_char)
! 	      || ! EQ (obj, make_number (Ctl (XINT (menu_prompt_more_char))))))
! 	{
! 	  if (!NILP (current_kboard->defining_kbd_macro))
! 	    store_kbd_macro_char (obj);
! 	  return obj;
! 	}
!       /* Help char - go round again */
!     }
  }
  \f
  /* Reading key sequences.  */
--- 7628,7736 ----
    if (!STRINGP (name))
      return Qnil;
  
    /* Start prompting at start of first map.  */
    mapno = 0;
    rest = maps[mapno];
  
!   /* Loop over elements of map.  */
!   for (;;)
      {
!       Lisp_Object elt;
  
!       /* If reached end of map, start at beginning of next map.  */
!       if (NILP (rest))
! 	{
! 	  mapno++;
! 	  if (mapno == nmaps)
! 	    /* Done with all maps.  */
! 	    break;
! 	  rest = maps[mapno];
! 	}
! 
!       /* Look at the next element of the map.  */
!       if (idx >= 0)
! 	elt = AREF (vector, idx);
!       else
! 	elt = Fcar_safe (rest);
! 
!       if (idx < 0 && VECTORP (elt))
! 	{
! 	  /* If we found a dense table in the keymap,
! 	     advanced past it, but start scanning its contents.  */
! 	  rest = Fcdr_safe (rest);
! 	  vector = elt;
! 	  idx = 0;
! 	}
!       else
! 	{
! 	  /* An ordinary element.  */
! 	  Lisp_Object event, tem;
  
! 	  if (idx < 0)
  	    {
! 	      event = Fcar_safe (elt); /* alist */
! 	      elt = Fcdr_safe (elt);
  	    }
  	  else
  	    {
! 	      XSETINT (event, idx); /* vector */
  	    }
+ 
+ 	  /* Ignore the element if it has no prompt string.  */
+ 	  if (INTEGERP (event) && parse_menu_item (elt, 0, -1))
+ 	    {
+ 	      /* The list describing this entry.  */
+ 	      Lisp_Object entry = Qnil;
+ 	      Lisp_Object prop_val;
+ 
+ 	      prop_val = AREF (item_properties, ITEM_PROPERTY_TYPE);
+ 	      if (EQ (prop_val, QCradio) || EQ (prop_val, QCtoggle))
+ 		/* This is a `toggle-able' menu-entry, make the
+ 		   tail of the list describe it.  */
+ 		entry
+ 		  = Fcons (prop_val,
+ 			   Fcons (AREF (item_properties,
+ 					ITEM_PROPERTY_SELECTED),
+ 				  entry));
+ 
+ 	      /* Equivalent keybinding.  */
+ 	      prop_val = AREF (item_properties, ITEM_PROPERTY_KEYEQ);
+ 	      if (!NILP (entry) || !NILP (prop_val))
+ 		entry = Fcons (prop_val, entry);
+ 
+ 	      /* The string prompt.  */
+ 	      prop_val = AREF (item_properties, ITEM_PROPERTY_NAME);
+ 	      entry = Fcons (prop_val, entry);
+ 
+ 	      /* Finally, the car of the list is the event.  */
+ 	      entry = Fcons (event, entry);
+ 
+ 	      /* Push this entry on the the list of entries.  */
+ 	      menu_list = Fcons (entry, menu_list);
+ 	    }
+ 
+ 	  /* Move past this element.  */
+ 	  if (idx >= 0 && idx + 1 >= XVECTOR (vector)->size)
+ 	    /* Handle reaching end of dense table.  */
+ 	    idx = -1;
+ 	  if (idx >= 0)
+ 	    idx++;
+ 	  else
+ 	    rest = Fcdr_safe (rest);
  	}
+     }
  
!   /* Put the entries in the proper order for the display function.  */
!   menu_list = Fnreverse (menu_list);
  
!   /* The car of the entries list is the prompt for the whole menu.  */
!   menu_list = Fcons (name, menu_list);
  
!   /* Display the menu, and prompt for a key.  */
!   if (NILP (Vkey_menu_prompt_function))
!     return Qnil;
!   else
!     return call1 (Vkey_menu_prompt_function, menu_list);
  }
  \f
  /* Reading key sequences.  */
***************
*** 10955,10960 ****
--- 10846,10868 ----
  	       doc: /* *How long to display an echo-area message when the minibuffer is active.
  If the value is not a number, such messages don't time out.  */);
    Vminibuffer_message_timeout = make_number (2);
+ 
+   DEFVAR_LISP ("key-menu-prompt-function", &Vkey_menu_prompt_function,
+ 	       doc: /* A function to display keyboard-menus, and read the user's response.
+ If nil, keyboard menus are disabled.
+ 
+ It is called with single argument, which is a list describing the keyboard menu
+ and should return the key the user types.
+ 
+ The argument is a list of the prompt and individual menu entries.
+ The format is as follows:
+ 
+        MENU  : (PROMPT ENTRY...)
+        ENTRY : (EVENT PROMPT [BINDING [TOGGLE_TYPE TOGGLE_STATE]])
+ 
+ Note that there is a prompt for the whole menu, and one for each
+ individual entry.  */);
+   Vkey_menu_prompt_function = Qnil;
  }
  
  void
diff -c lisp/subr.el.~1.305.~ lisp/subr.el
*** lisp/subr.el.~1.305.~	Sat Jun  1 09:02:46 2002
--- lisp/subr.el	Wed Jun  5 02:05:17 2002
***************
*** 656,661 ****
--- 656,748 ----
    (nth 3 position))
  
  \f
+ ;;;; Keyboard menu prompting
+ 
+ (defvar key-menu-event-face 'underline
+   "Face used to highlight the events in the keyboard-menu prompt.
+ Used by `key-menu-prompt'.")
+ (defvar key-menu-initial-separator "  "
+   "String used to separate a keyboard-menu prompt from the first key description.
+ Used by `key-menu-prompt'.")
+ (defvar key-menu-separator ",  "
+   "String used to separate adjacent keyboard-menu key descriptions.
+ Used by `key-menu-prompt'.")
+ (defvar key-menu-long-prompt-line-prefix "    "
+   "A prefix for entry lines when the menu prompt is very long.
+ Used by `key-menu-prompt'.")
+ 
+ (defun key-menu-prompt (menu)
+   "Display the keyboard-menu MENU, and read the user's response.
+ This function is appropiate for `key-menu-prompt-function', which see."
+   (let* ((prompt (concat (car menu) ":"))
+ 	 (prompt-width (string-width prompt))
+ 	 (cur-line "")
+ 	 (prefix nil)
+ 	 (sep "")
+ 	 (string prompt)
+ 	 (cur-line-width prompt-width)
+ 	 (max-width (frame-width)))
+     (dolist (entry (cdr menu))
+       (let* ((entry-prompt
+ 	      (if (eq (car entry) (aref (cadr entry) 0))
+ 		  (format "%s%s"
+ 			  (propertize (char-to-string (car entry))
+ 				      'face key-menu-event-face)
+ 			  (substring (cadr entry) 1))
+ 		(format "%s = %s"
+ 			(propertize (char-to-string (car entry))
+ 				    'face key-menu-event-face)
+ 			(cadr entry))))
+ 	     (entry-width
+ 	      (string-width entry-prompt))
+ 	     (appended-width
+ 	      (+ cur-line-width (string-width sep) entry-width)))
+ 	;; If this is the first line, first see if we'd be better off
+ 	;; wrapping right after the prompt (because the prompt string is
+ 	;; unusually long).  Note that we only do so if there are (1)
+ 	;; less than 4 entries already on the first line, and (2) the
+ 	;; prompt is greater than 12 characters wide; these values are
+ 	;; completely arbitrary.
+ 	(when (and (eq string prompt)
+ 		   (>= appended-width max-width)
+ 		   (> prompt-width (/ max-width 4)))
+ 	  ;; Wrap after the prompt
+ 	  (setq prefix key-menu-long-prompt-line-prefix
+ 		string (concat string "\n")
+ 		cur-line-width
+ 		(- cur-line-width (- prompt-width (string-width prefix)))
+ 		appended-width (+ cur-line-width entry-width)))
+ 	;; See if we have to wrap before the current entry (note that
+ 	;; this might happen even if we just wrapped after the prompt
+ 	;; above).
+ 	(if (< appended-width max-width)
+ 	    ;; It's OK to append the current entry, so do so
+ 	    (setq cur-line (concat cur-line sep entry-prompt)
+ 		  cur-line-width appended-width)
+ 	  ;; We have to wrap the current line first, and then append it
+ 	  (if prefix
+ 	      (setq string (concat string prefix cur-line "\n"))
+ 	    (setq string
+ 		  (concat string key-menu-initial-separator cur-line "\n")
+ 		  prefix
+ 		  (make-string (+ prompt-width
+ 				  (string-width key-menu-initial-separator))
+ 			       ? )))
+ 	  (setq cur-line entry-prompt
+ 		cur-line-width entry-width))
+ 	;; Update sep to the normal inter-entry value
+ 	(setq sep key-menu-separator)))
+ 
+     ;; Finally, display the menu, and read the user's input
+     (unless prefix
+       (setq prefix key-menu-initial-separator))
+     (setq string (concat string prefix cur-line))
+     (read-char string)))
+ 
+ ;; `key-menu-prompt-function' is defined in src/keyboard.c
+ (setq key-menu-prompt-function 'key-menu-prompt)
+ 
+ \f
  ;;;; Obsolescent names for functions.
  
  (defalias 'dot 'point)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]



-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> Richard Stallman <rms@gnu.org> writes:
> >     Is there any reason we couldn't make it call out to lisp to do the
> >     formatting?
> > 
> > It's ok with me if someone finds it easy to do.
> 
> What do you think of the appended patch?  It moves all the formatting
> and prompting for keyboard-menus to lisp (and in the process gets rid
> of the one-line-at-a-time interface, since the lisp code just displays
> the whole menu at once).

Just a little note: don't assume blindly that the minibuffer/echoarea
is always properly resized.  Think of the case where the frame is too
small.  Or when the user has set resize-mini-windows to nil.


	Stefan "whose Emacs does not know how to resize its
	        minibuffer-only frame"

Re: Assignment of misc packages for emacs

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> Just a little note: don't assume blindly that the minibuffer/echoarea
> is always properly resized.  Think of the case where the frame is too
> small.  Or when the user has set resize-mini-windows to nil.

Good point.  I thought before about the case where the menu was larger
than the largest minibuffer size -- but though such menus would be rare,
so support could be added later.  I guess not so rare after all...

Since all the interaction happens in the lisp function now, it'd
obviously be fairly simple to support menu paging (like the old C code
used to do).  What do I have to check?  I can think of:

     if resize-mini-windows == nil
       max-height is 1
     else if max-mini-window-height is an integer
       max-height is max-mini-window-height
     else
       max-height is min (1, trunc (frame-height * max-mini-window-height))

Does a minibuffer-only frame have to be special-cased?

Thanks,

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> Good point.  I thought before about the case where the menu was larger
> than the largest minibuffer size -- but though such menus would be rare,
> so support could be added later.  I guess not so rare after all...

Note that I don't know how common the problem is.  After all, in my case,
there's only 1 line, but it's about 230 chars long, so it shouldn't
be a problem (except that the code currently uses the selected frame instead
of the minibuffer's frame to determine the max line length, so it thinks
the minibuffer only has 80 chars per line).

>      if resize-mini-windows == nil
>        max-height is 1
>      else if max-mini-window-height is an integer
>        max-height is max-mini-window-height
>      else
>        max-height is min (1, trunc (frame-height * max-mini-window-height))

This last line doesn't look right.  The min(1,x) will always be 1.

> Does a minibuffer-only frame have to be special-cased?

I think so: it has a max-mini-window-height of 1.0.


	Stefan

PS: about the delay, I'd tend to agree that it's a bit surprising
    how eagerly the menu is displayed, but it has never bothered me.

Re: Assignment of misc packages for emacs

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> >        max-height is min (1, trunc (frame-height * max-mini-window-height))
> 
> This last line doesn't look right.  The min(1,x) will always be 1.

Whoops, I meant max.

> > Does a minibuffer-only frame have to be special-cased?
> 
> I think so: it has a max-mini-window-height of 1.0.

Hmmm, then `max (1, trunc (frame-height * max-mini-window-height))'
should return the right answer for minibuffer-only frames too (modulo
floating-point wierdness).

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Assignment of misc packages for emacs

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> except that the code currently uses the selected frame instead
> of the minibuffer's frame to determine the max line length, so it thinks
> the minibuffer only has 80 chars per line.

How is one supposed to determine the correct frame for the minibuffer?

Is (window-frame (minibuffer-window)) OK?

-Miles 
-- 
Run away!  Run away!

Re: Assignment of misc packages for emacs

[Richard Stallman]

    How is one supposed to determine the correct frame for the minibuffer?

    Is (window-frame (minibuffer-window)) OK?

(minibuffer-window) will tell you the window that will be used if you
invoke the minibuffer right away.  Likewise, (minibuffer-window) tells
you the window that would be used if you called `message' right now.
However, if you call `minibuffer-window' later on, while the minibuffer
or the echo area message is still visible, you won't necessarily get
the window that it is displayed in.

Re: Assignment of misc packages for emacs

[Richard Stallman]

There is also the case of a separate minibuffer frame.
That frame will not automatically get taller.

    Good point.  I thought before about the case where the menu was larger
    than the largest minibuffer size -- but though such menus would be rare,
    so support could be added later.  I guess not so rare after all...

    Since all the interaction happens in the lisp function now, it'd
    obviously be fairly simple to support menu paging (like the old C code
    used to do).  What do I have to check?  I can think of:

Instead of trying to anticipate all the reasons why the whole message
will not fit, I suggest you try displaying the whole message, then
check what part was actually displayed.  If it did not include the
whole message, you could try again starting with whatever did not make
it.

Maybe you could use `window-end' to figure out what part got
displayed.

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> >     Is there any reason we couldn't make it call out to lisp to do the
> >     formatting?
> > 
> > It's ok with me if someone finds it easy to do.
> 
> What do you think of the appended patch?  It moves all the formatting
> and prompting for keyboard-menus to lisp (and in the process gets rid
> of the one-line-at-a-time interface, since the lisp code just displays
> the whole menu at once).
> 

I would suggest that the key-menu-prompt function uses an abnormal
hook key-menu-format-entry-function to make it easy to provide
alternative formattings of the entries without having to deal with the
overall formatting and prompting of the key-menu (which need to be
more complex than the current implementation as Stefan has pointed
out).

Something like:

(defvar key-menu-format-entry-function nil
  "Function called to format key-menu entry.
Arguments are: EVENT PROMPT &optional BINDING TOGGLE-TYPE TOGGLE-STATE.
If nil, `key-menu-format-entry' is used.")

;; Args correspond to a menu ENTRY.
(defun key-menu-format-entry (event prompt &optional binding toggle-type toggle-state)
  (if (eq event (aref prompt 0))
      (format "%s%s"
	      (propertize (char-to-string event)
			  'face key-menu-event-face)
	      (substring prompt 1))
    (format "%s = %s"
	    (propertize (char-to-string event)
			'face key-menu-event-face)
	    prompt)))

(defun key-menu-prompt (menu)
  "Display the keyboard-menu MENU, and read the user's response.
This function is appropiate for `key-menu-prompt-function', which see."
  (let* (...)
    (dolist (entry (cdr menu))
      (let* ((entry-prompt
	      (apply (or key-menu-format-entry-function 'key-menu-format-entry) entry))
        ...


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

Re: Assignment of misc packages for emacs

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I would suggest that the key-menu-prompt function uses an abnormal
> hook key-menu-format-entry-function to make it easy to provide
> alternative formattings of the entries without having to deal with the
> overall formatting and prompting of the key-menu

That sounds reasonable.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Assignment of misc packages for emacs

[Miles Bader]

BTW, I find the fact that these keyboard-menus pop up immediately kind
of disconcerting (sort of unemacsy).  I think if the user hits the
prefix key immediately followed by another key, it shouldn't display
anything (right now if you do that, you see the menu quickly flash by,
no matter how quickly you type).

How about instead making them use the delay in `echo-keystrokes', so
hitting a `menufied' prefix key wouldn't display anything until after
the standard delay used to start echoing keystrokes in the echo area.

Perhaps instead there ought to be a separate delay used for keyboard
menus (maybe shorter?).

Thoughts?

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Assignment of misc packages for emacs

[Richard Stallman]

    How about instead making them use the delay in `echo-keystrokes', so
    hitting a `menufied' prefix key wouldn't display anything until after
    the standard delay used to start echoing keystrokes in the echo area.

    Perhaps instead there ought to be a separate delay used for keyboard
    menus (maybe shorter?).

I think it should be the same delay -- having a separate parameter
seems like creeping featurism.

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     How about instead making them use the delay in `echo-keystrokes', so
>     hitting a `menufied' prefix key wouldn't display anything until after
>     the standard delay used to start echoing keystrokes in the echo area.
> 
>     Perhaps instead there ought to be a separate delay used for keyboard
>     menus (maybe shorter?).
> 
> I think it should be the same delay -- having a separate parameter
> seems like creeping featurism.

IMO, there shouldn't be any delay for key-menus.  This functionality
is similar to a menu, and for menus we don't want any delay if we can
avoid it.

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

Re: Assignment of misc packages for emacs

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > I think it should be the same delay -- having a separate parameter
> > seems like creeping featurism.
> 
> IMO, there shouldn't be any delay for key-menus.  This functionality
> is similar to a menu, and for menus we don't want any delay if we can
> avoid it.

Well, exactly how you view it depends on who you are, I suspect.  In any
case, they're very different from normal mouse-menus (or some other
sorts of keyboard menus), because the latter are inherently visual,
whereas this sort of keyboard menu is _not_, it's really just a visual
aid added on top of the existing key-binding mechanism.

Sometimes visual aids are good, and sometimes they're a distraction.
I forsee two common ways of use:

 (1) For bindings the user knows well, they'll just hit the prefix key
     and the following key with no pause, and won't need to look at a
     menu at all -- and will be annoyed by any flash of the menu popping
     up and any extra slowness/GC caused by the menu code executing.

 (2) For bindings the user _doesn't_ know, they'll want the menu, to
     help them choose.  Since they're going to have to pause here anyway
     to examine the menu and think about what to do, a short delay for
     the menu to appear is not much of a problem.

     Morever, for me (like many other long-time emacs users, I suspect),
     it seems _natural_ because I'm used to the visual indication of a
     key prefix showing up in the echo area after a short delay, and
     because emacs generally avoids unnecessary verbiage when possible.
     For me, it seems like Just The Right Thing To Do.

The only existing (that I know of) use of this mechansim is in pcl-cvs's
diff menu, where `d d' will run a diff -- something which I do _very_
often, and hardly need a menu for.  I presume more and more people may
want to use this menu code after they become aware of it (for instance,
with a few tweaks, calc could probably use it for its many key
prefixes).  Having a menu suddenly pop _always_ where previously there
was none (unless you hit ?, in calc's case) would be very annoying for
many people, I think.

This, BTW is why I suggested that perhaps a different delay variable
might be appropriate.  For menus, I think a somewhat shorter delay than
the prefix-key-echoing is right -- you want to avoid them popping up
only in the case where you hit the prefix key and the following key in
quick succession (my case (1) above), and for case (2), you want the
menu to appear in a timely manner.  Also, beginners _may_ want to set
this delay to 0 (but I rather think not, actually, as long as it's not
so long).

Anyway, that's my rant on the issue.

-Miles

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Assignment of misc packages for emacs

[Richard Stallman]

    IMO, there shouldn't be any delay for key-menus.  This functionality
    is similar to a menu, and for menus we don't want any delay if we can
    avoid it.

Maybe you are right.

Re: Assignment of misc packages for emacs

[Richard Stallman]

The patch seems like a good idea, but I notice that it does a considerable
amount of manipulation of the menu data in C.  Couldn't that be moved
to Lisp also?  The menu key bindings are Lisp data.

Re: Assignment of misc packages for emacs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> The patch seems like a good idea, but I notice that it does a considerable
> amount of manipulation of the menu data in C.  Couldn't that be moved
> to Lisp also?  The menu key bindings are Lisp data.

It could be, but it seemed nice to have the format sent to lisp be
something simple and well defined -- raw keymaps are pretty complicated,
and the details tend to change over time.  I think the less places that
have to know about all the implementation details of keymaps, the
better.

The code in keyboard.c already has to deal with it, so it's natural to
keep the complexity there; also there's a convenient function
`parse_menu_item' in the C code which takes care of some of the
complexity.

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> Richard Stallman <rms@gnu.org> writes:
> > The patch seems like a good idea, but I notice that it does a considerable
> > amount of manipulation of the menu data in C.  Couldn't that be moved
> > to Lisp also?  The menu key bindings are Lisp data.
> 
> It could be, but it seemed nice to have the format sent to lisp be
> something simple and well defined -- raw keymaps are pretty complicated,
> and the details tend to change over time.  I think the less places that
> have to know about all the implementation details of keymaps, the
> better.
> 
> The code in keyboard.c already has to deal with it, so it's natural to
> keep the complexity there; also there's a convenient function
> `parse_menu_item' in the C code which takes care of some of the
> complexity.

Of course, ideally, the necessary "parsing" functions would be
exported to elisp.


	Stefan

Re: Assignment of misc packages for emacs

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> Of course, ideally, the necessary "parsing" functions would be
> exported to elisp.

Sure; seems like a lot of work to do it really well though.

-Miles
-- 
I have seen the enemy, and he is us.  -- Pogo

Re: Assignment of misc packages for emacs

[Richard Stallman]

    It could be, but it seemed nice to have the format sent to lisp be
    something simple and well defined -- raw keymaps are pretty complicated,
    and the details tend to change over time.

The code to understand the menu items has to be somewhere;
I don't see any reason why it should not be in Lisp.
After all, there is Lisp code to create menu items.

Meanwhile, this creates another ad-hoc representation for the same
data.  If we extend the capabilities of menus, might we have to make
an incompatible change in this representation?

Re: Assignment of misc packages for emacs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> The code to understand the menu items has to be somewhere; I don't see
> any reason why it should not be in Lisp.  After all, there is Lisp
> code to create menu items.
> 
> Meanwhile, this creates another ad-hoc representation for the same
> data.

Ok, sounds good to me [I mean, passing a raw keymap to the lisp code].

After looking at the C code more closely, I'm a bit confused about
what's actually happening (my patch just retained the original code for
scanning the keymaps, so I didn't write it).

It seems to use _multiple_ keymaps (the MAPS and NMAPS parameters),
which it merges to get all the menu entries.  Can any explain in what
situation you end up with multiple keymaps that need to be merged like
this?  Should the lisp function be passed a list of keymaps?

It would also be nice to have some helper functions/forms to assist lisp
code in manipulating the keymaps without caring too much about the
details.

For this current application, for instance, I'd like:

  1) something to iterate over the keymaps

     E.g. perhaps (dobindings (VAR KEYMAP [PREDICATE]) BODY..)

  2) accessor functions of some sort for the tricky bits

     For menu-items, as I mentioned earlier, there's already this handy
     C function `parse_menu_item' which could be used to do the bulk of
     the work for any accessor function(s).

     I'm not sure what would be better though, a bunch of individual
     accessor functions, e.g., (menu-item-help MENU-ITEM), or one big
     accessor function like (menu-item-property MENU-ITEM :help).

     The second would probably be easier to implement, since
     parse_menu_item fills in a table, so a general accessor funciton
     like `menu-item-property' could just have a list of
     keyword->table-index mappings.

What are people's opinions about the best way to do these things?
[Stefan...?]

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Assignment of misc packages for emacs

[Richard Stallman]

    It seems to use _multiple_ keymaps (the MAPS and NMAPS parameters),
    which it merges to get all the menu entries.  Can any explain in what
    situation you end up with multiple keymaps that need to be merged like
    this?

If the same prefix has bindings in the local map and the global map
(and maybe in minor mode maps), those bindings are all keymaps,
and they ought to be merged.

	   Should the lisp function be passed a list of keymaps?

That would be ok, or you could merge them in the C code and pass
one combined keymap.

      1) something to iterate over the keymaps

	 E.g. perhaps (dobindings (VAR KEYMAP [PREDICATE]) BODY..)

That seems like a useful idea.  How about taking a look at what XEmacs
has and considering making this compatible?

      2) accessor functions of some sort for the tricky bits

That might be a good idea, but it also carries the risk of making a
simple thing very heavyweight.

	 I'm not sure what would be better though, a bunch of individual
	 accessor functions, e.g., (menu-item-help MENU-ITEM), or one big
	 accessor function like (menu-item-property MENU-ITEM :help).

Two functions, menu-item-property and menu-item-properties, would make
it easy to do the whole thing in a fairly lightweight way.  But it
really depends on comparing two complete proposals to see how heavy
each one is.

Re: Assignment of misc packages for emacs

[Stefan Monnier]

> It seems to use _multiple_ keymaps (the MAPS and NMAPS parameters),

Yes, one might come from the global map, another from the local map,
yet others from various minor mode maps.

> which it merges to get all the menu entries.  Can any explain in what
> situation you end up with multiple keymaps that need to be merged like
> this?

They may all share the same prefix.

> Should the lisp function be passed a list of keymaps?

I think so, yes.

> It would also be nice to have some helper functions/forms to assist lisp
> code in manipulating the keymaps without caring too much about the
> details.
> 
> For this current application, for instance, I'd like:
> 
>   1) something to iterate over the keymaps
> 
>      E.g. perhaps (dobindings (VAR KEYMAP [PREDICATE]) BODY..)

XEmacs has map-keymap (and so does lucid.el).
CL has cl-map-keymap used internally for the `loop' macro where you can
loop over keybindings.
`map_keymap' (c|sh)ould also be used internally to avoid exposing the
internal representation of keymaps all over keyboard.c.

>   2) accessor functions of some sort for the tricky bits
> 
>      For menu-items, as I mentioned earlier, there's already this handy
>      C function `parse_menu_item' which could be used to do the bulk of
>      the work for any accessor function(s).
> 
>      I'm not sure what would be better though, a bunch of individual
>      accessor functions, e.g., (menu-item-help MENU-ITEM), or one big
>      accessor function like (menu-item-property MENU-ITEM :help).
> 
>      The second would probably be easier to implement, since
>      parse_menu_item fills in a table, so a general accessor funciton
>      like `menu-item-property' could just have a list of
>      keyword->table-index mappings.

How about (menu-item-property (parse-menu-item MENU-ITEM) :help) ?
Parsing can take a non-negligible time (it can run elisp code among
other things) so it would be good to be able to separate it from accessing
the actual data.


	Stefan

Re: Assignment of misc packages for emacs

[Richard Stallman]

    >      E.g. perhaps (dobindings (VAR KEYMAP [PREDICATE]) BODY..)

    XEmacs has map-keymap (and so does lucid.el).

One could write dobindings as a macro that expands into
map-keymap with a lambda expression inside.

What happened to the key-menu patch?

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> >     Is there any reason we couldn't make it call out to lisp to do the
> >     formatting?
> > 
> > It's ok with me if someone finds it easy to do.
> 
> What do you think of the appended patch?  It moves all the formatting
> and prompting for keyboard-menus to lisp (and in the process gets rid
> of the one-line-at-a-time interface, since the lisp code just displays
> the whole menu at once).
> 
> -Miles
> 
> 
> Patch:
> 

What happened to this patch?

There was some discussion how to accomplish this in a more general way
such as adding dobinding/map-keymap to be able to do more of the
function in Lisp, rather than in C (modifying the C-level code to use
Fmap_keymap as well).

Also, there was some discussion on improving the actual prompting,
but none of the alleged problems made have been bothering me [after all,
those key menus are not used very often].

FWIW, I applied the patch and have been using it since without problems.

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

Re: What happened to the key-menu patch?

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> What happened to this patch?
> 
> There was some discussion how to accomplish this in a more general way
> such as adding dobinding/map-keymap to be able to do more of the
> function in Lisp, rather than in C (modifying the C-level code to use
> Fmap_keymap as well).

I intend to do this (move the keymap interpretation into lisp), but
haven't got around to it yet.

I guess we should add a `map-keymap' for xemacs compatibility; I'm not
sure if it's worth it to add a `dobindings' macro or not.

Also, the xemacs docstring for `map-keymap' says:

   `map-keymap' is a built-in function
   (map-keymap FUNCTION KEYMAP &optional SORT-FIRST)
   Apply FUNCTION to each element of KEYMAP.  FUNCTION will be called
   with two arguments: a key-description list, and the binding.
   ...etc...

There are a few things I'm not sure about:

 (1) The xemacs manual doesn't seem to explain very well what `a
     key-description list' is, but it's something like (meta control x).
     I guess this is a canonical format for key names in xemacs, but it
     doesn't appear to be so in emacs, so I'm not sure how that argument
     should be handled (perhaps just punt, and pass whatever's stored in
     the keymap).

 (2) How are menu entries handled with this?  I'm not sure whether xemacs
     even stores menus in keymaps or not (it's somewhat hard to tell,
     since keyaps are an opaque type in xemacs, and just calling
     map-keymap doesn't yield anything obvious).  We could just pass the
     whole menu entry (e.g., (menu-item ...)) as the first argument, and
     perhaps extract the binding and pass it as the second arg, or even
     pass something else for that.

> Also, there was some discussion on improving the actual prompting,
> but none of the alleged problems made have been bothering me [after all,
> those key menus are not used very often].

Which problems?  I have a newer patch (at least I hope I still have it;
I'm at work now) that fixed some of the issues like menus bigger than
the maximum minibuffer size, but they're probably not things that would
affect the usual case (unless you're Stephan).

The other issue was that of a delay for menu popup, which you didn't
like, but I feel strongly should be supported, since I don't like the
current `eager' display (though the delay could be 0 by default if
that's better for newbies).

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: What happened to the key-menu patch?

[Stefan Monnier]

> I guess we should add a `map-keymap' for xemacs compatibility.

I don't think it's just for compatibility but also because it makes sense.

> sure if it's worth it to add a `dobindings' macro or not.

Agreed.  There's already a `loop' macro for it in CL.

>      key-description list' is, but it's something like (meta control x).
>      I guess this is a canonical format for key names in xemacs, but it
>      doesn't appear to be so in emacs, so I'm not sure how that argument
>      should be handled (perhaps just punt, and pass whatever's stored in
>      the keymap).

I don't think we should try to re-create the XEmacs (meta control x) form
from our M-C-x symbols.  We could provide an additional compatibility layer
on top of it, if it proves useful/necessary later on.

>  (2) How are menu entries handled with this?  I'm not sure whether xemacs
>      even stores menus in keymaps or not (it's somewhat hard to tell,
>      since keyaps are an opaque type in xemacs, and just calling
>      map-keymap doesn't yield anything obvious).  We could just pass the
>      whole menu entry (e.g., (menu-item ...)) as the first argument, and
>      perhaps extract the binding and pass it as the second arg, or even
>      pass something else for that.

XEmacs' keymap do not contain menu entries (of toolbar entries
for that matter).  As for how we should treat them, I think we should
not do anything special with them: i.e. `function' will be called
with key `menu-bar' and with the corresponding sub-keymap as the binding.

> affect the usual case (unless you're Stephan).
                                          ^^ f  (couldn't resist)

I have appended my current code.  It has several shortcomings, especially
the ugly "use integers to specify hard-coded C functions".  Also there
is the issue of eliminating/merging duplicate bindings, which I think
XEmacs' code punts on by declaring that `map-keymap' does not look at
the keymap's parent(s).
As you can see, the code is tentative and not ready for prime-time.
I only show it to give an idea of what I'm thinking of.


	Stefan


extern void menu_bar_item P_ ((Lisp_Object, Lisp_Object, Lisp_Object));
static void (*map_keymap_functions[])
     P_ ((Lisp_Object, Lisp_Object, Lisp_Object))
     = { menu_bar_item };

static void
map_keymap_item (closure, key, val)
     Lisp_Object closure, key, val;
{
  Lisp_Object fun = XCAR (closure);
  Lisp_Object args = XCDR (closure);
  if (EQ (val, Qt))
    val = Qnil;
  if (NATNUMP (fun))
    map_keymap_functions[XFASTINT (fun)](args, key, val);
  else
    call3 (fun, args, key, val);
}

static void
map_keymap_char_table_item (closure, key, val)
     Lisp_Object closure, key, val;
{
  if (!NILP (val))
    map_keymap_item (closure, key, val);
}

/* Call CLOSURE for every binding in MAP.
   CLOSURE is a cons cell of the form (FUN . ARGS).
   FUN is called with three arguments: FUN (ARGS, KEY, BINDING).
   If FUN is an integer, it denotes the index of the function to
   use from `map_keymap_functions'.  */
void
map_keymap (closure, map, autoload)
     Lisp_Object map, closure;
     int autoload;
{
  struct gcpro gcpro1, gcpro2, gcpro3;
  Lisp_Object tail;

  GCPRO3 (map, closure, tail);
  map = get_keymap (map, 1, autoload);
  for (tail = (CONSP (map) && EQ (Qkeymap, XCAR (map))) ? XCDR (map) : map;
       CONSP (tail) || (tail = get_keymap (tail, 0, autoload), CONSP (tail));
       tail = XCDR (tail))
    {
      Lisp_Object binding = XCAR (tail);
      
      if (CONSP (binding))
	map_keymap_item (closure, XCAR (binding), XCDR (binding));
      else if (VECTORP (binding))
	{
	  /* Loop over the char values represented in the vector.  */
	  int len = ASIZE (binding);
	  int c;
	  abort();
	  for (c = 0; c < len; c++)
	    {
	      Lisp_Object character;
	      XSETFASTINT (character, c);
	      map_keymap_item (closure, character, AREF (binding, c));
	    }
	}
      else if (CHAR_TABLE_P (binding))
	{
	  Lisp_Object indices[3];
	  map_char_table (map_keymap_char_table_item,
			  Qnil, binding, closure, 0, indices);
	}
    }
  UNGCPRO;
}

Re: What happened to the key-menu patch?

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > sure if it's worth it to add a `dobindings' macro or not.
> 
> Agreed.  There's already a `loop' macro for it in CL.

Yeah, but we don't really like cl in emacs, remember?  Oh wait, you do.

> >      key-description list' is, but it's something like (meta control x).
> >      I guess this is a canonical format for key names in xemacs, but it
> >      doesn't appear to be so in emacs, so I'm not sure how that argument
> >      should be handled (perhaps just punt, and pass whatever's stored in
> >      the keymap).
> 
> I don't think we should try to re-create the XEmacs (meta control x) form
> from our M-C-x symbols.  We could provide an additional compatibility layer
> on top of it, if it proves useful/necessary later on.

So, just pass whatever's stored in the keymap directly?

> >  (2) How are menu entries handled with this?
> 
> As for how we should treat them, I think we should not do anything
> special with them: i.e. `function' will be called with key `menu-bar'
> and with the corresponding sub-keymap as the binding.

That would be consistent with `lookup-key', but it also throws out
a bunch of useful information for menu-entries -- in particular, the
very information that I want for the key-menus!

How about just passing something similar to the corresponding arguments
to define-key, e.g., for keys, `function' would be the function, but
for menu-entries, it would be the whole (menu-item ...) list.

Either way, we have to provide some other sort of function to allow
easily going from one form to the other -- if we just pass the
function/sub-keymap, there needs to be a way for the user to lookup all
the menu-item information, and if we pass the (menu-item...) list
directly, there should probably be some access function(s) to make
getting at the various pieces cleanly.

Perhaps the thing to do is to pass only the function/sub-keymap by
default, but have an optional argument that says `pass all menu info for
menu-items'; this could possible be combined with Richard's suggestion
of having an option to suppress passing menu-items altogether.

We could (rather, should) add a similar optional argument to
`lookup-key' for conistency and utility.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: What happened to the key-menu patch?

[Stefan Monnier]

> > > sure if it's worth it to add a `dobindings' macro or not.
> > Agreed.  There's already a `loop' macro for it in CL.
> Yeah, but we don't really like cl in emacs, remember?  Oh wait, you do.

Indeed, I do.  And `loop' is a macro so it only needs CL at compile-time
which is usually regarded as OK.

> > >      key-description list' is, but it's something like (meta control x).
> > >      I guess this is a canonical format for key names in xemacs, but it
> > >      doesn't appear to be so in emacs, so I'm not sure how that argument
> > >      should be handled (perhaps just punt, and pass whatever's stored in
> > >      the keymap).
> > 
> > I don't think we should try to re-create the XEmacs (meta control x) form
> > from our M-C-x symbols.  We could provide an additional compatibility layer
> > on top of it, if it proves useful/necessary later on.
> 
> So, just pass whatever's stored in the keymap directly?

Yes.

> > >  (2) How are menu entries handled with this?
> > 
> > As for how we should treat them, I think we should not do anything
> > special with them: i.e. `function' will be called with key `menu-bar'
> > and with the corresponding sub-keymap as the binding.
> 
> That would be consistent with `lookup-key', but it also throws out
> a bunch of useful information for menu-entries -- in particular, the
> very information that I want for the key-menus!
> 
> How about just passing something similar to the corresponding arguments
> to define-key,

Yes, that's exactly what I meant and what my code does.

> e.g., for keys, `function' would be the function, but
> for menu-entries, it would be the whole (menu-item ...) list.

Yes, but I said `menu-bar' and the thing bound to `menu-bar'
is usually just a keymap because the menubar itself has no name:
only entries inside the keymap bound to `menu-bar' will
have `menu-item' thingies.

> Either way, we have to provide some other sort of function to allow
> easily going from one form to the other -- if we just pass the
> function/sub-keymap, there needs to be a way for the user to lookup all
> the menu-item information, and if we pass the (menu-item...) list
> directly, there should probably be some access function(s) to make
> getting at the various pieces cleanly.

Of course, we need to export some kind of parse-menu-item function,
as was discussed a few weeks/months back.

> Perhaps the thing to do is to pass only the function/sub-keymap by
> default, but have an optional argument that says `pass all menu info for
> menu-items'; this could possible be combined with Richard's suggestion
> of having an option to suppress passing menu-items altogether.

I think it's better to just pas the menu-items all the time: we'll
need the parse-menu-item functionality anyway.

> We could (rather, should) add a similar optional argument to
> `lookup-key' for conistency and utility.

I have also thought about it, but the need has never arisen
(not even in the C code).


	Stefan

Re: What happened to the key-menu patch?

[Richard Stallman]

      Also there
    is the issue of eliminating/merging duplicate bindings, which I think
    XEmacs' code punts on by declaring that `map-keymap' does not look at
    the keymap's parent(s).

By duplicate bindings do you mean shadowed bindings?

I think that if you ask for "scan the parents", by default you should
get all the bindings, including shadowed bindings.  However, there
could be an optional feature to ignore shadowed bindings.  That is not
terribly hard to do.  Just do a lookup for that event type, and see if
the binding that it reports is the one you have in hand.  I think that
there is already code to do this, probably in where-is-internal.

As for merging of subkeymaps, you don't have to worry about that.
read-key-sequence implicitly merges the keymaps that it gets for a
prefix key, when it gets them from different maps.  But it does not
merge the prefix definition from one map A with prefix definitions
from its parent B.  That is handled by making the prefix binding found
in map A have as its parent the prefix binding found in map B.
In other words, for scanning parents, you don't have to do anything
special when the binding is a keymap.

Re: What happened to the key-menu patch?

[Stefan Monnier]

>       Also there
>     is the issue of eliminating/merging duplicate bindings, which I think
>     XEmacs' code punts on by declaring that `map-keymap' does not look at
>     the keymap's parent(s).
> 
> By duplicate bindings do you mean shadowed bindings?

Both shadowed bindings and bindings which are both prefixes (such
that the first doesn't completely shadow the second).

> I think that if you ask for "scan the parents", by default you should
> get all the bindings, including shadowed bindings.  However, there
> could be an optional feature to ignore shadowed bindings.

What do you mean by "ignore" ?
Does that mean that if I do

	(let ((map (make-spase-keymap)))
	  (set-keymap-marent map global-map)
	  (define-key map "\C-x" (make-sparse-keymap)))

I'might never see any of the C-x bindings in `global-map' ?

> That is not
> terribly hard to do.  Just do a lookup for that event type, and see if
> the binding that it reports is the one you have in hand.  I think that
> there is already code to do this, probably in where-is-internal.

Lookup is O(N) and it would be done for every binding in the keymap,
so it might be easy but algorithmically expensive.
In the case of where-is-internal it's OK because it's done once after
scanning the whole keymap anyway.

> As for merging of subkeymaps, you don't have to worry about that.
> read-key-sequence implicitly merges the keymaps that it gets for a
> prefix key, when it gets them from different maps.  But it does not
> merge the prefix definition from one map A with prefix definitions
> from its parent B.  That is handled by making the prefix binding found
> in map A have as its parent the prefix binding found in map B.
> In other words, for scanning parents, you don't have to do anything
> special when the binding is a keymap.

Of course, I know about the fix_submap_inheritance kludge.
But the problem is that it might not have been executed yet,
so maybe map_keymap would need to do it.  Also what about merging
`menu-item's ?  Should they be merged ?


	Stefan

Re: What happened to the key-menu patch?

[Richard Stallman]

      Also what about merging
    `menu-item's ?

As far as I know, there is no reason ever to do this.  If you find two
menu items in scanning one keymap, the first should shadow the second.

    What do you mean by "ignore" ?
    Does that mean that if I do

	    (let ((map (make-spase-keymap)))
	      (set-keymap-marent map global-map)
	      (define-key map "\C-x" (make-sparse-keymap)))

    I'might never see any of the C-x bindings in `global-map' ?

That's correct.  I believe that read-key-sequence using this map
won't see them either.

Re: What happened to the key-menu patch?

[Stefan Monnier]

>       Also what about merging
>     `menu-item's ?
> 
> As far as I know, there is no reason ever to do this.  If you find two
> menu items in scanning one keymap, the first should shadow the second.

That's true for "leaf" menu-items but for menu-items corresponding to
prefix keys (i.e. submenus), there keymaps carried by the two menu-items
are merged.

>     What do you mean by "ignore" ?
>     Does that mean that if I do
> 
> 	    (let ((map (make-spase-keymap)))
> 	      (set-keymap-marent map global-map)
> 	      (define-key map "\C-x" (make-sparse-keymap)))
> 
>     I'might never see any of the C-x bindings in `global-map' ?
> 
> That's correct.  I believe that read-key-sequence using this map
> won't see them either.

Nope.  When looking up C-x, fix_submap_inheritance will end up doing
the equivalent of (set-keymap-parent .. (lookup-key "\C-x" global-map))
to the subkeymap built by the second `make-sparse-keymap).

It's the whole reason why fix_submap_inheritance was reason as
a matter of fact.


	Stefan

Re: What happened to the key-menu patch?

[Richard Stallman]

    > That's correct.  I believe that read-key-sequence using this map
    > won't see them either.

    Nope.  When looking up C-x, fix_submap_inheritance will end up doing
    the equivalent of (set-keymap-parent .. (lookup-key "\C-x" global-map))
    to the subkeymap built by the second `make-sparse-keymap).

You are right--the bindings in the second submap will be seen, but
they will be seen because they are included thus in the first submap.
When the scan actually reaches the second submap, it should ignore that.

Re: What happened to the key-menu patch?

[Stefan Monnier]

>     > That's correct.  I believe that read-key-sequence using this map
>     > won't see them either.
> 
>     Nope.  When looking up C-x, fix_submap_inheritance will end up doing
>     the equivalent of (set-keymap-parent .. (lookup-key "\C-x" global-map))
>     to the subkeymap built by the second `make-sparse-keymap).
> 
> You are right--the bindings in the second submap will be seen, but
> they will be seen because they are included thus in the first submap.
> When the scan actually reaches the second submap, it should ignore that.

But fix_submap_inheritance might not have been run yet, so map_keymap
should run it.


	Stefan

Re: What happened to the key-menu patch?

[Richard Stallman]

    But fix_submap_inheritance might not have been run yet, so map_keymap
    should run it.

Yes, I agree.

Re: What happened to the key-menu patch?

[Richard Stallman]

    I guess we should add a `map-keymap' for xemacs compatibility; I'm not
    sure if it's worth it to add a `dobindings' macro or not.

Ok, let's make it map-keymap.

     (1) The xemacs manual doesn't seem to explain very well what `a
	 key-description list' is, but it's something like (meta control x).

In Emacs this should be an event type.

     (2) How are menu entries handled with this?  I'm not sure whether xemacs
	 even stores menus in keymaps or not (it's somewhat hard to tell,
	 since keyaps are an opaque type in xemacs, and just calling
	 map-keymap doesn't yield anything obvious).

In XEmacs, menus are completely separate from keymaps.  (I think that
is a serious design error.)

We can handle menu items just like all other keymap entries.  Each
menu item is installed as the definition of some event type.
Following the usual specificiations, it should pass the the event type
as the first argument and the whole key binding value as the second
argument.  Everything should just work, if you write the function
properly.  It may not be necessary to do anything special for menu
bindings, or perhaps it is necessary to strip off the cached shortcut
info.

map-keymap should have an optional argument saying to ignore menu
bindings.

I think map-keymap should have another optional argument which
controls whether to scan the parent keymaps.  Let's choose the default
for this for compatibility with XEmacs, and make a non-nil argument
specify the other choice.

Re: What happened to the key-menu patch?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> It may not be necessary to do anything special for menu bindings, or
> perhaps it is necessary to strip off the cached shortcut info.

Of course, if we switch to using a hash-table to hold the cached
shortcut info, this problem goes away.

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: What happened to the key-menu patch?

[Richard Stallman]

    > It may not be necessary to do anything special for menu bindings, or
    > perhaps it is necessary to strip off the cached shortcut info.

    Of course, if we switch to using a hash-table to hold the cached
    shortcut info, this problem goes away.

I agree.  It would be nice for someone to implement that and see
how well it works.

Re: Assignment of misc packages for emacs

[Richard Stallman]

Now that the HierarKey menus are fixed, I see that after M-g it really
does output equivalents M-g d, M-g b, and so on.  I agree that this is not
useful, so I will take that out.

Re: Assignment of misc packages for emacs

[Richard Stallman]

    One additional trick is that M-x match prompts you for the directory
    using ido-read-directory, meaning that it is very easy to navigate to
    a completely different base directory.

I don't mind having ido as a feature available in Emacs, for whoever
wants to use it or enable it, but each specific command that reads a
directory name must be consistent with the rest of Emacs.  If you
install M-x match (or search-file-tree), please make it use the
standard file-name reading interface.

Re: Assignment of misc packages for emacs

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     One additional trick is that M-x match prompts you for the directory
>     using ido-read-directory, meaning that it is very easy to navigate to
>     a completely different base directory.
> 
> I don't mind having ido as a feature available in Emacs, for whoever
> wants to use it or enable it, but each specific command that reads a
> directory name must be consistent with the rest of Emacs.  If you
> install M-x match (or search-file-tree), please make it use the
> standard file-name reading interface.

It does -- unless you enable ido-mode.

Re: Assignment of misc packages for emacs

[Richard Stallman]

    > I don't mind having ido as a feature available in Emacs, for whoever
    > wants to use it or enable it, but each specific command that reads a
    > directory name must be consistent with the rest of Emacs.  If you
    > install M-x match (or search-file-tree), please make it use the
    > standard file-name reading interface.

    It does -- unless you enable ido-mode.

If you enable ido-mode, does that affect *all* reading of directory
names in the same way?  That would be the clean thing for it to do.
I guess your new variable is designed to make that possible.

Re: Assignment of misc packages for emacs

[Richard Stallman]

    > This sounds like the existing feature for handling menus on character
    > ttys.  Could you see how they compare?

    I can see the similarity in functionality, but for the simple use for
    which it is intended, I like mine better, as it is less intrusive and
    more similar to a keymap "with intermediate help in echo area".

We may be miscommunicating; when you speak of a keymap "with
intermediate help in echo area", I think you're talking of the feature
I'm talking about, which handles menus (keymaps) on character ttys.

    (defun replace-menu ()
     "Run a replace command specified in replace-commands."
     (interactive)
     (mini-menu replace-mini-menu))

What will that do under X?  Use the echo area?
It might be better to construct and use a menu keymap;
that would do more or less the same thing on a tty,
but under X, it would display a real menu.

Re: Assignment of misc packages for emacs

[Richard Stallman]

    I find this very easy to use; compare:

	    M-x match RET RET RET M-DEL RET

    to using e.g

	    M-x grep-find RET x_free_dpy_colors RET


Ok, please install this interface to grep.
The name `match' is not good, because it is too general;
it could fit many other activities.

I suggest the name `search-file-tree'.

Please don't install the new command yet though.
What to do about them is a separate issue, as I've
already mentioned.

Re: Assignment of misc packages for emacs

[D. Goel]

Richard Stallman <rms@gnu.org> writes:

>     Enhanced C-a:
> 
>     The first C-a always jumps to the beginning of the line (even if
>     the cursor is already there -- this is so keyboard macros can
>     consistenly depend on where C-a moves).
> 
> I don't like this.

RMS, i just wanted to point out that:

once you are at the beginning of line already, invoking C-a yet once
again does nothing at all, by default...  so one might as well add
funtionality to it---that it go to some place useful if it is already
at the beg-of-line.

In eshell, for instance, it seems esp. useful to have C-a toggle
between: beg-of-line and beg-of-user-prompt..

eshell:~ 
^^        ^^

viz. the two points underlined...


anyways, sorry for the blab..  
 

maybe you don't like it for good reason----users who are used to
default behavior of C-a might get confused or inconvenienced:

for instance, a user may, without looking at the screen, press C-a and
expect to be at beg-of-line. But what if she was already at
beg-of-line?  Surprise.. emacs has taken her somewhere else!..



D				   <http://www.glue.umd.edu/~deego/>
--