From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Key binding M-g should really be goto-line Date: Tue, 1 Mar 2005 20:06:27 -0600 (CST) Message-ID: <200503020206.j2226Rj21690@raven.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1109729284 17995 80.91.229.2 (2 Mar 2005 02:08:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2005 02:08:04 +0000 (UTC) Cc: jari.aalto@cante.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 02 03:08:03 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D6JGP-0008PP-Uh for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2005 03:07:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6JZ5-0005p8-Cf for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2005 21:26:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D6JYC-0005LW-3E for emacs-devel@gnu.org; Tue, 01 Mar 2005 21:25:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D6JY8-0005Hl-5Q for emacs-devel@gnu.org; Tue, 01 Mar 2005 21:25:21 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6JY7-0005GB-NT for emacs-devel@gnu.org; Tue, 01 Mar 2005 21:25:19 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D6JIO-0008PP-UV for emacs-devel@gnu.org; Tue, 01 Mar 2005 21:09:05 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j2228p9N006049; Tue, 1 Mar 2005 20:08:51 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j2226Rj21690; Tue, 1 Mar 2005 20:06:27 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: jari.aalto@cante.net In-reply-to: (jari.aalto@cante.net) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:34033 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34033 Jari Aalto wrote: "I want Emacs to move in the direction of doing word processing. It may take years, but we will get there. Then commands to specify faces will become important, and will need a good key binding. I chose the M-g binding for that reason, and the reason continues to have force. So I don't intend to change that binding." Please, I have been watching this future over 10 years now I personally do not have strong opinions on the goto-line binding. I personally use `M-x g-l RET' (with partial completion mode). In as far as the current state of Emacs' word processing capabilities are concerned: I am personally not a "word processor guy", but while proofreading the Emacs manual I took a close look at Enriched mode. Enriched mode used to have bugs that nearly made it unusable, except for very basic stuff. I recently checked and corrected the documentation and corrected bugs I found. I believe that Enriched mode currently largely "works" in the sense that it pretty much correctly does what it claims to be able to do. _But_ it only supports the text/enriched format _and_ it does so in a way conforming to RFC 1563, which has been obsolete since 1996. I believe that text/enriched should be updated for RFC 1896. (Assuming that this is still the most up to date standard. It was when I last checked.) Importantly, other formats should be supported. Last time we discussed this, at least one person seemed to interested in supporting additional formats. If such plans would actually materialize (of course, there is no guarantee of that until it actually happens), it could bring the future of "Emacs as a word processor" a lot closer. Updating for RFC 1896 would seem to be less complex and require less work than supporting new formats. Sincerely, Luc.