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: Sat, 18 Apr 2009 23:14:27 -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 1240111452 12012 80.91.229.12 (19 Apr 2009 03:24:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2009 03:24:12 +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 Sun Apr 19 05:25:31 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 1LvNer-000169-Jc for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2009 05:25:30 +0200 Original-Received: from localhost ([127.0.0.1]:59305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvNdS-0005p0-L4 for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 23:24:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvNdP-0005ou-Nt for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 23:23:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvNdK-0005oM-Ko for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 23:23:59 -0400 Original-Received: from [199.232.76.173] (port=58522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvNdK-0005oJ-En for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 23:23:54 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:35421) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LvNdJ-00080c-VX for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 23: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 n3J3NpDt008757; Sat, 18 Apr 2009 20:23:52 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n3J3K36l007557; Sat, 18 Apr 2009 20:20:03 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 19 Apr 2009 03: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.12401108776145 (code B ref 2887); Sun, 19 Apr 2009 03:20:03 +0000 Original-Received: (at 2887) by emacsbugs.donarmstrong.com; 19 Apr 2009 03:14:37 +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.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3J3EXLC006128 for <2887@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 20:14:35 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJsz6klLd+yz/2dsb2JhbACBTssOg30GhSg X-IronPort-AV: E=Sophos;i="4.40,211,1238990400"; d="scan'208";a="37271777" Original-Received: from 75-119-236-179.dsl.teksavvy.com (HELO ceviche.home) ([75.119.236.179]) by ironport2-out.teksavvy.com with ESMTP; 18 Apr 2009 23:14:27 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id A4FA7B408F; Sat, 18 Apr 2009 23:14:27 -0400 (EDT) In-Reply-To: (Arni Magnusson's message of "Sun, 19 Apr 2009 01:13:05 +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: Sat, 18 Apr 2009 23: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:27341 Archived-At: >> 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? Yes, at least. Maybe you can amortize it so it's only N+1 for N words. > It's an idea, but I still believe that many users would appreciate > binding single keystrokes to the functions I suggested. Yes, that's where we disagree. > (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)))) A perfect example of the kind of performance bug that comes up when you think in terms of lines, as encouraged by pos-at-beginning/end-of-line. The above should be: (defun comment-line-or-region () "Comment line or region." (interactive) (require 'newcomment) (if (and mark-active transient-mark-mode) (comment-region (save-excursion (goto-char (region-beginning)) (line-beginning-position)) (save-excursion (goto-char (region-end)) (line-end-position))) (comment-region (line-beginning-position) (line-end-position)))) line-number-at-pos is also a "function to avoid", just as bad as goto-line. Your code will walk over the whole buffer 4 times (twice to compute the line-number at region beg and end, then twice to find the beg/end of those 2 lines). >>> `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. I don't think the position-preservation is important enough to warrant a different command. So do C-SPC M-< before and C-u C-SPC afterwards if you want to preserve point. Or try to provide some way for flush-lines to operate on the whole buffer, without having to move point. Stefan