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 15:32: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 1240083876 22693 80.91.229.12 (18 Apr 2009 19:44:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2009 19:44:36 +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 Sat Apr 18 21:45: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 1LvGTw-0002zk-I3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 21:45:44 +0200 Original-Received: from localhost ([127.0.0.1]:34697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvGSX-00037b-QA for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 15:44:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvGSH-0002y7-Sd for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 15:44:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvGSC-0002vU-34 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 15:44:00 -0400 Original-Received: from [199.232.76.173] (port=40419 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvGSB-0002vG-KU for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 15:43:55 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:40596) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LvGSA-0006ll-Px for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 15:43:55 -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 n3IJhpdu008825; Sat, 18 Apr 2009 12:43:52 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n3IJe4jT007541; Sat, 18 Apr 2009 12:40:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 18 Apr 2009 19:40:04 +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.12400831586106 (code B ref 2887); Sat, 18 Apr 2009 19:40:04 +0000 Original-Received: (at 2887) by emacsbugs.donarmstrong.com; 18 Apr 2009 19:32:38 +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 n3IJWXqu006093 for <2887@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 12:32:35 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAMvH6UlLd+7D/2dsb2JhbACBTssig30GhSg X-IronPort-AV: E=Sophos;i="4.40,210,1238990400"; d="scan'208";a="37265333" Original-Received: from 75-119-238-195.dsl.teksavvy.com (HELO pastel.home) ([75.119.238.195]) by ironport2-out.teksavvy.com with ESMTP; 18 Apr 2009 15:32:27 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D251F7EFC; Sat, 18 Apr 2009 15:32:27 -0400 (EDT) In-Reply-To: (Arni Magnusson's message of "Sat, 18 Apr 2009 00:08:46 +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 15:44:00 -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:27333 Archived-At: > `backward-delete-word' > `delete-word' > I think Emacs should provide a simple way for beginning users to have > C-backspace and C-delete behave like they would expect, i.e. leaving > the clipboard intact. There are different ways to provide this, using > a variable and/or functions. Users should not need to write their own > functions for something this fundamental. I think the difference between these and the standard commands is too small to deserve a separate command. There are plenty of ways to get around the problem of "kill when I only want delete" (typically, doing the kill after the C-y, or using M-y, ...). 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). > `kill-line-or-region' > C-k should probably be bound to this function. This would be appreciated by > many `transient-mark-mode' users. I haven't used Emacs without > transient-mark-mode', but don't those people still want C-w bound to > kill-region'? Yes, we couldn't really get rid of C-w, I think, but users of transient-mark-mode could use that key for other things. > `pull-line-down' > `pull-line-up' > These are admittedly simple tricks of lesser importance, but anyone trying > out the existing `transpose-lines' will read its documentation twice and try > to master pulling lines up or down, before giving up. I find myself using > these almost every day, with code, data, and config files. I don't find transpose-lines very useful, so I might accept a proposal that makes it more useful, but not one that adds yet more refinements. > `pos-at-beginning-of-line' > `pos-at-end-of-line' > You're right, it's best to avoid `goto-line'. I have reimplemented these > functions (see attachment) to improve the speed. I think they bridge an > obvious gap in Emacs Lisp, making it considerably easier to read and write > functions that operate on buffer text. 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. The "obvious gap" that you talk about is only "obvious" if you think in terms of lines, which is almost always the wrong way to think about the text in Emacs. > `zap-back-to-char' > `zap-up-to-char' > I believe these more useful than the existing `zap-to-char', which often > deletes the beginning of that important location, an opening brace or > the like. Maybe a better approach would be to add config var to zap-to-char whether it also zaps the char or not. In any case, I'd rather wait for other people to support this option, since I have no idea how common it is. > `delete-trailing-white' >> 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. > I agree that hardwiring [ \t\r] works fastest and is easy to use and > maintain. Attached is my proposed upgrade of this function, where cleaned > lines are counted. Thanks. We'll consider using it for Emacs-23.2. > `delete-all-blank-lines' > Vertical analog to `delete-trailing-white', which I use about as > often. Anyone trying out the existing `delete-blank-lines' will wonder > whether there is a keybinding to delete all blank lines, instead of just > around the point. 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. > `delete-indentation-nospace' > Similar to `delete-indentation' but leaves no space between the joined > lines. I find myself using these almost every day, with prose, code, data, > and config files. I have bound the two functions to neighboring keybindings. Here again, I'm not sure the difference is worth the trouble. I'd rather make fixup-whitespace customizable so you can specify when to keep a space and when not to. You can then customize it to never keep a space, and then use M-^ for delete-indentation-nospace and M-^ SPC when you do want a space. > `downcase-word-or-region' > `upcase-word-or-region' > M-l and M-u could be bound to this function. This would be appreciated by > many `transient-mark-mode' users. Yes, I think it would be a good change. > I haven't used Emacs without transient-mark-mode', but don't those > people still want C-x C-l and C-x C-u bound to `downcase-region' and > `upcase-region'? It's possible, but it's less sure than with C-w because those commands are used much less frequently, so it might be OK to just tell people to use C-u C-x C-x M-u instead of C-x C-u. Stefan