emacs-devel
[Top][All Lists]
Advanced

[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 15:34:54 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux)

Today at 14:43, David Kastrup wrote:

> Danilo Segan <address@hidden> writes:
>> 
>> Sorry if I sounded too harsh -- I just want the defaults to be good,
>
> M-g for goto-line is a good default.  

Such a blank statement is not really something I'd consider a good
analysis.  Certainly, you're an established Emacs hacker and
power-user (at least compared to me), so you do have some knowledge of
what is good and what is not good for Emacs.

Yet, the point you seem to be missing is that M-g is also a good
default for infinitely many other things.  And that's why I'm making
such a fuss about it.

> "Educating" users is not the task of an editor, and certainly not by
> willful omission of features.  Next thing you'll propose educating
> users about key combinations by removing the menus.  And educating
> them about M-x delete-file RET by making shell-mode barf on rm.

Ah, so I see.  Let's put cua-mode as a default; after all, majority
of potential Emacs users lurk there.  Lets not "educate" users that
C-c is not for copying with the lame excuse that it's better suited
for many other shortcuts.

Or, is in fact Emacs already doing what I'm "hereticaly" proposing?
Educating users with a different way of working?  Yeah, I guessed
so.  Those who do not want to be "educated", need to load all sort
of stuff (like M-x viper or cua-mode), in order to use what they
already know.

I didn't propose removing goto-line function, but rather, if we're
looking for improvements, lets make improvements where they matter
as well (perhaps where they matter even more).  And Kim Storm
expanded that point in the area where it also seems very much
relevant.

> That's not the way to go about it.  Education of users is by making
> the available information more accessible, not by hiding away all
> other possibilities and making them inconvenient.

Please, tell me how did you come up with this?  Did what I "proposed"
make goto-line in any way more inconvenient compared to what we have
now?

I repeatedly argued only for having next-error *more* visible than
goto-line, not for obscuring goto-line at all, on the assumption that
it's supposed to be more useful.  Juanma doesn't agree with this
assumption, so he naturally doesn't agree that next-error should
receive more exposure.  It's up to Emacs developers to decide whether
my assumption is correct, since they worked on next-error
functionality, and they know whether it was supposed to be more useful
(FAQ entry seems to indicate it was)--perhaps it failed?

Since you seem to be pretty much concerned with my usage of word
"educate", I'll point out that I'm using it in the sense of "make
aware of features in Emacs" (whether by making them more accessible
from UI, writing about them in more appropriate places in manual,
advertising them, or whatever), not only by forcing users to learn
current behaviour.  Perhaps I chose the wrong word.  If so, I'm deeply
sorry about it.

Cheers,
Danilo




reply via email to

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