[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion: Mapping of M-g should be goto-line

From: Danilo Segan
Subject: Re: Suggestion: Mapping of M-g should be goto-line
Date: Thu, 25 Mar 2004 13:55:48 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux)

Today at 13:25, Jari Aalto wrote:

> * Thu 2004-03-25 Danilo Segan <dsegan <AT> gmx.net> mail.default.spool
> | That's only a reason to educate them better, ...
> That is not the correct way. I believe that if there is functionality
> that is not appropriate for the 99 % of the users, it should be
> changed - not matter what other "education" might then be.

I'm not arguing for keeping M-g bound to face changing functions.  I'm
arguing for not using goto-line more than next-error and other
mechanisms, since they're *easier* to use.

> But you missed the point. Emacs is a companion. It should be a good
> one.  Right now M-g is not a good companion. It could be much better
> with goto-line.

Exactly, and it would be even better if it was bound to next-error.
You're not bringing any points that my view is not a valid one, or
usage patterns where using goto-line is easier than next-error, or
"emacsclient [+LINE[:COLUMN]]".  Visual tools should provide a way to
enter any editor at "current" line (like DVI viewers do), and
creating web pages is only a very tiny subset of what people do with
Emacs today.

> | I suggest you try "emacsclient -n +5 path/to/file"
> | ... With all this, I rarely if ever need to use M-x goto-line.  
> For you maybe. I believe the more user friendly Emacs is, the better
> people get a hand on it. 

This seems strange.  Are you actually claiming that if I compile a
program in one xterm, and get an error like

   some-main-file.c:655: error, this is error

it's easier for me to remember filename (main.c), line number (655),
switch to Emacs (which might hide the current xterm, or which might
be in the different workspace), find-file main.c (for which I usually
need to type couple of path components as well), type
whatever-the-shortcut for goto-line (eg. M-g), and enter the line 
number (provided I didn't forget it this far :)?  Instead of the simple

   emacsclient -n +655 some-main-file.c

while reading both the line number and filename on the screen (so no
need to remember them), and making use of name completion in the

How could the first approach using goto-line be "more user friendly"
than the latter?  If that's your point, I strongly disagree.  And no,
I'm not talking only about me, I'm talking about everyone using a
terminal outside Emacs for such tasks.

> Why do you think there is vi(1) people that never touched emacs?

Some, at least, do it for religious reasons ;)  vi also has a
completely different philosophy, and all the things that stand for
Emacs, also stand for vi, and maybe even more so -- it's even harder
for newbies to use, so I don't really understand your bringing it up
(and those who want may try M-x viper instead).  I surely don't
think Emacs should try to replicate "user-friendliness" of vi ;)

> Or Windows users that use programmer's file editor instead of Emacs?

Because Emacs is entirely different from how other Windows programs
behave?  C-x, C-c don't do the tasks people got used them to do in
Windows environment?

> Little things can make a difference sometimes. M-g could play a tiny
> part towards it.

Yeah, but I'm still not convinced that binding goto-line there is
that tiny part towards it.

> | For "average joe", we want to make them learn the better way.
> Sure, they can add line to .emacs to map goto-line. Everybody
> can. Millions of users can. But that's unproductive and unnecessary.

I'm not that insane to claim that adding a line to .emacs is the
"better way" if a feature is to be used by most of the users.  I'm
trying to point out that there's such a need for goto-line only
because other Emacs features which are the right way are not exposed
enough: so, we need to expose them instead, not to expose goto-line.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]