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

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> Would it be ok for you to define it in your init file?  I've documented
>> the positive arg = tabs/spaces, negative arg = tabs/spaces/newlines as a
>> general contract of all predefined actions (see new patch below) and
>> your favorite action would immediately violate it...
>
> I think the newline-including variations would be as popular as the
> non-newline ones, so I think we should have those variations for all
> of the actions.

You're quite strong willed, aren't you? ;-)

> Perhaps `M--' could work as a toggle -- if the action doesn't include
> newlines, `M--' switches on, and if it does, `M--' switches it off.

That's indeed an idea.  How about cycle-spacing-actions could also have
actions of the form

    (just-one-space inverted-arg)
    (just-one-space 4)

where the former would, you guess it, use the inverted value of this
cycle's prefix arg and the latter would ignore the cycle's prefix arg
and just use 4?  That would fit your desire, right?

>> No, at least not yet. But if they did, you would need to always give
>> an explicit prefix arg when you really want to delete all spaces
>> before/after point because the default value of a numerical prefix
>> arg is 1.
>
> But it doesn't have to be, surely?  No prefix for
> delete-space-after-point could mean exactly that, but a prefix of four
> could mean leave four.

I don't like that no prefix arg (aka 1) would be treated differently
than any other value.  And what if you actually want to delete all but
one space?

Or do you suggest that cycle-spacing should be changed from taking a
numeric prefix arg to a raw prefix arg and then do the conversion to
numeric itself (with prefix-numeric-value)?  That would make it possible
to distinguish no prefix arg from 1.  I think that would be benefitical
otherwise, e.g., to force a new cycle.

In any case, how would you define the semantics for the delete-* actions
with numeric values for N?  I mean, for delete-space-after/before I can
imagine that the N whitespace characters after/before should survive (in
case there are at least so many).  But in case of delete-all-space,
there's no precise meaning of the correct spaces around point which
could be a wild mix of spaces, tabs, and newlines.

I'd rather suggest to leave the delete-* actions as-is and add another
just-one-newline (and probably also just-one-newline-and-indent) action
which is like just-one-space with newline instead of space (plus one
indent-according-to-mode).

Bye,
Tassilo