From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Arni Magnusson Newsgroups: gmane.emacs.bugs Subject: bug#2887: Suggestions for simple.el Date: Sun, 19 Apr 2009 01:13:05 +0000 (GMT) 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: Arni Magnusson , 2887@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: ger.gmane.org 1240104256 543 80.91.229.12 (19 Apr 2009 01:24:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2009 01:24:16 +0000 (UTC) Cc: 2887@emacsbugs.donarmstrong.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 19 03:25:35 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 1LvLml-000127-Uv for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2009 03:25:32 +0200 Original-Received: from localhost ([127.0.0.1]:39787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvLlM-0002gz-Sx for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 21:24:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvLlH-0002fm-Ey for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 21:23:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvLlD-0002fS-1U for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 21:23:58 -0400 Original-Received: from [199.232.76.173] (port=52678 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvLlC-0002fP-Qk for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 21:23:54 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:41124) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LvLlC-0003QH-Aq for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 21:23:54 -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 n3J1NpNW007721; Sat, 18 Apr 2009 18:23:52 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n3J1K3NE006446; Sat, 18 Apr 2009 18:20:03 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Arni Magnusson Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 19 Apr 2009 01:20:03 +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.12401035995015 (code B ref 2887); Sun, 19 Apr 2009 01:20:03 +0000 Original-Received: (at 2887) by emacsbugs.donarmstrong.com; 19 Apr 2009 01:13:19 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from hafgarpur.hafro.is (hafgarpur.hafro.is [130.208.64.48]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3J1DEMm005008 for <2887@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 18:13:16 -0700 X-Virus-Scanned: amavisd-new at hafro.is Original-Received: from localhost.localdomain (hafstormur.hafro.is [130.208.66.52]) by hafgarpur.hafro.is (8.14.2/8.14.2/hafro-2.45) with ESMTP id n3J1D7D6012238; Sun, 19 Apr 2009 01:13:07 GMT Original-Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2/hafro-1.6) with ESMTP id n3J1D66c017203; Sun, 19 Apr 2009 01:13:06 GMT Original-Received: from localhost (arnima@localhost) by localhost.localdomain (8.14.2/8.14.2/hafro-0.3) with ESMTP id n3J1D53l017200; Sun, 19 Apr 2009 01:13:06 GMT X-Authentication-Warning: localhost.localdomain: arnima owned process doing -bs X-X-Sender: arnima@localhost.localdomain In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sat, 18 Apr 2009 21:23:58 -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:27339 Archived-At: >> `backward-delete-word' >> `delete-word' > > I would only consider some general "kill-next-kill" feature which would > allow to turn any killing command into a deleting one (e.g. a > kill-next-kill command which would cause the subsequent commands's > effect on the kill-ring to be cancelled). This would mean two keystrokes to delete a word, right? First `kill-next-kill' and then `kill-word'. It's an idea, but I still believe that many users would appreciate binding single keystrokes to the functions I suggested. They would most likely bind them to C-backspace and C-delete. >> `pos-at-beginning-of-line' >> `pos-at-end-of-line' > > The reimplementation doesn't change anything: its performance will still > suck on large files. It's just fundamentally an operation that is slow > and that we should generally avoid, so I don't want to add yet more ways > (additionally to goto-line) to do that. I don't understand, I think these functions are blazing fast. In practice, I would probably not use Emacs to perform 100,000 iterations on a 200 MB file - but that's why I'm surprised to see that it takes less than a second: 100000 M-x benchmark (pos-at-end-of-line 10) ; 0.421s I'm using a small arg of 10, because that's the case where you predicted that `line-end-position' would be much faster. 100000 M-x benchmark (line-end-position 10) ; 0.220s This is necessarily faster, since `pos-at-end-of-line' calls `line-end-position', but the (save-excursion (goto-char (point-min)) overhead is not as great as one might expect. With few iterations and large arg, the speed is also comparable: 10 M-x benchmark (pos-at-end-of-line 100000) ; 0.156s 10 M-x benchmark (line-end-position 100000) ; 0.156s Most things become more sluggish with a 200 MB file. Overall, I think these functions make it considerably easier to read and write functions that operate on buffer text - with minimal performance cost. In practice, I use it without iteration, and with a 1 MB source code file it doesn't register in a benchmark (0.000000s). I hesitate to introduce another function to the discussion, but here's an example where I use `pos-at-beginning-of-line' and `pos-at-end-of-line'. Since you're the maintainer of newcomment.el, it might pique your interest: (defun comment-line-or-region () "Comment line or region." (interactive) (require 'newcomment) (if (and mark-active transient-mark-mode) (comment-region (pos-at-beginning-of-line (line-number-at-pos (region-beginning))) (pos-at-end-of-line (line-number-at-pos (region-end)))) (comment-region (line-beginning-position)(line-end-position)))) Same idea as `kill-line-or-region'. Without the `pos-at-beginning-of-line' and `pos-at-end-of-line', (comment-region (region-beginning) (region-end)) it would misbehave when the region consists of a partially selected first and/or last line. Someone like you might be able to improve this function, but it's served me well and has no discernible speed lag. >> `delete-all-blank-lines' > > Can someone figure out a way to tweak flush-lines such that it can be > used for that purpose without having to jump through as many hooks? > Maybe we can just say that if you call flush-lines with an empty > argument (which currently would flush *all* lines) it will flush all > empty lines. This is definitely an idea, making better use of the default value of the regexp. But do you really mean flush all empty lines, or just the empty lines below the point? The idea behind `delete-all-blank-lines' is to really delete all empty lines, without moving the point, in one keystroke. I could probably edit `flush-lines' to do exactly that, although it operates only on text after the point for non-default regexps. Phew, it looks like the rest of our discussion threads have closed successfully, meaning that we have fully understood each others' ideas, and the decisions will depend on your good judgement and the Emacs elders. Cheers, Arni