From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Suggestion: Mapping of M-g should be goto-line Date: 25 Mar 2004 21:27:16 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87oeqlj79q.fsf@offby1.atm01.sea.blarg.net> <200403251639.i2PGdXDF030749@Tempo.Update.UU.SE> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1080268690 24928 80.91.224.253 (26 Mar 2004 02:38:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 26 Mar 2004 02:38:10 +0000 (UTC) Cc: offby1@blarg.net, ams@kemisten.nu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Mar 26 03:38:01 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 1B6hEP-00086p-00 for ; Fri, 26 Mar 2004 03:38:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B6hEO-0007AW-00 for ; Fri, 26 Mar 2004 03:38:00 +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 1B6hBu-0004v6-Aj for emacs-devel@quimby.gnus.org; Thu, 25 Mar 2004 21:35:26 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B6hBk-0004ty-Uf for emacs-devel@gnu.org; Thu, 25 Mar 2004 21:35:16 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B6h4k-0003bA-6K for emacs-devel@gnu.org; Thu, 25 Mar 2004 21:28:33 -0500 Original-Received: from [206.47.199.166] (helo=simmts8-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B6h4A-0003DQ-Ij; Thu, 25 Mar 2004 21:27:26 -0500 Original-Received: from empanada.local ([67.71.118.2]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040326022713.LIOV21833.simmts8-srv.bellnexxia.net@empanada.local>; Thu, 25 Mar 2004 21:27:13 -0500 Original-Received: by empanada.local (Postfix, from userid 502) id 559E4144A15; Thu, 25 Mar 2004 21:27:16 -0500 (EST) Original-To: David Kastrup In-Reply-To: Original-Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:20950 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20950 >> >> >> For what it's worth I always thought C-c C-c was the natural binding >> >> >> for `compile' (or more generally for "here, I'm done editing, now >> >> >> process what I've edited"). [...] >> Isn't AUCTeX's central dispatcher supposed to be a "better compile" >> so that you don't need compile for those cases? > Better? It substitutes for most of it, yes, but if you have > processes like weaving a noweb file or other autogenerated stuff, > AUCTeX can be a bit tedious. For example, generating index and > glossary and so on often is done by Makefiles in more complicated > projects. But people who need that can do M-x compile RET, right? After all that's what they do already. > Well, Gnus sends mail and articles with C-c C-c, Yes, exactly what I said "process what I've edited". I've never felt the need to compile an email. > calc finished editing, Do you mean it just quits with C-c C-c? Or does it take the result of your editing and processes it? > PCL-vcs aborts a job, That was maybe a poor choice. > most shell modes send an interrupt (don't tell me you never want to use > compile from a shell), and so on. I never want to use compile from a shell, to tell you the truth. Why would you ever want to? > It's not exactly the least used key combination. Indeed and it often means "process what Ive just edited", which in an email means "send it" and in a C buffer means "compile it". C-c C-c is currently globally unbound and I suggest we bind it to `compile'. Major modes would be encouraged to override it with mode-specific implementations of the idea of "process what I've just edited", like AUCTeX and message already do. Stefan