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, 04 Apr 2009 23:27:28 -0400 Message-ID: References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> <11531.194.144.135.59.1238888128.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 1238903050 20767 80.91.229.12 (5 Apr 2009 03:44:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2009 03:44:10 +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 05 05:45:29 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 1LqJIW-0004iX-7t for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Apr 2009 05:45:28 +0200 Original-Received: from localhost ([127.0.0.1]:35365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqJH8-0000cE-1x for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Apr 2009 23:44:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqJH2-0000bz-Hb for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 23:43:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqJGw-0000bn-Vf for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 23:43:55 -0400 Original-Received: from [199.232.76.173] (port=43112 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqJGw-0000bk-Pz for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 23:43:50 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:46369) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LqJGw-00015j-9E for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 23:43:50 -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 n353hlgd015354; Sat, 4 Apr 2009 20:43:48 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n353Z3KN012899; Sat, 4 Apr 2009 20:35: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, 05 Apr 2009 03:35: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.123890205911459 (code B ref 2887); Sun, 05 Apr 2009 03:35:03 +0000 Original-Received: (at 2887) by emacsbugs.donarmstrong.com; 5 Apr 2009 03:27:39 +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 n353RZJq011448 for <2887@emacsbugs.donarmstrong.com>; Sat, 4 Apr 2009 20:27:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOLB10nO+Lq2/2dsb2JhbACBUsh/hA8GhQk X-IronPort-AV: E=Sophos;i="4.39,325,1235970000"; d="scan'208";a="36227064" Original-Received: from 206-248-186-182.dsl.teksavvy.com (HELO pastel.home) ([206.248.186.182]) by ironport2-out.teksavvy.com with ESMTP; 04 Apr 2009 23:27:29 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 937438095; Sat, 4 Apr 2009 23:27:28 -0400 (EDT) In-Reply-To: <11531.194.144.135.59.1238888128.squirrel@www.hafro.is> (Arni Magnusson's message of "Sat, 4 Apr 2009 23:35:28 -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, 04 Apr 2009 23:43:55 -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:26914 Archived-At: > `backward-delete-word' > `delete-word' > Users can delete words while leaving the kill-ring unchanged. For example, > the user has copied a table from somewhere and is now deleting some words > before yanking the table where it belongs. It would be frustrating for the > user to yank and see recently deleted words instead of the table. Which leads to the following questions: - is it really that important given that the user could get the same result by yanking first and deleting the words afterwards? - why is this important for *kill-word, but not for all the other kill operations? - the most important one: who's going to do M-x delete-word rather than work around the problem some other way? I.e. such a command is basically useless unless it's bound to a key, so the problem is not so much the command as it is to find a key for it. > `kill-line-or-region' > Users can bind C-k to kill lines and regions (do what I mean), as an > alternative to the default C-k and C-w setup. That might be OK. Many people who'd like it, might prefer to just use some variant of delete-selection-mode, tho. > `pull-line-down' > `pull-line-up' > Users can move lines up and down more effectively thank with > `transpose-lines'. Can you summarize the difference? > `pos-at-beginning-of-line' > `pos-at-end-of-line' > Useful when writing a variety of editing functions. Should be in simple.el > for the same resons as `line-beginning-position' and `line-end-position' > are there. Actually, line-*-position are in the C code (and if they were written in Lisp, they should be in subr.el rather than in simple.el). The problem with pos-at-*-of-line is that goto-line is costly, so Elisp generally shouldn't encourage its use. > `zap-back-to-char' > `zap-up-to-char' > Zapping is typically to delete garbage until some important location. > The existing `zap-to-char' often deletes the beginning of that > important location, an opening brace or the like. I never use zap-to-char, so I'll let other people judge if that can be useful. > `clean-trails' > Like `delete-trailing-white', but reports how many lines were cleaned, and > deletes ^M as well. Many programs and programmers write files with > trailing spaces and ^M glyphs. It's nice to be able to clean those and get > body count in one keystroke. The report of number of lines cleaned sounds like a good addition to delete-trailing-whitespace. Not sure about ^M since I basically never bumped into it (or rather I always handle it via eol-conversion), but if it's useful, it would also be beter to incorporate it into delete-trailing-whitespace than create a new command for it. > `delete-all-blank-lines' > It's often useful to get rid of extra vertical spacing in source code, > output files, etc., sometimes undoing after enjoying the squeezed view. > Without this command, it would take a lot of keystrokes to delete all > blank lines while retaining the cursor buffer position. I've never needed such a command, so again, I'll let other people judge if it is sufficiently generally useful to find its way in Emacs. > `delete-indentation-nospace' > The `delete-indentation' command is very useful, but it often creates an > unwanted space. Users will probably bind this command to a keystroke close > to the `delete-indentation' keystroke. delete-indentation tries to guess when spaces are wanted. Maybe we could improve the guess instead? > `goto-longest-line' > Users can find out the maximum width (columns) of a text file, to check > the coding style or for some other reason. Sometimes it's easiest to call > "wc -L" via `shell-command' or `dired-do-shell-command', but > `goto-longest-line' will often be quicker and moves the cursor to the > longest line, for closer examination. > I remember when I wrote this command I thought about implementing a > separate non-interactive function called `longest-line' that would just > return the line number. Then `goto-longest-line' would call `longest-line' > to do the calculations, and other functions might call `longest-line' with > some other purpose than moving the cursor to it. I would be happy to > contribute a two-function implementation instead, since `longest-line' > might be useful for many users. There's no point not moving to the line, even if used from Elisp (since it's just as easy to wrap the call in a save-excursion if needed), so the command works as well from Lisp. > `downcase-word-or-region' > `upcase-word-or-region' > Users can bind M-l and M-u to downcase/upcase words or regions (do what I > mean), as an alternative to the default C-x C-l, C-x C-u, M-l, and M-u > setup. That sounds OK. This said, I think those new commands, unbound to any key, shouldn't be placed in simple.el (which is preloaded) but into some other file. I'm tempted to say "misc.el", where we could stuff any number of "commands that users might like, but for which we couldn't come up with a good key-binding". Stefan