From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Danilo Segan Newsgroups: gmane.emacs.devel Subject: Re: Suggestion: Mapping of M-g should be goto-line Date: Thu, 25 Mar 2004 15:34:54 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <86hdwdc7w1.fsf@avet.kvota.net> References: <86brmldvbd.fsf@avet.kvota.net> <20040325123800.4ADA.JMBARRANQUERO@wke.es> <86zna5cdnp.fsf@avet.kvota.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1080225663 26154 80.91.224.253 (25 Mar 2004 14:41:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 25 Mar 2004 14:41:03 +0000 (UTC) Cc: Juanma Barranquero , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Mar 25 15:40:51 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B6W2N-0005vh-00 for ; Thu, 25 Mar 2004 15:40:51 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B6W2N-0007ap-00 for ; Thu, 25 Mar 2004 15:40:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B6W0N-0007h2-Mv for emacs-devel@quimby.gnus.org; Thu, 25 Mar 2004 09:38:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B6Vzo-0007XX-2o for emacs-devel@gnu.org; Thu, 25 Mar 2004 09:38:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B6VzD-0007Pk-Tm for emacs-devel@gnu.org; Thu, 25 Mar 2004 09:38:08 -0500 Original-Received: from [217.65.193.23] (helo=avet.kvota.net) by monty-python.gnu.org with smtp (Exim 4.30) id 1B6VzA-0007P8-6S for emacs-devel@gnu.org; Thu, 25 Mar 2004 09:37:33 -0500 Original-Received: (qmail 601 invoked by uid 1001); 25 Mar 2004 14:34:54 -0000 Original-To: David Kastrup Mail-Followup-To: David Kastrup , Juanma Barranquero , emacs-devel@gnu.org In-Reply-To: (David Kastrup's message of "25 Mar 2004 14:43:19 +0100") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20899 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20899 Today at 14:43, David Kastrup wrote: > Danilo Segan 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