From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#2887: Suggestions for simple.el Date: Tue, 07 Apr 2009 10:02:07 -0400 Message-ID: References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> <11531.194.144.135.59.1238888128.squirrel@www.hafro.is> <13654.194.144.135.59.1238962672.squirrel@www.hafro.is> <16717.194.144.135.59.1239072410.squirrel@www.hafro.is> Reply-To: Stefan Monnier , 2887@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1239114335 27259 80.91.229.12 (7 Apr 2009 14:25:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Apr 2009 14:25:35 +0000 (UTC) Cc: 2887@emacsbugs.donarmstrong.com To: "Arni Magnusson" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 07 16:26:54 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LrCF9-00066r-04 for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Apr 2009 16:25:39 +0200 Original-Received: from localhost ([127.0.0.1]:59018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrCDk-0005Vg-MY for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Apr 2009 10:24:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrCDV-0005Pq-Qk for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2009 10:23:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrCDR-0005Ou-KJ for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2009 10:23:57 -0400 Original-Received: from [199.232.76.173] (port=47524 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrCDR-0005OX-3h for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2009 10:23:53 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:46511) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrCDP-0003OI-No for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2009 10:23:52 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n37ENmrF018733; Tue, 7 Apr 2009 07:23:49 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n37E5856013283; Tue, 7 Apr 2009 07:05:08 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 14:05:08 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123911293712049 (code B ref 2887); Tue, 07 Apr 2009 14:05:08 +0000 Original-Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 14:02:17 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n37E2Ddl012033 for <2887@emacsbugs.donarmstrong.com>; Tue, 7 Apr 2009 07:02:15 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEALf52klMCqib/2dsb2JhbACBUs0Wg30GhQ4 X-IronPort-AV: E=Sophos;i="4.39,337,1235970000"; d="scan'208";a="36705415" Original-Received: from 76-10-168-155.dsl.teksavvy.com (HELO ceviche.home) ([76.10.168.155]) by ironport2-out.teksavvy.com with ESMTP; 07 Apr 2009 10:02:07 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 46409B4640; Tue, 7 Apr 2009 10:02:07 -0400 (EDT) In-Reply-To: <16717.194.144.135.59.1239072410.squirrel@www.hafro.is> (Arni Magnusson's message of "Tue, 7 Apr 2009 02:46:50 -0000 (GMT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 07 Apr 2009 10:23:57 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:26973 Archived-At: > The default behavior of practically all editors is to delete words > without altering the clipboard. The principle of least surprise says > Emacs should at least make it easy for users to bind C-backspace to > `backward-delete-word' and C-delete to `delete-word', if that's the > behavior they prefer. But do those editors offer the equivalent of M-y? > When I'm editing a 212MB text file, many things become sluggish, but > pos-at-*-of-line is not one of them: > M-x benchmark (pos-at-end-of-line 1000000) ; 0.157s This timing means that if a command calls this function for lines near point, that command becomes sluggish when you get to the end of the buffer. If it calls it 100 times, the command becomes completely unusable. > This speed is similar to line-*-position: > M-x benchmark (line-end-position 1000000) ; 0.172s > 10 M-x benchmark (line-end-position 1000000) ; 0.734s Of course. But line-end-position is usually called with small args because it's a relative position. > Here is a candidate upgrade of `delete-trailing-whitespace': Please send it as a patch so we can see what's changed rather than only see the end result. > This performs 4x faster than the first candidate upgrade, because the > regexp matches only 3 characters, whereas "\\s-+$" matches 147 different > characters in text-mode. Actually, it isn't quite for that reason, it's much worse: \s- is a regexp that may potentially match *any* character (depending on the syntax-table text-property), so contrary to [ \t\r] which can use a "fastmap" to quickly skip over irrelevant chars, \s- has to spend a lot more time on each char. > The syntax table definitions of whitespace can be confusing, e.g. the > ^M glyph is considered whitespace in text-mode but not in > emacs-lisp-mode... Agreed. > After this explanatory introduction, my real proposal is to define a > variable to determine the behavior of `delete-trailing-whitespace': > (defvar trailing-whitespace-regexp "\\s-+$" > "Regular expression describing what `delete-trailing-whitespace' > should delete. Note that regardless of the value of > `trailing-whitespace-regexp', `delete-trailing-whitespace' will never > delete formfeed and newline characters. > The default value \"\\\\s-+$\" uses the current syntax table definitions > of whitespace, but an expression like \"[ \\r\\t]+$\" is faster and > consistent across modes.") I think [ \t\r] is a good default, and if we introduce a config var (which I'm not sure is worth the trouble), there's no reason to keep the special treatment of formfeed. > (let ((count 0)(table (syntax-table))) > (modify-syntax-entry ?\f "." table) ; never delete formfeeds > (modify-syntax-entry ?\n "." table) ; never delete newline > (with-syntax-table table > (while (re-search-forward whitespace-regexp nil t) > (replace-match "")(setq count (1+ count))) > (message "Cleaned %d lines" count)))))) This modifies the current syntax-table (because `syntax-table' returns the table itself, not a copy). > Good point. Here are some undefined keystrokes in Emacs 22.3.1 that seem > to get through: > C-x j backward-delete-word > C-x C-j delete-word > C-x x kill-line-or-region > M-n pull-line-down > M-p pull-line-up > C-M-z zap-back-to-char > C-M-m zap-up-to-char > C-x C-a delete-all-blank-lines > M-& delete-indentation-nospace > C-x w goto-longest-line > C-x y downcase-word-or-region > C-x C-y upcase-word-or-region > Thank you for your patience and thoughtful responses, I think I will prefer to leave those unbound for now, waiting for more generally useful commands, or more general agreement that they are generally useful. Note that for some of them (e.g. kill-line-or-region or downcase-word-or-region), you might want to try and argue that their functionality should simply be folded into the kill-line resp. downcase-word (which might let us free up C-x C-u and C-x C-l, and maybe even C-w). Stefan