bug#19267: 25.0.50; Enhance cycle-spacing with a state where only whitespace after point is deleted

[Tassilo Horn]

Hi Lars,

> Hm, yes, that might be good.  If the list of cycled actions gets to
> long, it's no longer convenient.  So for myself, I'd probably have
>
> (just-one-space-including-newlines delete-after-space restore-original)
>
> and then `M-SPC' would do what I wanted in 99% of the time (with my
> usage patterns).  (We could also add target actions like `no-space'
> and `no-space-before-point' (i.e., the `M-\' actions).)
>
> So perhaps we could change the `M-SPC' binding to a new
> `cycle-spacing-command' that, by default, does exactly what
> `just-one-space' does now (so that there will be no user visible
> changes; i.e., it doesn't cycle because cycle-spacing-actions will be
> just (just-one-space)).  But then users can customize it and add the
> actions they want in a convenient way.

Ah, compatibility questions...

I'd say just create a cycle-spacing-actions defcustom and use that in
the existing cycle-spacing instead of the hard-coded sequence.  And bind
M-SPC to cycle-spacing by default because it's simply superior (a
super-set) of just-one-space.

I mean, how would people discover the possibility of customizing
cycle-spacing-actions if not by checking the info docs and/or NEWS
(where cycle-spacing is already mentioned as a more powerful
just-one-space alternative)?  And nobody would look in there if the
default behavior is just-one-space.  We need a disruptive change! :-)

But that's just me.

Bye,
Tassilo