Jamie Zawinski's XEmacs Wishlist

This document is based on Jamie Zawinski's xemacs wishlist. Throughout this page, ``I'' refers to Jamie.

The list has been substantially reformatted and edited to fit the needs of this site. If you have any soul at all, you'll go check out the original. OK? You should also check out some other wishlists.

About the List

I've ranked these (roughly) from easiest to hardest; though of all of them, I think the debugger improvements would be the most useful. I think the combination of emacs+gdb is the best Unix development environment currently available, but it's still lamentably primitive and extremely frustrating (much like Unix itself), especially if you know what kinds of features more modern integrated debuggers have.

xemacs wishlist

Improve the keyboard macro system.

Keyboard macros are one of the most useful concepts that emacs has to offer, but there's room for improvement.

Make it possible to embed one macro inside of another.

Often, I'll define a keyboard macro, and then realize that I've left something out, or that there's more that I need to do; for example, I may define a macro that does something to the current line, and then realize that I want to apply it to a lot of lines. So, I'd like this to work:

`C-x (`	; start macro #1
`...`	; (do stuff)
`C-x )`	; done with macro #1
`...`	; (do stuff)
`C-x (`	; start macro #2
`C-x e`	; execute macro #1 (splice it into macro #2)
`C-s foo`	; move forward to the next spot
`C-x )`	; done with macro #2
`C-u 1000 C-x e`	; apply the new macro

That is, simply, one should be able to wrap new text around an existing macro. I can't tell you how many times I've defined a complex macro but left out the ``C-n C-a'' at the end...

Yes, you can accomplish this with M-x name-last-kbd-macro, but that's a pain. And it's also more permanent than I'd often like.

Make it possible to correct errors when defining a macro.

Right now, the act of defining a macro stops if you get an error while defining it, and all of the characters you've already typed into the macro are gone. It needn't be that way. I think that, when that first error occurs, the user should be given the option of taking the last command off of the macro and trying again.

The macro-reader knows where the bounds of multi-character command sequences are, and it could even keep track of the corresponding undo records; rubbing out the previous entry on the macro could also undo any changes that command had made. (This should also work if the macro spans multiple buffers, and should restore window configurations as well.)

You'd want multi-level undo for this as well, so maybe the way to go would be to add some new key sequence which was used only as the back-up-inside-a-keyboard-macro-definition command.

I'm not totally sure that this would end up being very usable; maybe it would be too hard to deal with. Which brings us to:
Make it possible to edit a keyboard macro after it has been defined.

I only just discovered edit-kbd-macro (C-x C-k). It is very, very cool.

The trick it does of showing the command which will be executed is somewhat error-prone, as it can only look up things in the current map or the global map; if the macro changed buffers, it wouldn't be displaying the right commands. (One of the things I often use macros for is operating on many files at once, by bringing up a dired buffer of those files, editing them, and then moving on to the next.)

However, if the act of recording a macro also kept track of the actual commands that had gotten executed, it could make use of that info as well.

Another way of editing a macro, other than as text in a buffer, would be to have a command which single-steps a macro: you would lean on the space bar to watch the macro execute one character (command?) at a time, and then when you reached the point you wanted to change, you could do some gesture to either: insert some keystrokes into the middle of the macro and then continue; or to replace the rest of the macro from here to the end; or something.

Another similar hack might be to convert a macro to the equivalent lisp code, so that one could tweak it later in ways that would be too hard to do from the keyboard (wrapping parts of it in `while' loops or something.) (M-x insert-kbd-macro isn't really what I'm talking about here: I mean insert the list of commands, not the list of keystrokes.)

Save my wrists!

In the spirit of the `teach-extended-commands-p' variable, it would be interesting if emacs would keep track of what are the commands I use most often, perhaps grouped by proximity or mode -- it would then be more obvious which commands were most likely candidates for placement on a toolbar, or popup menu, or just a more convenient key binding.

Bonus points if it figures out that I type ``bt\n'' and ``ret\ny\n'' into my *gdb* buffer about a hundred thousand times a day.
XmCreateFileSelectionBox

The thing that ``File/Open...'' pops up has excellent hack value, but as a user interface, it's an abomination. Isn't it time someone added a real file selection dialog already? (For the Motifly-challenged, the Athena-based file selector that GhostView uses seems adequate.)
Improve the toolbar system.

It's great that XEmacs has a toolbar, but it's damn near impossible to customize it.
1. Make it easy to define new toolbar buttons.
  
  Currently, to define a toolbar button that has a text equivalent, one must edit a pixmap, and put the text there! That's prohibitive. One should be able to add some kind of generic toolbar button, with a plain icon or none at all, but which has a text label, without having to use a paint program.
2. Make it easy to have customized, mode-local toolbars.
  
  In my c-mode-hook, for example, I can add a couple of new keybindings, and delete a few others, and to do that, I don't have to duplicate the entire definition of the c-mode-map. Making mode-local additions and subtractions to the toolbars should be as easy.
3. Make it easy to have customized, mode-local popup menus.
  
  The same situation holds for the right-mouse-button popup menu; one should be able to add new commands to those menus without difficulty. One problem is that each mode which does have a popup menu implements it in a different way...
Make the External Widget work.

About half of the work is done to make a replacement for the XmText widget which offloads editing responsibility to an external Emacs process. Someone should finish that. The benefit here would be that then, any Motif program could be linked such that all editing happened with a real Emacs behind it. (If you're Athena-minded, flavor with Text instead of XmText -- it's probably easy to make it work with both.)

The part of this that is done already is the ability to run an Emacs screen on a Window object that has been created by another process (this is what the ExternalClient.c and ExternalShell.c stuff is.) What is left to be done is, adding the text-widget-editor aspects of this.

First, the emacs screen being displayed on that window would have to be one without a modeline, and one which behaved sensibly in the context of ``I am a small multi-line text area embedded in a dialog box'' as opposed to ``I am a full-on text editor and lord of all that I survey.''

Second, the API that the (non-emacs-aware) user of the XmText widget expects would need to be implemented: give the caller the ability to pull the edited text string back out, and so on. The idea here being, hooking up emacs as the widget editor should be as transparent as possible.
Bring the debugger interface into the eighties.

Some of you may have seen my gdb-highlight.el package, that I posted to gnu.emacs.sources last month. I think it's really cool, but there should be a lot more work in that direction. For those of you who haven't seen it, what it does is watch text that gets inserted into the *gdb* buffer and make very nearly everything be clickable and have a context-sensitive menu. Generally, the types that are noticed are:
- function names;
- variable and parameter names;
- structure slots;
- source file names;
- type names;
- breakpoint numbers;
- stack frame numbers.
Any time one of those objects is presented in the *gdb* buffer, it is mousable. Clicking middle button on it takes some default action (edits the function, selects the stack frame, disables the breakpoint, ...) Clicking the right button pops up a menu of commands, including commands specific to the object under the mouse, and/or other objects on the same line.

So that's all well and good, and I get far more joy out of what this code does for me than I expected, but there are still a bunch of limitations. The debugger interface needs to do much, much more.
1. Make gdbsrc-mode not suck.
  
  The idea behind gdbsrc-mode is on the side of the angels: one should be able to focus on the source code and not on the debugger buffer, absolutely. But the implementation is just awful.
  
  First and foremost, it should not change ``modes'' (in the more general sense). Any commands that it defines should be on keys which are exclusively used for that purpose, not keys which are normally self-inserting. I can't be the only person who usually has occasion to actually edit the sources which the debugger has chosen to display! Switching into and out of gdbsrc-mode is prohibitive.
  
  I want to be looking at my sources at all times, yet I don't want to have to give up my source-editing gestures. I think the right way to accomplish this is to put the gdbsrc commands on the toolbar and on popup menus; or to let the user define their own keys (I could see devoting my kp_enter key to ``step'', or something common like that.)
  
  Also it's extremely frustrating that one can't turn off gdbsrc mode once it has been loaded, without exiting and restarting emacs; that alone means that I'd probably never take the time to learn how to use it, without first having taken the time to repair it...
2. Make it easier access to variable values.
  
  I want to be able to double-click on a variable name to highlight it, and then drag it to the debugger window to have its value printed.
  
  I want gestures that let me write as well as read: for example, to store value A into slot B.
3. Make all breakpoints visible.
  
  Any time there is a running gdb which has breakpoints, the buffers holding the lines on which those breakpoints are set should have icons in them. These icons should be context-sensitive: I should be able to pop up a menu to enable or disable them, to delete them, to change their commands or conditions.
  
  I should also be able to move them. It's annoying when you have a breakpoint with a complex condition or command on it, and then you realize that you really want it to be at a different location. I want to be able to drag-and-drop the icon to its new home.
4. Make a debugger status display window.
  - I want a window off to the side that shows persistent information -- it should have a pane which is a drag-editable, drag-reorderable representation of the elements on gdb's ``display'' list; they should be displayed here instead of being just dumped in with the rest of the output in the *gdb* buffer.
  - I want a pane that displays the current call-stack and nothing else. I want a pane that displays the arguments and locals of the currently-selected frame and nothing else. I want these both to update as I move around on the stack.
  - Since the unfortunate reality is that excavating this information from gdb can be slow, it would be a good idea for these panes to have a toggle button on them which meant ``stop updating'', so that when I want to move fast, I can, but I can easily get the display back when I need it again.
  The reason for all of this is that I spend entirely too much time scrolling around in the *gdb* buffer; with gdb-highlight, I can just click on a line in the backtrace output to go to that frame, but I find that I spend a lot of time looking for that backtrace: since it's mixed in with all the other random output, I waste time looking around for things (and usually just give up and type ``bt'' again, then thrash around as the buffer scrolls, and I try to find the lower frames that I'm interested in, as they have invariably scrolled off the window already...
5. Save and restore breakpoints across emacs/debugger sessions.
  
  This would be especially handy given that gdb leaks like a sieve, and with a big program, I only get a few dozen relink-and-rerun attempts before gdb has blown my swap space.
6. Keep breakpoints in sync with source lines.
  
  When a program is recompiled and then reloaded into gdb, the breakpoints often end up in less-than-useful places. For example, when I edit text which occurs in a file anywhere before a breakpoint, emacs is aware that the line of the bp hasn't changed, but just that it is in a different place relative to the top of the file. Gdb doesn't know this, so your breakpoints end up getting set in the wrong places (usually the maximally inconvenient places, like after a loop instead of inside it). But emacs knows, so emacs should inform the debugger, and move the breakpoints back to the places they were intended to be.
(Possibly the OOBR stuff does some of this, but can't tell, because I've never been able to get it to do anything but beep at me and mumble about environments. I find it pretty funny that the manual keeps explaining to me how intuitive it is, without actually giving me a clue how to launch it...)
Add better dialog box features.

It'd be nice to be able to create more complex dialog boxes from emacs-lisp: ones with checkboxes, radio button groups, text fields, and popup menus.
Add embeddable dialog boxes.

One of the things that the now-defunct Energize code (the C side of it, that is) could do was embed a dialog box between the toolbar and the main text area -- buffers could have control panels associated with them, that had all kinds of complex behavior.
Make the mark-stack be visible.

You know, I've encountered people who have been using emacs for years, and never use the mark stack for navigation. I can't live without it; ``C-u C-SPC'' is among my most common gestures.
1. It would be a lot easier to realize what's going to happen if the marks on the mark stack were visible. They could be displayed as small ``caret'' glyphs, for example; something large enough to be visible, but not easily mistaken for a character or for the cursor.
2. The marks and the selected region should be visible in the scrollbar as well -- I don't remember where I first saw this idea, but it's very cool: there's a second, less-strongly-rendered ``thumb'' in the scrollbar which indicates the position and size of the selection; and there are tiny tick-marks which indicate the positions of the saved points.
3. Markers which are in registers (point-to-register, C-x /) should be displayed differently (more prominent.)
4. It'd be cool if you could pick up markers and move them around, to adjust the points you'll be coming back to later.
Write a new garbage collector.

The emacs GC is very primitive; it is also, fortunately, a rather well isolated module, and it would not be a very big task to swap it with a new one (once that new one was written, that is.) Someone should go bone up on modern GC techniques, and then just dive right in...
Add support for lexical scope to the emacs-lisp runtime.

Yadda yadda, this list goes to eleven.

Subject:	Re: XEmacs wishlist
Date:	Wed, 14 May 1997 16:18:23 -0700
From:	Jamie Zawinski <jwz@netscape.com>
Newsgroups:	comp.emacs.xemacs, comp.emacs

Andreas Schwab wrote:

Use `C-u C-x (':
start-kbd-macro:
Non-nil arg (prefix arg) means append to last macro defined; This begins by re-executing that macro as if you typed it again.

Cool, I didn't know it did that...

But it only lets you append. I often want to prepend, or embed the macro multiple times (motion 1, C-x e, motion 2, C-x e, motion 3.)

Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML