bug#15821: a better M-SPC

bug#15821: a better M-SPC

[Toomas Rosin]

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.

bug#15821: a better M-SPC

[Stefan Monnier]

> 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

bug#15821: a better M-SPC

[Stefan Kangas]

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

bug#15821: a better M-SPC

[Andreas Schwab]

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."

bug#15821: a better M-SPC

[Richard Stallman]

[[[ 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)

bug#15821: a better M-SPC

[Stefan Kangas]

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