I’m on the tail end of five 18-hour days in crunch mode for a demo. Filing distro bug reports on an aesthetic/usability issue for an editor I don’t use is somewhat low on my list of prioritised tasks right now. But don’t let me stop you filing one…

That is surprising. That means Debian or Ubuntu are fucking up the default Emacs configuration, for some reason. The upstream sources turn on menu-bars and tool-bars by default. Maybe you should file a bug report.

Not sure you read me correctly. The default install disables the WIMP interface and until you dig through a few manpages and config files can you un-disable them.

The default emacs23 packages in Debian testing and Ubuntu Karmic are GTK builds.

Try installing a “Basic GNU emacs setup” in Ubuntu or Debian sometime. There’s no WIMP GUI with menubars, it’s disabled by default and you have to dig through a few manpages and experiment before finding the fastest way to turn it back on is to turn everything else off with -Q on startup. Not a good solution. And I didn’t find it till a month after giving up.

1. Options -> Set Default Fonts.
2. Pick a font from a bog-standard GTK font dialog
3. Options -> Save Options

I’m surprised you could do so much bitching about it.

Your comment could almost be an advertisement for vi, if you just changed the editor name and the commands. In vi, as with Emacs, it seems, we don’t use absolute line numbers much, but do use relative line numbers a fair amount. Of course, we don’t type “ctrl-u 5 ctrl-n” (five keystrokes), we just type “5j” (two keystrokes). Or, more frequently, we work in paragraphs, such as “3d}” to delete the following three paragraphs. And completion? The default completion in vim is “Esc-/” style, where it uses words from other files you’re editing (which actually works a lot better for me than completion based on API lookup).

People will argue about this, of course, but I think that vi wins when it comes to moving around and doing common actions with a minimal number of keystrokes and using keys close to the home row. On the other hand, if you want to program your editor to do something, I’d say that Emacs wins hands-down.

This is not a failing of Emacs itself, of course, but I’ve noticed that vi users, in general, tend to be pretty skilled with their editor, whereas a great proportion of Emacs users are very clumsy and inefficient with it. (They still use the arrow keys, they don’t use counts [Ctrl-U], they don’t use word and paragraph movement and selection, etc.)

That said, as a multi-decade (and thus now *very* hard-core) vi user, I’m still split on whether one would want to tell a new programmer to learn Emacs or vi.

If you’re getting your line number errors in an emacs buffer, then C-x ` (backtick) from the error buffer does a goto-line in the appropriate source buffer. I know this works with gcc and msvc compiler errors, perl errors from use strict, etc. So it probably works reasonably well if you are running command-line php from within emacs (e.g., by using it as the compile command for M-x compile, or via M-x shell).

If you’re using XEmacs, you can get line numbers trivially by doing M-x setnu — which will autoload and run setnu-mode. Speed will suffer on truly enormous source buffers, though.

I think the completion might be a personal thing – but again, it’s something that “Cream for Emacs” would have already set up. Myself, I’m happy to bind C-X C-] to C-] and go through the tags, I don’t even use C-X C-O that often.

If it works for you, wonderful – but that wasn’t the problem I was facing, which was that the learning curve is too steep for a beginning user who has any work to get done!

When I was doing my attempt to get accustomed to VI (similar to your emacs foray, I guess, and similarly unsuccesful), I learned about c-x c-o. It is subtly different from esc-/, probably in the way it iterates through available completions. I find the emacs one more fluent? intutive? matching my thinking? But I guess it’s a personal thing.