* bug#15821: a better M-SPC
@ 2013-11-06 9:36 Toomas Rosin
2013-11-16 21:42 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Toomas Rosin @ 2013-11-06 9:36 UTC (permalink / raw)
To: 15821
Hello,
I hope this is the right place for the following suggestion.
My version of M-SPC is an improvement over the original Emacs one in two respects: it operates both horizontally and vertically, and it takes a numeric argument. See the docstring for details.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun adjust-space-2d (&optional arg)
"Adjust horizontal or vertical whitespace.
On a non-empty blank line, leave exactly ARG spaces on it (without
ARG, make it empty).
On an empty line, delete all blank lines above and below it, leaving
ARG empty lines. When there is no ARG, the default is to leave no
empty lines at the beginning or the end of the buffer or at a single
blank line, and leave one empty line elsewhere.
At the beginning or end of a non-blank line, delete all leading
resp. trailing whitespace, leaving ARG (by default, zero) spaces.
Elsewhere, insert and/or delete blanks, leaving ARG spaces (by
default, one space)."
(interactive "*P")
(let ((num (if arg (prefix-numeric-value arg)))
(pos (point)))
(cond
;;; Empty line at the beginning of the buffer.
((and (bobp) (looking-at "$"))
(delete-blank-lines)
(if (looking-at "[ \t]*$") (kill-line))
(when num (open-line num)))
;;; Empty line elsewhere.
((save-excursion (beginning-of-line) (looking-at "$"))
(delete-blank-lines)
(when num (delete-blank-lines) (open-line num)))
;;; Beginning of line.
((save-excursion (skip-chars-backward " \t") (bolp))
(beginning-of-line)
(while (looking-at "[ \t]") (delete-char 1))
(when num (insert (make-string num ? )) (beginning-of-line)))
;;; End of line.
((save-excursion (skip-chars-forward " \t") (eolp))
(skip-chars-backward " \t")
(while (not (eolp)) (delete-char 1))
(when num (insert (make-string num ? ))))
;;; Anywhere else.
(t
(just-one-space)
(when num (delete-char -1) (insert (make-string num ? )))))))
(global-set-key (kbd "M-SPC") 'adjust-space-2d)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Best regards,
T.
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#15821: a better M-SPC 2013-11-06 9:36 bug#15821: a better M-SPC Toomas Rosin @ 2013-11-16 21:42 ` Stefan Monnier 2020-01-21 1:20 ` Stefan Kangas 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2013-11-16 21:42 UTC (permalink / raw) To: Toomas Rosin; +Cc: 15821 > I hope this is the right place for the following suggestion. It is. > My version of M-SPC is an improvement over the original Emacs one in > two respects: it operates both horizontally and vertically, and it > takes a numeric argument. See the docstring for details. I don't myself use M-SPC much and have never used its numeric argument, so I'd like to hear what other users have to say about your suggestion. Reading your docstring, I see the following changes: 1- On a non-empty blank line, leave exactly ARG spaces on it (without ARG, make it empty). 2- On an empty line, delete all blank lines above and below it, leaving ARG empty lines. 3- At the beginning or end of a non-blank line, delete all leading resp. trailing whitespace, leaving ARG (by default, zero) spaces. 4- Don't treat a negative ARG as meaning to also delete newlines. Point 4 sounds like an oversight (you don't yourself use that "negative ARG" feature, so you didn't bother to implement it), right? For points 1 to 3, the main issue I see with them is that some people apparently tend to like M-SPC so much that they hit M-SPC when they just want to insert a SPC (Richard mentioned doing that, recently), so changing M-SPC so that it sometimes finishes with no space at point can be an annoyance. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15821: a better M-SPC 2013-11-16 21:42 ` Stefan Monnier @ 2020-01-21 1:20 ` Stefan Kangas 2020-01-21 9:24 ` Andreas Schwab ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Stefan Kangas @ 2020-01-21 1:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: Toomas Rosin, 15821 Stefan Monnier <monnier@iro.umontreal.ca> writes: >> My version of M-SPC is an improvement over the original Emacs one in >> two respects: it operates both horizontally and vertically, and it >> takes a numeric argument. See the docstring for details. > > I don't myself use M-SPC much and have never used its numeric argument, > so I'd like to hear what other users have to say about your suggestion. I'm a heavy user of `just-one-space' (M-SPC), so I will venture to comment given the lack of replies over the years. I will not comment on the code, but only Stefan Monnier's summary of it, so apologies if there's something that I've misunderstood. I also want to say first thank you to Toomas for taking the time to write up a suggestion aiming to improving Emacs. As will be clear below, I'm personally not too keen on this particular change, however. Note first that the numeric argument is currently very easy to understand: leave exactly ARG spaces. Negative ARG means to leave the absolute value of ARG spaces and delete empty lines. > Reading your docstring, I see the following changes: > 1- On a non-empty blank line, leave exactly ARG spaces on it (without > ARG, make it empty). M-SPC has until now always left one space by default. I think the proposal would make for a very frustrating and confusing user experience. Changing it is also backwards incompatible. > 2- On an empty line, delete all blank lines above and below it, leaving > ARG empty lines. I don't see why we would want to change `just-one-space' to operate on lines in this way. I think it would make more sense to modify `delete-blank-lines' to leave ARG empty lines with a prefix argument. But that's a separate feature request, in my opinion. > 3- At the beginning or end of a non-blank line, delete all leading > resp. trailing whitespace, leaving ARG (by default, zero) spaces. Same comment as above regarding zero spaces. The rest is no change compared to what we have now, AFAICT. > 4- Don't treat a negative ARG as meaning to also delete newlines. > > Point 4 sounds like an oversight (you don't yourself use that "negative > ARG" feature, so you didn't bother to implement it), right? I think one of the more useful aspects of M-SPC, that I personally use all the time, and which we should most definitely keep. > For points 1 to 3, the main issue I see with them is that some people > apparently tend to like M-SPC so much that they hit M-SPC when they just > want to insert a SPC (Richard mentioned doing that, recently), so > changing M-SPC so that it sometimes finishes with no space at point can > be an annoyance. In summary, if I understand them correctly, I oppose the proposed changes, which would in my opinion be a change for the worse. They would also be backwards compatible and almost certainly break existing use patterns. (I know they would for me.) I therefore recommend to close this as wontfix. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15821: a better M-SPC 2020-01-21 1:20 ` Stefan Kangas @ 2020-01-21 9:24 ` Andreas Schwab 2020-01-22 3:13 ` Richard Stallman 2020-02-28 23:21 ` Stefan Kangas 2 siblings, 0 replies; 6+ messages in thread From: Andreas Schwab @ 2020-01-21 9:24 UTC (permalink / raw) To: Stefan Kangas; +Cc: Toomas Rosin, 15821, Stefan Monnier On Jan 21 2020, Stefan Kangas wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> Reading your docstring, I see the following changes: >> 1- On a non-empty blank line, leave exactly ARG spaces on it (without >> ARG, make it empty). > > M-SPC has until now always left one space by default. I think the > proposal would make for a very frustrating and confusing user > experience. Changing it is also backwards incompatible. Given the name of the function, leaving no space when called without prefix would be a contradiction. There is also cycle-spacing. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15821: a better M-SPC 2020-01-21 1:20 ` Stefan Kangas 2020-01-21 9:24 ` Andreas Schwab @ 2020-01-22 3:13 ` Richard Stallman 2020-02-28 23:21 ` Stefan Kangas 2 siblings, 0 replies; 6+ messages in thread From: Richard Stallman @ 2020-01-22 3:13 UTC (permalink / raw) To: Stefan Kangas; +Cc: toomas, 15821, monnier [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I often use M-SPC with no argument; please do not change it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15821: a better M-SPC 2020-01-21 1:20 ` Stefan Kangas 2020-01-21 9:24 ` Andreas Schwab 2020-01-22 3:13 ` Richard Stallman @ 2020-02-28 23:21 ` Stefan Kangas 2 siblings, 0 replies; 6+ messages in thread From: Stefan Kangas @ 2020-02-28 23:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: Toomas Rosin, 15821 tags 15821 wontfix close 15821 thanks Stefan Kangas <stefan@marxist.se> writes: > In summary, if I understand them correctly, I oppose the proposed > changes, which would in my opinion be a change for the worse. They > would also be backwards compatible and almost certainly break existing > use patterns. (I know they would for me.) > > I therefore recommend to close this as wontfix. Andreas Schwab and RMS has expressed support for my proposal to not changing anything here. There also have been no further comments within 5 weeks. I'm consequently closing this bug now. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-28 23:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-06 9:36 bug#15821: a better M-SPC Toomas Rosin 2013-11-16 21:42 ` Stefan Monnier 2020-01-21 1:20 ` Stefan Kangas 2020-01-21 9:24 ` Andreas Schwab 2020-01-22 3:13 ` Richard Stallman 2020-02-28 23:21 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).