From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: "Arni Magnusson" , 2887@debbugs.gnu.org Resent-From: "Arni Magnusson" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 04 Apr 2009 13:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: report 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12388519376065 (code B ref -1); Sat, 04 Apr 2009 13:40:04 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 4 Apr 2009 13:32:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n34DWDqG006058 for ; Sat, 4 Apr 2009 06:32:14 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lq5ym-00088I-NG for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 09:32:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lq5yi-00083M-CI for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 09:32:12 -0400 Received: from [199.232.76.173] (port=49655 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lq5yi-000836-8Z for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 09:32:08 -0400 Received: from hafgarpur.hafro.is ([130.208.64.48]:36389) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lq5yh-0003Ld-Ln for bug-gnu-emacs@gnu.org; Sat, 04 Apr 2009 09:32:07 -0400 X-Virus-Scanned: amavisd-new at hafro.is Received: from hafrun.hafro.is (hafrun.hafro.is [130.208.58.66]) by hafgarpur.hafro.is (8.14.2/8.14.2/hafro-2.45) with ESMTP id n34DW360010121 for ; Sat, 4 Apr 2009 13:32:03 GMT Received: from www.hafro.is (localhost [127.0.0.1]) by hafrun.hafro.is (8.14.2/8.14.2/hafro-1.6) with ESMTP id n34DW3rk019922 for ; Sat, 4 Apr 2009 13:32:03 GMT Received: from 194.144.135.59 (SquirrelMail authenticated user arnima) by www.hafro.is with HTTP; Sat, 4 Apr 2009 13:32:03 -0000 (GMT) Message-ID: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> Date: Sat, 4 Apr 2009 13:32:03 -0000 (GMT) From: "Arni Magnusson" To: bug-gnu-emacs@gnu.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20090404133203_61019" X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) ------=_20090404133203_61019 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear Emacs maintainers, I would like to suggest adding a few functions to the simple.el library. I do this with hesitation - since I know the idea is to keep it simple and let users write extensions to suit their preferences - but I believe a large number of Emacs users would appreciate having access to these functions out of the box. I just finished teaching an Emacs workshop, where I ended up distributing these functions to my colleagues, but I found it hard to explain whey they're not already in simple.el. Please see the attached file suggestions-simple.el. Instead of giving detailed reasons for including each function, I have only briefly commented on which functionality I'm extending, or which gap I'm bridging. I have used these functions a lot, but I am sure the Emacs maintainers can see ways to improve them in terms of robustness, speed, function names, documentation, etc. I would be happy to discuss any further details with you. All the best, Arni Magnusson ------=_20090404133203_61019 Content-Type: text/x-emacs-lisp; name="suggestions-simple.el" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="suggestions-simple.el" ;; simple::backward-kill-word ;; subr::backward-delete-char (defun backward-delete-word (N) "Delete previous N words." (interactive "*p")(delete-word (- N))) ;; simple::kill-word ;; C::delete-char (defun delete-word (N) "Delete following N words." (interactive "*p") (delete-region (point)(save-excursion (forward-word N)(point)))) ;; simple::kill-line ;; simple::kill-region (defun kill-line-or-region () "Kill region if selected, otherwise kill line." (interactive) (if (and mark-active transient-mark-mode)(kill-region (point)(mark))(kill-line))) ;; simple::transpose-lines ;; simple::kill-whole-line (defun pull-line-down (N) "Pull line down N times." (interactive "*p") (let ((col (current-column)))(kill-whole-line 1)(forward-line N)(yank 1)(pop kill-ring)(forward-line -1) (move-to-column col))) ;; simple::transpose-lines ;; simple::kill-whole-line (defun pull-line-up (N) "Pull line up N times." (interactive "*p") (let ((col (current-column)))(kill-whole-line 1)(forward-line (- N))(yank 1)(pop kill-ring)(forward-line -1) (move-to-column col))) ;; simple::goto-line ;; C::point (defun pos-at-beginning-of-line (N) "Return the position at beginning of line N." (save-excursion (goto-line N)(point))) (defun pos-at-end-of-line (N) "Return the position at end of line N." (save-excursion (goto-line N)(end-of-line)(point))) ;; simple::zap-to-char ;; C::delete-region (defun zap-back-to-char (char) "Delete region back to, but not including, CHAR." (interactive "cZap back to char: ") (let ((case-fold-search nil)) (delete-region (point)(progn (search-backward (char-to-string char))(forward-char)(point))))) ;; simple::zap-to-char ;; C::delete-region (defun zap-up-to-char (char) "Delete region up to, but not including, CHAR." (interactive "cZap to char: ") (let ((case-fold-search nil)) (delete-region (point)(progn (search-forward (char-to-string char))(backward-char)(point))))) ;; simple::delete-trailing-whitespace ;; whitespace::whitespace-buffer (defun clean-trails () "Delete ^M glyphs, spaces, and tabs from line ends." (interactive) ; \r means ^M (save-excursion (goto-char (point-min)) ; unlike delete-trailing-whitespace, clean-trails removes ^M (\r) in lisp-mode (let ((count 0))(while (re-search-forward "[\r\t ]+$" nil t)(replace-match "")(setq count (+ count 1))) (message "Cleaned %d lines" count)))) ;; simple::delete-blank-lines ;; whitespace::whitespace-buffer (defun delete-all-blank-lines () "Delete all blank lines in buffer." (interactive) (save-excursion (goto-char (point-min)) (let ((count 0))(while (search-forward "\n\n" nil t)(goto-char (point-min)) (while (search-forward "\n\n" nil t)(replace-match "\n")(setq count (+ count 1))) (goto-char (point-min))) (if (= (following-char) 10)(progn (delete-char 1)(setq count (+ count 1)))) (message "Deleted %d blank lines" count)))) ;; simple::delete-indentation (defun delete-indentation-nospace () "Join this line to previous with no whitespace at join." (interactive) (delete-indentation)(delete-horizontal-space)) ;; simple::end-of-buffer ;; simple::goto-line (defun goto-longest-line () "Go to longest line in buffer." (interactive) (let ((line 1)(length 0)) (save-excursion (goto-char (point-min))(end-of-line)(setq length (current-column)) (while (not (eobp)) (progn (end-of-line 2) (if (> (current-column) length)(progn (setq line (line-number-at-pos))(setq length (current-column))))))) (goto-line line)(message "Line %d is %d characters" line length))) ;; C::downcase-region ;; C::downcase-word ;; belongs in simple (defun downcase-word-or-region (N) "Downcase N words or region." (interactive "*p") (if (and mark-active transient-mark-mode)(downcase-region (point)(mark))(downcase-word N))) (defun upcase-word-or-region (N) "Upcase N words or region." (interactive "*p") (if (and mark-active transient-mark-mode)(upcase-region (point)(mark))(upcase-word N))) ------=_20090404133203_61019-- From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 04 Apr 2009 14:25:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123885487820321 (code B ref 2887); Sat, 04 Apr 2009 14:25:05 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 4 Apr 2009 14:21:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n34ELEuS020314 for <2887@emacsbugs.donarmstrong.com>; Sat, 4 Apr 2009 07:21:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAKoJ10nO+Lq2/2dsb2JhbACBUsplhA8GhQk X-IronPort-AV: E=Sophos;i="4.39,324,1235970000"; d="scan'208";a="36209481" 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 10:21:08 -0400 Received: by pastel.home (Postfix, from userid 20848) id 853D08095; Sat, 4 Apr 2009 10:21:08 -0400 (EDT) From: Stefan Monnier To: Arni Magnusson Cc: 2887@debbugs.gnu.org Message-ID: References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> Date: Sat, 04 Apr 2009 10:21:08 -0400 In-Reply-To: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> (Arni Magnusson's message of "Sat, 4 Apr 2009 13:32:03 -0000 (GMT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Please see the attached file suggestions-simple.el. Instead of giving > detailed reasons for including each function, I have only briefly > commented on which functionality I'm extending, or which gap I'm bridging. I'd rather see detailed reasons for each function/command you suggest. E.g. why do you need a backward-delete-word when we already provide backward-kill-word? Stefan From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: "Arni Magnusson" , 2887@debbugs.gnu.org Resent-From: "Arni Magnusson" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 04 Apr 2009 23:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123888814114561 (code B ref 2887); Sat, 04 Apr 2009 23:40:04 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 4 Apr 2009 23:35:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n34NZaRe014547 for <2887@emacsbugs.donarmstrong.com>; Sat, 4 Apr 2009 16:35:38 -0700 X-Virus-Scanned: amavisd-new at hafro.is Received: from hafrun.hafro.is (hafrun.hafro.is [130.208.58.66]) by hafgarpur.hafro.is (8.14.2/8.14.2/hafro-2.45) with ESMTP id n34NZSEH017120; Sat, 4 Apr 2009 23:35:28 GMT Received: from www.hafro.is (localhost [127.0.0.1]) by hafrun.hafro.is (8.14.2/8.14.2/hafro-1.6) with ESMTP id n34NZRmI020577; Sat, 4 Apr 2009 23:35:27 GMT Received: from 194.144.135.59 (SquirrelMail authenticated user arnima) by www.hafro.is with HTTP; Sat, 4 Apr 2009 23:35:28 -0000 (GMT) Message-ID: <11531.194.144.135.59.1238888128.squirrel@www.hafro.is> In-Reply-To: References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> Date: Sat, 4 Apr 2009 23:35:28 -0000 (GMT) From: "Arni Magnusson" To: "Stefan Monnier" Cc: 2887@debbugs.gnu.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Thank you, Stefan, for the prompt reply and interest. Please find below my list of raisons d'être. Arni `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. `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. `pull-line-down' `pull-line-up' Users can move lines up and down more effectively thank with `transpose-lines'. `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. `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. `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. `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. `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. `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. `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. From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 05 Apr 2009 03:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123890205911459 (code B ref 2887); Sun, 05 Apr 2009 03:35:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 5 Apr 2009 03:27:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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" 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 Received: by pastel.home (Postfix, from userid 20848) id 937438095; Sat, 4 Apr 2009 23:27:28 -0400 (EDT) From: Stefan Monnier To: "Arni Magnusson" Cc: 2887@debbugs.gnu.org Message-ID: References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> <11531.194.144.135.59.1238888128.squirrel@www.hafro.is> Date: Sat, 04 Apr 2009 23:27:28 -0400 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) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > `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 From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Leo , 2887@debbugs.gnu.org Resent-From: Leo Original-Sender: news Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 05 Apr 2009 14:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12389416082581 (code B ref -1); Sun, 05 Apr 2009 14:35:03 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Apr 2009 14:26:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n35EQhXN002569 for ; Sun, 5 Apr 2009 07:26:45 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqTJ4-0000rm-Q9 for bug-gnu-emacs@gnu.org; Sun, 05 Apr 2009 10:26:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqTIz-0000rZ-Fl for bug-gnu-emacs@gnu.org; Sun, 05 Apr 2009 10:26:41 -0400 Received: from [199.232.76.173] (port=53129 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqTIz-0000rW-8U for bug-gnu-emacs@gnu.org; Sun, 05 Apr 2009 10:26:37 -0400 Received: from main.gmane.org ([80.91.229.2]:53764 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LqTIy-00086b-TY for bug-gnu-emacs@gnu.org; Sun, 05 Apr 2009 10:26:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LqTIv-0000W8-GZ for bug-gnu-emacs@gnu.org; Sun, 05 Apr 2009 14:26:33 +0000 Received: from smaug.linux.pwf.cam.ac.uk ([193.60.95.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Apr 2009 14:26:33 +0000 Received: from sdl.web by smaug.linux.pwf.cam.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Apr 2009 14:26:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Leo Date: Sun, 05 Apr 2009 15:26:17 +0100 Organization: University of Cambridge Lines: 19 Message-ID: References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> <11531.194.144.135.59.1238888128.squirrel@www.hafro.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: smaug.linux.pwf.cam.ac.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:XN3Yodh3Jowfv5n7dT08TXAgaOY= Sender: news X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) On 2009-04-05 04:27 +0100, Stefan Monnier wrote: >> `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. I think those functions are already in emacs. Take a look at its lisp dir, i think it is misc.el. -- .: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :. www.git-scm.com git - the one true version control system From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: "Arni Magnusson" , 2887@debbugs.gnu.org Resent-From: "Arni Magnusson" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 05 Apr 2009 20:25:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123896269314155 (code B ref 2887); Sun, 05 Apr 2009 20:25:07 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 5 Apr 2009 20:18:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n35KI3DD014134 for <2887@emacsbugs.donarmstrong.com>; Sun, 5 Apr 2009 13:18:05 -0700 X-Virus-Scanned: amavisd-new at hafro.is Received: from hafrun.hafro.is (hafrun.hafro.is [130.208.58.66]) by hafgarpur.hafro.is (8.14.2/8.14.2/hafro-2.45) with ESMTP id n35KHqJe001173; Sun, 5 Apr 2009 20:17:54 GMT Received: from www.hafro.is (localhost [127.0.0.1]) by hafrun.hafro.is (8.14.2/8.14.2/hafro-1.6) with ESMTP id n35KHpuG021823; Sun, 5 Apr 2009 20:17:52 GMT Received: from 194.144.135.59 (SquirrelMail authenticated user arnima) by www.hafro.is with HTTP; Sun, 5 Apr 2009 20:17:52 -0000 (GMT) Message-ID: <13654.194.144.135.59.1238962672.squirrel@www.hafro.is> In-Reply-To: References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> <11531.194.144.135.59.1238888128.squirrel@www.hafro.is> Date: Sun, 5 Apr 2009 20:17:52 -0000 (GMT) From: "Arni Magnusson" To: "Stefan Monnier" Cc: 2887@debbugs.gnu.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Thank you, Stefan, for the insightful comments. We're discussing quite a few things at once, but I'll try to be concise: >> `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? 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. > - why is this important for *kill-word, but not for all the other kill > operations? Because deleting words is probably the most common deletion, after deleting characters. It would frustrate many more users if `delete-char' would alter the kill ring. > - 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. The Emacs manual and the documentation of `kill-word' and `backward-kill-word' could mention that some users may prefer binding C-backspace to `backward-delete-word' and C-delete to `delete-word'. >> `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. Again, the important distinction between killing and deleting. Even in `delete-selection-mode', the `kill-line-or-region' command is useful for yanking the text later. >> `pull-line-down' >> `pull-line-up' > >> Users can move lines up and down more effectively thank with >> `transpose-lines'. > > Can you summarize the difference? To move a line 3 down, call `pull-line-down' 3 times or with a numerical argument of 3. Likewise with `pull-line-up'. Most Emacs users would probably do this by killing and yanking, but it's considerably quicker using the pull-line-* commands. The `transpose-lines' command may be useful in some circumstances, but not in the tasks described above. >> `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. My commands that call pos-at-*-of-line work faster than I can blink my eyes, but I understand your concern. To optimize the speed the functions would probably need to be implemented in C code, but that's beyond my programming capabilities. Still, if I'm not mistaken, Emacs Lisp programmers would have to use something just as expensive to perform this task, so pos-at-*-of-line would save them some typing and thinking. >> `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. It's a common task to delete everything between the point and another location. Zapping is best if that location contains a somewhat rare character, usually some kind of symbol or parenthesis. In my experience the character itself should usually not be deleted as well. >> `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. Yes, it would be a nice improvement to upgrade the `delete-trailing-whitespace' command so it counts cleaned lines. Files with mixed Unix/Dos line endings are sometimes created when people using different OS's work together on a project. Many programs choke on input files that contain mixed Unix/Dos line endings, often without helpful error messages. If the Emacs maintainers decide to make `delete-trailing-whitespace' also delete trailing ^M in mixed line-ending files, it would make me (and presumably many other users) happy, but it might create a backwards-compatibility issue. Adding an &optional ctrl-M flag to `delete-trailing-whitespace' (non-nil to remove trailing ^M as well) would not enable to users to bind a simple keystroke to do that. What I propose is a separate function `delete-trailing-whitespace-M' that removes both trailing whitespace and trailing ^M in files with mixed line endings. A bulky solution, but I think users will appreciate 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. It's often a good way to get an overview of code that is vertically stretched. I remove all comments (one keystroke) and all blank lines (another keystroke), absorb the information and undo. I also use it on certain program input files where blank lines would be problematic. >> `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? These functions are used in a wide variety of situations (text, code, data), making guesswork practically hopeless. I use `delete-indentation' and `delete-indentation-nospace' a lot, and I'm not sure which one I use more frequently. >> `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. Good call, one function it is. >> `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. Great. > 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". I would slip them into simple.el, since they load very fast and rhyme with what's already there. Allow me to propose the following bindings that are undefined in Emacs 22.3.1: C-x C-backspace backward-delete-word C-x C-delete delete-word C-; kill-line-or-region M-n pull-line-down M-p pull-line-up C-, zap-back-to-char C-. zap-up-to-char C-' clean-trails C-" delete-all-blank-lines M-& delete-indentation-nospace C-= goto-longest-line M-down downcase-word-or-region M-up upcase-word-or-region From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Lennart Borgman , 2887@debbugs.gnu.org Resent-From: Lennart Borgman Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 05 Apr 2009 22:05:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.12389688119916 (code B ref 2887); Sun, 05 Apr 2009 22:05:06 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 5 Apr 2009 22:00:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-bw0-f157.google.com (mail-bw0-f157.google.com [209.85.218.157]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n35M05rs009362 for <2887@emacsbugs.donarmstrong.com>; Sun, 5 Apr 2009 15:00:07 -0700 Received: by bwz1 with SMTP id 1so2189938bwz.1 for <2887@emacsbugs.donarmstrong.com>; Sun, 05 Apr 2009 15:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CggayBwrD+79KRaNxsvJMjH1DWmrjA87xzhO279Gcw0=; b=p6iXhFjcI9f+62OmQABC36T4clfyVt8QfTVu2UCz0PGEtELqEF9AE/GTUKnEzXFsQd PvbvUyd2wstkGvF+cFXqHLuxvXN8OAB5aSp61btwIX2JnzS1wSmsRirkK39xvNsL2Myb WRzLngPOD0a0DAj8CtP2LCZyI8Pt0YbTv/LB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ff/khfDDRZ5BexZ3UHisOFEpLquWp21Y+zw1ta7Q5H9ulqMqZoQipF6ZLytMbCcDCs C8ocfhwKn2uW6SAsaM4uxBZudcdWq3YM3ELWW8lu8jJtmktNJ+F+LMN+c7sNaKtZCnfI JRjHZ4eag1r59oNoCIHMKNAHjgoiiWZG+IkJY= MIME-Version: 1.0 Received: by 10.223.126.66 with SMTP id b2mr3147035fas.3.1238968799289; Sun, 05 Apr 2009 14:59:59 -0700 (PDT) In-Reply-To: <13654.194.144.135.59.1238962672.squirrel@www.hafro.is> 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> Date: Sun, 5 Apr 2009 23:59:59 +0200 Message-ID: From: Lennart Borgman To: Arni Magnusson , 2887@debbugs.gnu.org Cc: Stefan Monnier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 5, 2009 at 10:17 PM, Arni Magnusson wrote: >>> 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. > > It's often a good way to get an overview of code that is vertically > stretched. I remove all comments (one keystroke) and all blank lines > (another keystroke), absorb the information and undo. I also use it on > certain program input files where blank lines would be problematic. I can see the idea, but I would suggest a minor mode that hide comments and blank lines instead. That would allow editing the file with comments and blank line hidden. > M-down =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 downcase-word-or-region > M-up =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 upcase-word-or-region Key bindings is a scarce resource. Those two bindings are already used by windmove.el for moving between windows (and that is something that perhaps should be on by default). From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 06 Apr 2009 02:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123898407315278 (code B ref 2887); Mon, 06 Apr 2009 02:20:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 6 Apr 2009 02:14:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n362ETIw015270 for <2887@emacsbugs.donarmstrong.com>; Sun, 5 Apr 2009 19:14:31 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowGAM8B2UlMCqib/2dsb2JhbACBUsYzhA8GhQk X-IronPort-AV: E=Sophos;i="4.39,327,1235970000"; d="scan'208";a="36474869" Received: from 76-10-168-155.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.155]) by ironport2-out.teksavvy.com with ESMTP; 05 Apr 2009 22:14:23 -0400 Received: by pastel.home (Postfix, from userid 20848) id 674C6807E; Sun, 5 Apr 2009 22:14:23 -0400 (EDT) From: Stefan Monnier To: "Arni Magnusson" Cc: 2887@debbugs.gnu.org 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> Date: Sun, 05 Apr 2009 22:14:23 -0400 In-Reply-To: <13654.194.144.135.59.1238962672.squirrel@www.hafro.is> (Arni Magnusson's message of "Sun, 5 Apr 2009 20:17:52 -0000 (GMT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > The Emacs manual and the documentation of `kill-word' and > `backward-kill-word' could mention that some users may prefer binding > C-backspace to `backward-delete-word' and C-delete to `delete-word'. The Emacs manual is already "too large" to contain all the info we want to put in it, so mentioning such things is unlikely. But it's probably a good idea to add those commands to misc.el. Then the EmacsWiki can mention them. > My commands that call pos-at-*-of-line work faster than I can blink my > eyes, but I understand your concern. Try them on 200MB buffers. > To optimize the speed the functions would probably need to be > implemented in C code, but that's beyond my programming > capabilities. The core loop is in goto-line and is already written in C. > Still, if I'm not mistaken, Emacs Lisp programmers would > have to use something just as expensive to perform this task, so > pos-at-*-of-line would save them some typing and thinking. The point is to force them to use goto-line explicitly, so as to hopefully make the cost more obvious. > It's a common task to delete everything between the point and another > location. Zapping is best if that location contains a somewhat rare > character, usually some kind of symbol or parenthesis. In my experience > the character itself should usually not be deleted as well. I tend to use C-s for that (as well as for movement). But I understand that other people have other habits. > Yes, it would be a nice improvement to upgrade the > `delete-trailing-whitespace' command so it counts cleaned lines. Feel free to provide a patch for it (tho, since we're in the pretest, there's no hurry: it won't be installed right now). > Files with mixed Unix/Dos line endings are sometimes created when people > using different OS's work together on a project. Many programs choke on > input files that contain mixed Unix/Dos line endings, often without > helpful error messages. I understand the problem, yes. I just don't know it enough to understand which kind of solution is more handy. The few times I've had such a thing, I just did M-% C-q C-m RET RET !. For such rare occurrences, anything more specialized would be useless because I wouldn't remember it. Obviously, if it happens commonly to you, you'll want another solution. > If the Emacs maintainers decide to make `delete-trailing-whitespace' also > delete trailing ^M in mixed line-ending files, it would make me (and > presumably many other users) happy, but it might create a > backwards-compatibility issue. It might, but I'm not sure it'd be such a big deal. The docstring explicitly mentions that a form-feed is not considered as whitespace by this function, so that might be taken to mean that "every other whitespace-like chars" (such as C-m) would be considered as whitespace. > These functions are used in a wide variety of situations (text, code, > data), making guesswork practically hopeless. I use `delete-indentation' > and `delete-indentation-nospace' a lot, and I'm not sure which one I use > more frequently. What bindings do you use? >> 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". > I would slip them into simple.el, since they load very fast and rhyme with > what's already there. As mentioned, simple.el is preloaded, so anything we add to it increases the size of Emacs for everyone, whether they use it or not. > Allow me to propose the following bindings that are > undefined in Emacs 22.3.1: There's a good reason why they're undefined: most of those keys can't be pressed under a tty. Stefan From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: "Drew Adams" , 2887@debbugs.gnu.org Resent-From: "Drew Adams" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 06 Apr 2009 03:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123898696628274 (code B ref 2887); Mon, 06 Apr 2009 03:10:04 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 6 Apr 2009 03:02:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3632iic028264 for <2887@emacsbugs.donarmstrong.com>; Sun, 5 Apr 2009 20:02:45 -0700 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n36328BI030997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Apr 2009 03:02:09 GMT Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3632xlY010335; Mon, 6 Apr 2009 03:03:00 GMT Received: from dradamslap1 (/141.144.64.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Apr 2009 03:02:32 +0000 From: "Drew Adams" To: "'Stefan Monnier'" , <2887@debbugs.gnu.org>, "'Arni Magnusson'" 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> Date: Sun, 5 Apr 2009 20:02:47 -0700 Message-ID: <004d01c9b664$2a90fe60$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acm2XtCeof26i7sPR/mIOjSeXGgPuQABPaGQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.49D970CB.0022:SCFMA4539814,ss=1,fgs=0 > But it's probably a good idea to add those commands to misc.el. > Then the EmacsWiki can mention them. Huh? What kind of reasoning is that? If that's the reason, just put the code on EmacsWiki - no reason to add it to Emacs. Sheesh. From rgm@gnu.org Mon Apr 6 10:52:37 2009 Received: (at control) by emacsbugs.donarmstrong.com; 6 Apr 2009 17:52:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-5.0 required=4.0 tests=VALID_BTS_CONTROL, X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n36HqYOc019515 for ; Mon, 6 Apr 2009 10:52:35 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Lqszo-0000CC-P3; Mon, 06 Apr 2009 13:52:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18906.16736.695637.568948@fencepost.gnu.org> Date: Mon, 6 Apr 2009 13:52:32 -0400 From: Glenn Morris To: control Subject: control message X-Debbugs-No-Ack: yes severity 2853 minor reassign 2857 emacs,ns reassign 2868 emacs,ns reassign 2877 emacs,ns severity 2887 wishlist reassign 2897 spam reassign 2898 spam reassign 2899 spam reassign 2900 spam reassign 2902 spam reassign 2903 spam severity 2904 minor reassign 2904 emacs,ns reassign 2906 spam reassign 2907 spam reassign 2908 spam reassign 2909 spam From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: "Arni Magnusson" , 2887@debbugs.gnu.org Resent-From: "Arni Magnusson" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 02:55:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.12390724259228 (code B ref 2887); Tue, 07 Apr 2009 02:55:06 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 02:47:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=FVGT_m_MULTI_ODD, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n372l0CI009219 for <2887@emacsbugs.donarmstrong.com>; Mon, 6 Apr 2009 19:47:02 -0700 X-Virus-Scanned: amavisd-new at hafro.is Received: from hafrun.hafro.is (hafrun.hafro.is [130.208.58.66]) by hafgarpur.hafro.is (8.14.2/8.14.2/hafro-2.45) with ESMTP id n372kocl013305; Tue, 7 Apr 2009 02:46:52 GMT Received: from www.hafro.is (localhost [127.0.0.1]) by hafrun.hafro.is (8.14.2/8.14.2/hafro-1.6) with ESMTP id n372knXO025016; Tue, 7 Apr 2009 02:46:49 GMT Received: from 194.144.135.59 (SquirrelMail authenticated user arnima) by www.hafro.is with HTTP; Tue, 7 Apr 2009 02:46:50 -0000 (GMT) Message-ID: <16717.194.144.135.59.1239072410.squirrel@www.hafro.is> In-Reply-To: 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> Date: Tue, 7 Apr 2009 02:46:50 -0000 (GMT) From: "Arni Magnusson" To: "Stefan Monnier" Cc: 2887@debbugs.gnu.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal >> My commands that call pos-at-*-of-line work faster than I can blink >> my eyes, but I understand your concern. > > Try them on 200MB buffers. 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 10 M-x benchmark (pos-at-end-of-line 1000000) ; 0.719s 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 >> Yes, it would be a nice improvement to upgrade the >> `delete-trailing-whitespace' command so it counts cleaned lines. > > Feel free to provide a patch for it (tho, since we're in the pretest, > there's no hurry: it won't be installed right now). Here is a candidate upgrade of `delete-trailing-whitespace': (defun delete-trailing-whitespace () "Delete all the trailing whitespace across the current buffer. All whitespace after the last non-whitespace character in a line is deleted. This respects narrowing, created by \\[narrow-to-region] and friends. A formfeed is not considered whitespace by this function." (interactive "*") (save-match-data (save-excursion (goto-char (point-min)) (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 "\\s-+$" nil t) (replace-match "")(setq count (1+ count))) (message "Cleaned %d lines" count)))))) Although the code is substantially different, it performs precisely the same deletions as the existing revision 1.985, and the computational speed is comparable. The user-visible difference is that it reports how many lines were cleaned. The code is clear and extensible. One possible change is to add one important line, while still fulfilling the current documentation: (modify-syntax-entry ?\r " " table) ; always delete trailing ^M And here's a version that deletes only trailing spaces, tabs, and ^M glyphs: (defun delete-trailing-whitespace () "Delete all the trailing whitespace across the current buffer. All whitespace after the last non-whitespace character in a line is deleted. This respects narrowing, created by \\[narrow-to-region] and friends. A formfeed is not considered whitespace by this function." (interactive "*") (save-match-data (save-excursion (goto-char (point-min)) (let ((count 0)) (while (re-search-forward "[ \r\t]+$" nil t) (replace-match "")(setq count (1+ count))) (message "Cleaned %d lines" count))))) 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. 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... 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.") (defun delete-trailing-whitespace () "Delete all trailing whitespace, as defined by `trailing-whitespace-regexp', in the current buffer. All whitespace after the last non-whitespace character in a line is deleted. This respects narrowing, created by \\[narrow-to-region] and friends. Note that regardless of the value of `trailing-whitespace-regexp', `delete-trailing-whitespace' will never delete formfeed and newline characters." (interactive "*") (save-match-data (save-excursion (goto-char (point-min)) (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 version of `delete-trailing-whitespace' can mimic my `clean-trails', making that function unnecessary. >> These functions are used in a wide variety of situations (text, code, >> data), making guesswork practically hopeless. I use >> `delete-indentation' and `delete-indentation-nospace' a lot, and I'm >> not sure which one I use more frequently. > > What bindings do you use? M-j and C-M-j, overriding the defaults. >> Allow me to propose the following bindings that are undefined in >> Emacs 22.3.1: > > There's a good reason why they're undefined: most of those keys can't > be pressed under a tty. 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, Arni From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 14:05:08 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123911293712049 (code B ref 2887); Tue, 07 Apr 2009 14:05:08 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 14:02:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=FVGT_m_MULTI_ODD, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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" 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 Received: by ceviche.home (Postfix, from userid 20848) id 46409B4640; Tue, 7 Apr 2009 10:02:07 -0400 (EDT) From: Stefan Monnier To: "Arni Magnusson" Cc: 2887@debbugs.gnu.org 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> Date: Tue, 07 Apr 2009 10:02:07 -0400 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) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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 From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: "Drew Adams" , 2887@debbugs.gnu.org Resent-From: "Drew Adams" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 16:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123912059118578 (code B ref 2887); Tue, 07 Apr 2009 16:15:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 16:09:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n37G9mKo018570 for <2887@emacsbugs.donarmstrong.com>; Tue, 7 Apr 2009 09:09:49 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n37GD0FO019045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Apr 2009 16:13:01 GMT Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n37G9gKB013717; Tue, 7 Apr 2009 16:09:46 GMT Received: from dradamslap1 (/141.144.73.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Apr 2009 16:09:34 +0000 From: "Drew Adams" To: "'Stefan Monnier'" , <2887@debbugs.gnu.org>, "'Arni Magnusson'" Cc: 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> Date: Tue, 7 Apr 2009 09:09:32 -0700 Message-ID: <008701c9b79b$41f3f250$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acm3jJPQTgXrL5ilQwq6rEyV7GXRWwABX6Qw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt701.oracle.com [141.146.40.71] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020B.49DB7AC4.0109:SCFMA4539814,ss=1,fgs=0 > > 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 > > 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. So it sounds as if you're actually going to add these things to Emacs (even if you don't bind them by default)? If so, that's quite surprising, especially since the policy has always been _not_ to add functions simply because they _might_ be generally useful. Not to mention the tradition of case-by-case discussion in emacs-devel first, including discussion of rationale (e.g. use cases). Whatever. In that case, below is my version of `goto-longest-line', published under that name over two years ago. I also sent it to emacs-devel on two occasions: 2008-1-23 (thread "find longest lines during isearch") and 2008-06-21 (thread "Another neat Eclispe'ism"). http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01611.html http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg01442.html My version has these advantages: * If the region is active, it is restricted to the region. * If repeated, it goes to the longest line after the cursor. * You can use it to search from point forward only, by using `C-SPC' first. * It highlights the line (using `hl-line-highlight'). * It returns, as a list: the line #, its length, a list of other lines just as long (there can be more than one "longest line"), and the number of lines checked. * Interactively, it echoes all of that info. Example messages: Line 234: 76 chars, (459 lines measured) Line 234: 76 chars, Others: {239, 313} (459 lines measured) I bind [(control end)] to this command in `isearch-mode-map' (when `window-system'). This is the way I typically call it: `C-s C-end'. Repeatedly move to longest line after point: `C-x C-end C-end...'. And `C-g' returns you to the point where searching starts, so you can use it to see where long lines are without necessarily moving there and staying. I also bind it to `C-x L', but I typically use it from Isearch. A related command is `goto-long-line', which goes to the first line that is at least N chars long. N is the `fill-column' by default, or provided explicitly by `C-u'. If you are really interested in adding general, miscellaneous commands and functions that might be useful ("waiting for more generally useful commands"), I have plenty more, and there are hundreds more by others, on Emacs Wiki and elsewhere. The `goto-long*-line' commands and others are here: http://www.emacswiki.org/emacs/misc-cmds.el. And there is a wiki page loaded with commands for finding, visualizing, and moving to long lines: http://www.emacswiki.org/emacs/FindLongLines. I really didn't think this was how Emacs development proceeded, but apparently there has been a change (?). FWIW, I think emacs-devel is the proper place to discuss additions and other changes to Emacs. It's OK for enhancement suggestions to be submitted to the bugs list, but concrete discussion about adding or changing Emacs code should be done in emacs-devel, IMO. And such discussion should precede actually making changes. ;---------------8<----------------------- (defun goto-longest-line (beg end) "Go to the first of the longest lines in the region or buffer. If the region is active, it is checked. If not, the buffer (or its restriction) is checked. Returns a list of three elements: (LINE LINE-LENGTH OTHER-LINES LINES-CHECKED) LINE is the first of the longest lines measured. LINE-LENGTH is the length of LINE. OTHER-LINES is a list of other lines checked that are as long as LINE. LINES-CHECKED is the number of lines measured. Interactively, a message displays this information. If there is only one line in the active region, then the region is deactivated after this command, and the message mentions only LINE and LINE-LENGTH. If this command is repeated, it checks for the longest line after the cursor. That is *not* necessarily the longest line other than the current line. That longest line could be before or after the current line. To search only from the current line forward, not throughout the buffer, you can use `C-SPC' to set the mark, then use this \(repeatedly)." (interactive (if (or (not mark-active) (null (mark))) (list (point-min) (point-max)) (if (< (point) (mark)) (list (point) (mark)) (list (mark) (point))))) (when (and (not mark-active) (= beg end)) (error "The buffer is empty")) (when (and mark-active (> (point) (mark))) (exchange-point-and-mark)) (when (< end beg) (setq end (prog1 beg (setq beg end)))) (when (eq this-command last-command) (forward-line 1) (setq beg (point))) (goto-char beg) (when (eobp) (error "End of buffer")) (cond ((<= end (save-excursion (goto-char beg) (forward-line 1) (point))) (beginning-of-line) (when (require 'hl-line nil t) (let ((hl-line-mode t)) (hl-line-highlight)) (add-hook 'pre-command-hook #'hl-line-unhighlight nil t)) (let ((lineno (line-number-at-pos)) (chars (save-excursion (end-of-line) (current-column)))) (message "Only line %d: %d chars" lineno chars) (let ((visible-bell t)) (ding)) (setq mark-active nil) (list lineno chars nil 1))) (t (let* ((start-line (line-number-at-pos)) (max-width 0) (line start-line) long-lines col) (when (eobp) (error "End of buffer")) (while (and (not (eobp)) (< (point) end)) (end-of-line) (setq col (current-column)) (when (>= col max-width) (if (= col max-width) (setq long-lines (cons line long-lines)) (setq long-lines (list line))) (setq max-width col)) (forward-line 1) (setq line (1+ line))) (setq long-lines (nreverse long-lines)) (let ((lines long-lines)) (while (and lines (> start-line (car lines))) (pop lines)) (goto-char (point-min)) (when (car lines) (forward-line (1- (car lines))))) (when (require 'hl-line nil t) (let ((hl-line-mode t)) (hl-line-highlight)) (add-hook 'pre-command-hook #'hl-line-unhighlight nil t)) (when (interactive-p) (let ((others (cdr long-lines))) (message "Line %d: %d chars%s (%d lines measured)" (car long-lines) max-width (concat (and others (format ", Others: {%s}" (mapconcat (lambda (line) (format "%d" line)) (cdr long-lines) ", ")))) (- line start-line)))) (list (car long-lines) max-width (cdr long-lines) (- line start-line)))))) From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 17:25:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.12391247377402 (code B ref 2887); Tue, 07 Apr 2009 17:25:04 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 17:18:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n37HIrr4007389 for <2887@emacsbugs.donarmstrong.com>; Tue, 7 Apr 2009 10:18:55 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAGsn20lMCqib/2dsb2JhbACBUs16g30GhQ4 X-IronPort-AV: E=Sophos;i="4.39,338,1235970000"; d="scan'208";a="36721205" Received: from 76-10-168-155.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.155]) by ironport2-out.teksavvy.com with ESMTP; 07 Apr 2009 13:18:48 -0400 Received: by pastel.home (Postfix, from userid 20848) id C091480A8; Tue, 7 Apr 2009 13:18:47 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <2887@debbugs.gnu.org>, "'Arni Magnusson'" , 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> <008701c9b79b$41f3f250$0200a8c0@us.oracle.com> Date: Tue, 07 Apr 2009 13:18:47 -0400 In-Reply-To: <008701c9b79b$41f3f250$0200a8c0@us.oracle.com> (Drew Adams's message of "Tue, 7 Apr 2009 09:09:32 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > So it sounds as if you're actually going to add these things to Emacs > (even if you don't bind them by default)? No. Stefan From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Chong Yidong , 2887@debbugs.gnu.org Resent-From: Chong Yidong Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 17:25:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.12391248258666 (code B ref 2887); Tue, 07 Apr 2009 17:25:06 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 17:20:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n37HKLRK008656 for <2887@emacsbugs.donarmstrong.com>; Tue, 7 Apr 2009 10:20:22 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 7605157E21C; Tue, 7 Apr 2009 13:22:02 -0400 (EDT) From: Chong Yidong To: "Drew Adams" Cc: "'Stefan Monnier'" , <2887@debbugs.gnu.org>, "'Arni Magnusson'" , emacs-devel@gnu.org 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> <008701c9b79b$41f3f250$0200a8c0@us.oracle.com> Date: Tue, 07 Apr 2009 13:22:02 -0400 In-Reply-To: <008701c9b79b$41f3f250$0200a8c0@us.oracle.com> (Drew Adams's message of "Tue, 7 Apr 2009 09:09:32 -0700") Message-ID: <87iqlg4bwl.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Drew Adams" writes: >> 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. > > So it sounds as if you're actually going to add these things to Emacs > (even if you don't bind them by default)? > > If so, that's quite surprising, especially since the policy has always > been _not_ to add functions simply because they _might_ be generally > useful. I don't think that's what Stefan was saying (but he can speak for himself). You're right, of course, that it's not a good idea to add functions simply because they *might* be useful, especially since simple.el is loaded by default. I have not looked through bug#2887 in detail, but my impression is that most of the suggested functions aren't quite suitable for default inclusion in Emacs. They are, however, Valuable Excercises For the Novice Emacs Lisp coder. Maybe someone should set up a page on Emacswiki for this sort of thing. From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: "Drew Adams" , 2887@debbugs.gnu.org Resent-From: "Drew Adams" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 17:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123912522210274 (code B ref 2887); Tue, 07 Apr 2009 17:30:02 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 17:27:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n37HQx5P010260 for <2887@emacsbugs.donarmstrong.com>; Tue, 7 Apr 2009 10:27:00 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n37HQrIn002473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Apr 2009 17:26:54 GMT Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n37HQrpU006218; Tue, 7 Apr 2009 17:26:54 GMT Received: from dradamslap1 (/141.144.73.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Apr 2009 17:26:46 +0000 From: "Drew Adams" To: "'Chong Yidong'" Cc: "'Stefan Monnier'" , <2887@debbugs.gnu.org>, "'Arni Magnusson'" , 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><008701c9b79b$41f3f250$0200a8c0@us.oracle.com> <87iqlg4bwl.fsf@cyd.mit.edu> Date: Tue, 7 Apr 2009 10:26:40 -0700 Message-ID: <00c101c9b7a6$0b1c2da0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87iqlg4bwl.fsf@cyd.mit.edu> Thread-Index: Acm3pVrwIUN1FhQ0RHqVElTdOImlkQAAIAzg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.49DB8CD8.00C6:SCFMA4539814,ss=1,fgs=0 > most of the suggested functions aren't quite suitable for default > inclusion in Emacs. They are, however, Valuable Excercises For the > Novice Emacs Lisp coder. Maybe someone should set up a page on > Emacswiki for this sort of thing. Feel free to act on your own suggestion - anyone can edit EmacsWiki. From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Apr 2009 21:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.123914064116693 (code B ref 2887); Tue, 07 Apr 2009 21:50:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 7 Apr 2009 21:44:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n37LhrKg016680 for <2887@emacsbugs.donarmstrong.com>; Tue, 7 Apr 2009 14:43:55 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAJFl20lMCqib/2dsb2JhbACBUs0cg3sGhQ4 X-IronPort-AV: E=Sophos;i="4.39,339,1235970000"; d="scan'208";a="36738405" Received: from 76-10-168-155.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.155]) by ironport2-out.teksavvy.com with ESMTP; 07 Apr 2009 17:43:47 -0400 Received: by pastel.home (Postfix, from userid 20848) id C714282FD; Tue, 7 Apr 2009 17:43:47 -0400 (EDT) From: Stefan Monnier To: Chong Yidong Cc: "Drew Adams" , <2887@debbugs.gnu.org> 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> <008701c9b79b$41f3f250$0200a8c0@us.oracle.com> <87iqlg4bwl.fsf@cyd.mit.edu> Date: Tue, 07 Apr 2009 17:43:47 -0400 In-Reply-To: <87iqlg4bwl.fsf@cyd.mit.edu> (Chong Yidong's message of "Tue, 07 Apr 2009 13:22:02 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Actually, I do think that a "find longest line" command would be a good addition to misc.el: it's not terribly hard to write, but it's not trivial either. Stefan From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Arni Magnusson , 2887@debbugs.gnu.org Resent-From: Arni Magnusson Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 18 Apr 2009 00:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.124001334631674 (code B ref 2887); Sat, 18 Apr 2009 00:15:04 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 18 Apr 2009 00:09:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n3I09062031654 for <2887@emacsbugs.donarmstrong.com>; Fri, 17 Apr 2009 17:09:02 -0700 X-Virus-Scanned: amavisd-new at hafro.is 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 n3I08pMx021331; Sat, 18 Apr 2009 00:08:52 GMT Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2/hafro-1.6) with ESMTP id n3I08p03009744; Sat, 18 Apr 2009 00:08:51 GMT Received: from localhost (arnima@localhost) by localhost.localdomain (8.14.2/8.14.2/hafro-0.3) with ESMTP id n3I08oWM009741; Sat, 18 Apr 2009 00:08:51 GMT X-Authentication-Warning: localhost.localdomain: arnima owned process doing -bs Date: Sat, 18 Apr 2009 00:08:46 +0000 (GMT) From: Arni Magnusson X-X-Sender: arnima@localhost.localdomain To: Stefan Monnier cc: 2887@debbugs.gnu.org In-Reply-To: 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> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2129641270-1240013331=:7824" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-2129641270-1240013331=:7824 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Thanks Stefan, for forwarding my suggestions to emacs-devel. The discussion raised many good points. After considering the viewpoints we have heard so far, here are my (revised) opinions: `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. `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'? `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. `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. `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. `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. `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. `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. `goto-longest-line' I should probably withdraw this suggestion. After seeing Drew Adam's version, I have concluded that my version is too clunky to be in simple.el, and Drew's version is too large to be in simple.el. Despite being a vertical analog to `end-of-buffer', simple.el should probably not provide this functionality. `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. 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'? --- By suggesting so many functions at once, I've taken more of your time than I should. I'm very grateful for your hard work maintaining Emacs, and discussions like this are worthwhile if they lead to improved editing efficiency for users. The functions are all very short, very convenient in my opinion, and importantly they rhyme with functions that are already in simple.el. > 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". Ooo, I'm afraid misc.el might be a regrettable move in the long run. I think descriptive package names are the way to go, as the base Emacs distribution continues to grow. Perhaps simple.el could be split into something like base-buffers.el, base-mark.el, etc. As it stands, after careful examination of the base packages, I believe my suggested functions belong in simple.el. There are many commands in simple.el that are not bound to keys, including: * Variations of existing bound functions `next-error-no-select', `previous-error-no-select' `newline-and-indent', `reindent-then-newline-and-indent' `undo-only' * Modify buffer text `forward-to-indentation', `backward-to-indentation' `fixup-whitespace' * Information `what-line', `what-cursor-position' `blink-matching-open' * Others that I have bound `copy-region-as-kill' `insert-buffer' My suggested commands are mainly in one category: * Variations of existing bound functions `backward-delete-word', `delete-word' `kill-line-or-region' `pull-line-down', `pull-line-up' `zap-back-to-char', `zap-up-to-char' `delete-indentation-nospace' `downcase-word-or-region', `upcase-word-or-region' * Modify buffer text `delete-all-blank-lines' There are mainly two ways users can find out about such unbound commands: docstring cross-references, and brief entries in the Emacs/Emacs Lisp manuals. The latter manual mentions practically all commands in simple.el. Again, my apologies for the length of this message. If any of my suggestions end up being accepted, I could add some cross-references to their docstrings. Best regards, Arni --8323328-2129641270-1240013331=:7824 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=pos-at-xxx-of-line.el Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=pos-at-xxx-of-line.el KGRlZnVuIHBvcy1hdC1iZWdpbm5pbmctb2YtbGluZSAoTikgIlJldHVybiB0 aGUgcG9zaXRpb24gYXQgYmVnaW5uaW5nIG9mIGxpbmUgTi4iDQogIChzYXZl LWV4Y3Vyc2lvbiAoZ290by1jaGFyIChwb2ludC1taW4pKShsaW5lLWJlZ2lu bmluZy1wb3NpdGlvbiBOKSkpDQoNCihkZWZ1biBwb3MtYXQtZW5kLW9mLWxp bmUgKE4pICJSZXR1cm4gdGhlIHBvc2l0aW9uIGF0IGVuZCBvZiBsaW5lIE4u Ig0KICAoc2F2ZS1leGN1cnNpb24gKGdvdG8tY2hhciAocG9pbnQtbWluKSko bGluZS1lbmQtcG9zaXRpb24gTikpKQ0K --8323328-2129641270-1240013331=:7824 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=unchanged.el Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=unchanged.el KGRlZnVuIGJhY2t3YXJkLWRlbGV0ZS13b3JkIChOKSAiRGVsZXRlIHByZXZp b3VzIE4gd29yZHMuIiAoaW50ZXJhY3RpdmUgIipwIikoZGVsZXRlLXdvcmQg KC0gTikpKQ0KKGRlZnVuIGRlbGV0ZS13b3JkIChOKSAiRGVsZXRlIGZvbGxv d2luZyBOIHdvcmRzLiIgKGludGVyYWN0aXZlICIqcCIpDQogIChkZWxldGUt cmVnaW9uIChwb2ludCkoc2F2ZS1leGN1cnNpb24gKGZvcndhcmQtd29yZCBO KShwb2ludCkpKSkNCg0KKGRlZnVuIGtpbGwtbGluZS1vci1yZWdpb24gKCkg IktpbGwgcmVnaW9uIGlmIHNlbGVjdGVkLCBvdGhlcndpc2Uga2lsbCBsaW5l LiIgKGludGVyYWN0aXZlKQ0KICAoaWYgKGFuZCBtYXJrLWFjdGl2ZSB0cmFu c2llbnQtbWFyay1tb2RlKShraWxsLXJlZ2lvbiAocG9pbnQpKG1hcmspKShr aWxsLWxpbmUpKSkNCg0KKGRlZnVuIHB1bGwtbGluZS1kb3duIChOKSAiUHVs bCBsaW5lIGRvd24gTiB0aW1lcy4iIChpbnRlcmFjdGl2ZSAiKnAiKQ0KICAo bGV0ICgoY29sIChjdXJyZW50LWNvbHVtbikpKShraWxsLXdob2xlLWxpbmUg MSkoZm9yd2FyZC1saW5lIE4pKHlhbmsgMSkocG9wIGtpbGwtcmluZykoZm9y d2FyZC1saW5lIC0xKQ0KICAgICAgIChtb3ZlLXRvLWNvbHVtbiBjb2wpKSkN CihkZWZ1biBwdWxsLWxpbmUtdXAgKE4pICJQdWxsIGxpbmUgdXAgTiB0aW1l cy4iIChpbnRlcmFjdGl2ZSAiKnAiKQ0KICAobGV0ICgoY29sIChjdXJyZW50 LWNvbHVtbikpKShraWxsLXdob2xlLWxpbmUgMSkoZm9yd2FyZC1saW5lICgt IE4pKSh5YW5rIDEpKHBvcCBraWxsLXJpbmcpKGZvcndhcmQtbGluZSAtMSkN CiAgICAgICAobW92ZS10by1jb2x1bW4gY29sKSkpDQoNCihkZWZ1biB6YXAt YmFjay10by1jaGFyIChjaGFyKSAiRGVsZXRlIHJlZ2lvbiBiYWNrIHRvLCBi dXQgbm90IGluY2x1ZGluZywgQ0hBUi4iIChpbnRlcmFjdGl2ZSAiY1phcCBi YWNrIHRvIGNoYXI6ICIpDQogIChsZXQgKChjYXNlLWZvbGQtc2VhcmNoIG5p bCkpDQogICAgKGRlbGV0ZS1yZWdpb24gKHBvaW50KShwcm9nbiAoc2VhcmNo LWJhY2t3YXJkIChjaGFyLXRvLXN0cmluZyBjaGFyKSkoZm9yd2FyZC1jaGFy KShwb2ludCkpKSkpDQooZGVmdW4gemFwLXVwLXRvLWNoYXIgKGNoYXIpICJE ZWxldGUgcmVnaW9uIHVwIHRvLCBidXQgbm90IGluY2x1ZGluZywgQ0hBUi4i IChpbnRlcmFjdGl2ZSAiY1phcCB0byBjaGFyOiAiKQ0KICAobGV0ICgoY2Fz ZS1mb2xkLXNlYXJjaCBuaWwpKQ0KICAgIChkZWxldGUtcmVnaW9uIChwb2lu dCkocHJvZ24gKHNlYXJjaC1mb3J3YXJkIChjaGFyLXRvLXN0cmluZyBjaGFy KSkoYmFja3dhcmQtY2hhcikocG9pbnQpKSkpKQ0KDQooZGVmdW4gZGVsZXRl LWFsbC1ibGFuay1saW5lcyAoKSAiRGVsZXRlIGFsbCBibGFuayBsaW5lcyBp biBidWZmZXIuIiAoaW50ZXJhY3RpdmUpDQogIChzYXZlLWV4Y3Vyc2lvbg0K ICAgIChnb3RvLWNoYXIgKHBvaW50LW1pbikpDQogICAgKGxldCAoKGNvdW50 IDApKSh3aGlsZSAoc2VhcmNoLWZvcndhcmQgIlxuXG4iIG5pbCB0KShnb3Rv LWNoYXIgKHBvaW50LW1pbikpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAod2hpbGUgKHNlYXJjaC1mb3J3YXJkICJcblxuIiBuaWwgdCkocmVwbGFj ZS1tYXRjaCAiXG4iKShzZXRxIGNvdW50ICgrIGNvdW50IDEpKSkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIChnb3RvLWNoYXIgKHBvaW50LW1pbikp KQ0KICAgICAgICAgKGlmICg9IChmb2xsb3dpbmctY2hhcikgMTApKHByb2du IChkZWxldGUtY2hhciAxKShzZXRxIGNvdW50ICgrIGNvdW50IDEpKSkpDQog ICAgICAgICAobWVzc2FnZSAiRGVsZXRlZCAlZCBibGFuayBsaW5lcyIgY291 bnQpKSkpDQoNCihkZWZ1biBkZWxldGUtaW5kZW50YXRpb24tbm9zcGFjZSAo KSAiSm9pbiB0aGlzIGxpbmUgdG8gcHJldmlvdXMgd2l0aCBubyB3aGl0ZXNw YWNlIGF0IGpvaW4uIiAoaW50ZXJhY3RpdmUpDQogIChkZWxldGUtaW5kZW50 YXRpb24pKGRlbGV0ZS1ob3Jpem9udGFsLXNwYWNlKSkNCg0KKGRlZnVuIGRv d25jYXNlLXdvcmQtb3ItcmVnaW9uIChOKSAiRG93bmNhc2UgTiB3b3JkcyBv ciByZWdpb24uIiAoaW50ZXJhY3RpdmUgIipwIikNCiAgKGlmIChhbmQgbWFy ay1hY3RpdmUgdHJhbnNpZW50LW1hcmstbW9kZSkoZG93bmNhc2UtcmVnaW9u IChwb2ludCkobWFyaykpKGRvd25jYXNlLXdvcmQgTikpKQ0KKGRlZnVuIHVw Y2FzZS13b3JkLW9yLXJlZ2lvbiAoTikgIlVwY2FzZSBOIHdvcmRzIG9yIHJl Z2lvbi4iIChpbnRlcmFjdGl2ZSAiKnAiKQ0KICAoaWYgKGFuZCBtYXJrLWFj dGl2ZSB0cmFuc2llbnQtbWFyay1tb2RlKSh1cGNhc2UtcmVnaW9uIChwb2lu dCkobWFyaykpKHVwY2FzZS13b3JkIE4pKSkNCg== --8323328-2129641270-1240013331=:7824 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=delete-trailing-whitespace.el.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=delete-trailing-whitespace.el.diff MTAsMTZjMTAsMTMNCjwgICAgICAgKHdoaWxlIChyZS1zZWFyY2gtZm9yd2Fy ZCAiXFxzLSQiIG5pbCB0KQ0KPCAJKHNraXAtc3ludGF4LWJhY2t3YXJkICIt IiAoc2F2ZS1leGN1cnNpb24gKGZvcndhcmQtbGluZSAwKSAocG9pbnQpKSkN CjwgCTs7IERvbid0IGRlbGV0ZSBmb3JtZmVlZHMsIGV2ZW4gaWYgdGhleSBh cmUgY29uc2lkZXJlZCB3aGl0ZXNwYWNlLg0KPCAJKHNhdmUtbWF0Y2gtZGF0 YQ0KPCAJICAoaWYgKGxvb2tpbmctYXQgIi4qXGYiKQ0KPCAJICAgICAgKGdv dG8tY2hhciAobWF0Y2gtZW5kIDApKSkpDQo8IAkoZGVsZXRlLXJlZ2lvbiAo cG9pbnQpIChtYXRjaC1lbmQgMCkpKSkpKQ0KLS0tDQo+ICAgICAgIChsZXQg KChjb3VudCAwKSkNCj4gICAgICAgICAod2hpbGUgKHJlLXNlYXJjaC1mb3J3 YXJkICJbIFx0XHJdKyQiIG5pbCB0KQ0KPiAgICAgICAgICAgKHJlcGxhY2Ut bWF0Y2ggIiIpKHNldHEgY291bnQgKDErIGNvdW50KSkpDQo+ICAgICAgICAg KG1lc3NhZ2UgIkNsZWFuZWQgJWQgbGluZXMiIGNvdW50KSkpKSkNCg== --8323328-2129641270-1240013331=:7824 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=delete-trailing-whitespace-suggest.el Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=delete-trailing-whitespace-suggest.el KGRlZnVuIGRlbGV0ZS10cmFpbGluZy13aGl0ZXNwYWNlICgpDQogICJEZWxl dGUgYWxsIHRoZSB0cmFpbGluZyB3aGl0ZXNwYWNlIGFjcm9zcyB0aGUgY3Vy cmVudCBidWZmZXIuDQpBbGwgd2hpdGVzcGFjZSBhZnRlciB0aGUgbGFzdCBu b24td2hpdGVzcGFjZSBjaGFyYWN0ZXIgaW4gYSBsaW5lIGlzIGRlbGV0ZWQu DQpUaGlzIHJlc3BlY3RzIG5hcnJvd2luZywgY3JlYXRlZCBieSBcXFtuYXJy b3ctdG8tcmVnaW9uXSBhbmQgZnJpZW5kcy4NCkEgZm9ybWZlZWQgaXMgbm90 IGNvbnNpZGVyZWQgd2hpdGVzcGFjZSBieSB0aGlzIGZ1bmN0aW9uLiINCiAg KGludGVyYWN0aXZlICIqIikNCiAgKHNhdmUtbWF0Y2gtZGF0YQ0KICAgIChz YXZlLWV4Y3Vyc2lvbg0KICAgICAgKGdvdG8tY2hhciAocG9pbnQtbWluKSkN CiAgICAgIChsZXQgKChjb3VudCAwKSkNCiAgICAgICAgKHdoaWxlIChyZS1z ZWFyY2gtZm9yd2FyZCAiWyBcdFxyXSskIiBuaWwgdCkNCiAgICAgICAgICAo cmVwbGFjZS1tYXRjaCAiIikoc2V0cSBjb3VudCAoMSsgY291bnQpKSkNCiAg ICAgICAgKG1lc3NhZ2UgIkNsZWFuZWQgJWQgbGluZXMiIGNvdW50KSkpKSkN Cg== --8323328-2129641270-1240013331=:7824 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=delete-trailing-whitespace-cvs.el Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=delete-trailing-whitespace-cvs.el KGRlZnVuIGRlbGV0ZS10cmFpbGluZy13aGl0ZXNwYWNlICgpDQogICJEZWxl dGUgYWxsIHRoZSB0cmFpbGluZyB3aGl0ZXNwYWNlIGFjcm9zcyB0aGUgY3Vy cmVudCBidWZmZXIuDQpBbGwgd2hpdGVzcGFjZSBhZnRlciB0aGUgbGFzdCBu b24td2hpdGVzcGFjZSBjaGFyYWN0ZXIgaW4gYSBsaW5lIGlzIGRlbGV0ZWQu DQpUaGlzIHJlc3BlY3RzIG5hcnJvd2luZywgY3JlYXRlZCBieSBcXFtuYXJy b3ctdG8tcmVnaW9uXSBhbmQgZnJpZW5kcy4NCkEgZm9ybWZlZWQgaXMgbm90 IGNvbnNpZGVyZWQgd2hpdGVzcGFjZSBieSB0aGlzIGZ1bmN0aW9uLiINCiAg KGludGVyYWN0aXZlICIqIikNCiAgKHNhdmUtbWF0Y2gtZGF0YQ0KICAgIChz YXZlLWV4Y3Vyc2lvbg0KICAgICAgKGdvdG8tY2hhciAocG9pbnQtbWluKSkN CiAgICAgICh3aGlsZSAocmUtc2VhcmNoLWZvcndhcmQgIlxccy0kIiBuaWwg dCkNCgkoc2tpcC1zeW50YXgtYmFja3dhcmQgIi0iIChzYXZlLWV4Y3Vyc2lv biAoZm9yd2FyZC1saW5lIDApIChwb2ludCkpKQ0KCTs7IERvbid0IGRlbGV0 ZSBmb3JtZmVlZHMsIGV2ZW4gaWYgdGhleSBhcmUgY29uc2lkZXJlZCB3aGl0 ZXNwYWNlLg0KCShzYXZlLW1hdGNoLWRhdGENCgkgIChpZiAobG9va2luZy1h dCAiLipcZiIpDQoJICAgICAgKGdvdG8tY2hhciAobWF0Y2gtZW5kIDApKSkp DQoJKGRlbGV0ZS1yZWdpb24gKHBvaW50KSAobWF0Y2gtZW5kIDApKSkpKSkN Cg== --8323328-2129641270-1240013331=:7824-- From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 18 Apr 2009 19:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.12400831586106 (code B ref 2887); Sat, 18 Apr 2009 19:40:04 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 18 Apr 2009 19:32:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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" 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 Received: by pastel.home (Postfix, from userid 20848) id D251F7EFC; Sat, 18 Apr 2009 15:32:27 -0400 (EDT) From: Stefan Monnier To: Arni Magnusson Cc: 2887@debbugs.gnu.org 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> Date: Sat, 18 Apr 2009 15:32:27 -0400 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) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > `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 From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Arni Magnusson , 2887@debbugs.gnu.org Resent-From: Arni Magnusson Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 19 Apr 2009 01:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.12401035995015 (code B ref 2887); Sun, 19 Apr 2009 01:20:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 19 Apr 2009 01:13:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 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 Date: Sun, 19 Apr 2009 01:13:05 +0000 (GMT) From: Arni Magnusson X-X-Sender: arnima@localhost.localdomain To: Stefan Monnier cc: 2887@debbugs.gnu.org In-Reply-To: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> `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 From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Arni Magnusson , 2887@debbugs.gnu.org Resent-From: Arni Magnusson Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 19 Apr 2009 01:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.124010525313015 (code B ref 2887); Sun, 19 Apr 2009 01:50:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 19 Apr 2009 01:40:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n3J1eouf013009 for <2887@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 18:40:51 -0700 X-Virus-Scanned: amavisd-new at hafro.is 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 n3J1eiTj012386; Sun, 19 Apr 2009 01:40:44 GMT Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2/hafro-1.6) with ESMTP id n3J1eiZ5017444; Sun, 19 Apr 2009 01:40:44 GMT Received: from localhost (arnima@localhost) by localhost.localdomain (8.14.2/8.14.2/hafro-0.3) with ESMTP id n3J1eiWB017441; Sun, 19 Apr 2009 01:40:44 GMT X-Authentication-Warning: localhost.localdomain: arnima owned process doing -bs Date: Sun, 19 Apr 2009 01:40:44 +0000 (GMT) From: Arni Magnusson X-X-Sender: arnima@localhost.localdomain To: Stefan Monnier cc: 2887@debbugs.gnu.org In-Reply-To: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > [...] understood each others' ideas [...] Whoa, that should have been each other's ideas. Lisp programmers need to be extra careful with their apostrophes :) Arni From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Stefan Monnier , 2887@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 19 Apr 2009 03:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.12401108776145 (code B ref 2887); Sun, 19 Apr 2009 03:20:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 19 Apr 2009 03:14:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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" 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 Received: by ceviche.home (Postfix, from userid 20848) id A4FA7B408F; Sat, 18 Apr 2009 23:14:27 -0400 (EDT) From: Stefan Monnier To: Arni Magnusson Cc: 2887@debbugs.gnu.org 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> Date: Sat, 18 Apr 2009 23:14:27 -0400 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) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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 From unknown Mon Aug 18 11:30:36 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#2887: Suggestions for simple.el Reply-To: Arni Magnusson , 2887@debbugs.gnu.org Resent-From: Arni Magnusson Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 19 Apr 2009 13:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 2887 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 2887-submit@emacsbugs.donarmstrong.com id=B2887.124014851322182 (code B ref 2887); Sun, 19 Apr 2009 13:50:03 +0000 Received: (at 2887) by emacsbugs.donarmstrong.com; 19 Apr 2009 13:41:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n3JDfmZb022162 for <2887@emacsbugs.donarmstrong.com>; Sun, 19 Apr 2009 06:41:50 -0700 X-Virus-Scanned: amavisd-new at hafro.is 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 n3JDff3I021593; Sun, 19 Apr 2009 13:41:41 GMT Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.2/8.14.2/hafro-1.6) with ESMTP id n3JDfeE9012561; Sun, 19 Apr 2009 13:41:40 GMT Received: from localhost (arnima@localhost) by localhost.localdomain (8.14.2/8.14.2/hafro-0.3) with ESMTP id n3JDfdVu012558; Sun, 19 Apr 2009 13:41:40 GMT X-Authentication-Warning: localhost.localdomain: arnima owned process doing -bs Date: Sun, 19 Apr 2009 13:41:39 +0000 (GMT) From: Arni Magnusson X-X-Sender: arnima@localhost.localdomain To: Stefan Monnier cc: 2887@debbugs.gnu.org, bug-lisp-manual@gnu.org In-Reply-To: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed [Arni Magnusson wrote:] >> (defun pos-at-beginning-of-line (N) >> "Return the position at beginning of line N." >> (save-excursion >> (goto-char (point-min))(line-beginning-position N))) >> >> (defun pos-at-end-of-line (N) >> "Return the position at end of line N." >> (save-excursion >> (goto-char (point-min))(line-end-position N))) >> >> (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)))) [Stefan Monnier wrote:] > 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). --- Aha, now I see what you mean. One should use relative motion in Emacs Lisp programs and avoid referring to absolute line numbers (`goto-line', `line-beginning-position', `line-end-position', `line-number-at-pos'). Thank you Stefan, for explaining this to me - now I would like to help others to avoid using these functions in Emacs Lisp programs, when possible. Couldn't this be mentioned in the docstrings and in the Emacs Lisp Manual? They had already helped me by tagging a warning sign on functions like: `next-line', `previous-line' `beginning-of-buffer', `end-of-buffer' `replace-string', `replace-regexp' `insert-file', `insert-buffer' In my notes, I have also written that (goto-char (point-min)) is better than (goto-line 1), but now I can't see where this is documented. Besides the docstrings and the function entries in the manual, there is a section in the manual called "Emacs Programming Tips" where the pitfalls of *-line-* functions could be mentioned. Thanks, Arni From unknown Mon Aug 18 11:30:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#2887: Suggestions for simple.el Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 21:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 2887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Arni Magnusson" Cc: 2887@debbugs.gnu.org Received: via spool by 2887-submit@debbugs.gnu.org id=B2887.160055222632171 (code B ref 2887); Sat, 19 Sep 2020 21:51:02 +0000 Received: (at 2887) by debbugs.gnu.org; 19 Sep 2020 21:50:26 +0000 Received: from localhost ([127.0.0.1]:48289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJkkU-0008Mp-7h for submit@debbugs.gnu.org; Sat, 19 Sep 2020 17:50:26 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52540) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJkkS-0008MY-F6 for 2887@debbugs.gnu.org; Sat, 19 Sep 2020 17:50:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WuIKY1UfQsRKWfAByhBnWh+VuOyFaOp9mlLbHqZZA1I=; b=GFJ+MWPma+2anWfINZlMrF7JG1 xG1g/xXzA+DjIbKoQs3oCcHpOBtrJO6OTQU/MR79froG0ePvwQn++vHje44OQTQ31kgG0h3nZpx3K PWUij5vz7I8nYObJOJ6ROdUXamAxo77M8dRpgWhB6lnbZJo1RLj9HtKt69hVm6AWyeiM=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJkkH-0006tK-0h; Sat, 19 Sep 2020 23:50:17 +0200 From: Lars Ingebrigtsen References: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> X-Now-Playing: The Art of Noise's _In Visible Silence_: "Backbeat" Date: Sat, 19 Sep 2020 23:50:10 +0200 In-Reply-To: <26172.194.144.135.59.1238851923.squirrel@www.hafro.is> (Arni Magnusson's message of "Sat, 4 Apr 2009 13:32:03 -0000 (GMT)") Message-ID: <87bli1l9m5.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "Arni Magnusson" writes: > I would like to suggest adding a few functions to the simple.el library. I > do this with hesitation - since I know the idea is to keep it simple and > let users write extensions to suit their prefe [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Arni Magnusson" writes: > I would like to suggest adding a few functions to the simple.el library. I > do this with hesitation - since I know the idea is to keep it simple and > let users write extensions to suit their preferences - but I believe a > large number of Emacs users would appreciate having access to these > functions out of the box. There was a lot of discussion that followed after posting the patch, but it didn't seem like there was a lot of enthusiasm for adding these basic functions to Emacs eleven years ago, so it seems unlikely that there'll be more progress here now, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 19 17:50:32 2020 Received: (at control) by debbugs.gnu.org; 19 Sep 2020 21:50:32 +0000 Received: from localhost ([127.0.0.1]:48292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJkka-0008N7-Ho for submit@debbugs.gnu.org; Sat, 19 Sep 2020 17:50:32 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJkkY-0008Mi-IA for control@debbugs.gnu.org; Sat, 19 Sep 2020 17:50:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PTXX7FE/pRXpGTmhPxSg8KShjOKYLlWtMV+BklWv/Q4=; b=jOyVf9IHog295xnO2vUm9/ttx1 PnRiRPcdvg+yC2vwyeGlm95tWS975CN0wThP5n+sTI5uu7Sm76aK15DZi7aNtHyAN3gDv+LuPXDbn hb/o6HlvzhG1/KdabfdRgvF9mK3S2cqCvpCjwszA+cX0GA++Dpz4NaamNkTyR+N1uKI0=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJkkQ-0006tV-Qk for control@debbugs.gnu.org; Sat, 19 Sep 2020 23:50:24 +0200 Date: Sat, 19 Sep 2020 23:50:21 +0200 Message-Id: <87a6xll9lu.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #2887 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 2887 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 2887 quit