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

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

>> Thinking about it a bit more, I agree with you two.
>
> I'll print that statement and put it in a frame in my living room. ;-)

:-)

> BTW, do we already have a function which given an element and a
> (conceptually cyclic) list returns the element after that.  E.g., such
> as this one:

Isn't that basically just (cadr (last list (mod i (length list)))) or
something like that?  (There's probably at least five off-by-ones in
that form.  😀  And...  you'd need a special test for the first element.)

> We need such a helper for the functionality.  The question is just if
> it's generally useful in which case I'd ask for a good name and place
> (accessible from simple.el).  Otherwise, I'd just keep it as an
> anonymous helper...

Sure, I think that sounds like a nice function.

Tassilo Horn <tsdh@gnu.org> writes:

> Ok, attached is a first version of the patch for discussion.  The
> supported actions are:
>
> (setq cycle-spacing-actions
>       '( just-one-space        ; you name it
>          ;; delete-space-after ; delete spaces after point
>          delete-space-before   ; delete spaces before point
>          delete-all-space      ; delete all spaces around point
>          restore))             ; restore the original spacing
>
> In addition, you can add functions (symbols) into that list which are
> simply funcall-ed.

Sounds good.  There should also be a just-one-space-including-newlines
(which is the `M-- M-SPC' action), and...  Uhm, perhaps that's all
that's missing, if we want to cover all the `M-SPC'/`M-\' actions.

Or perhaps newline-including versions of all the functions, really.

>    However, with the new version, I think it would make more sense when
>    the prefix arg given to the initial invocation is passed on to
>    following invocations of this cycle.  The reason is that only
>    just-one-space actually cares about the exact numerical value whereas
>    all actions (except 'restore) care about the prefix arg being
>    positive or negative.

delete-space-before/after could also care about the numerical prefix?

>    A negative arg always indicates that newlines
>    are treated as a deletable space whereas arg => 0 only considers tabs
>    and spaces.  So right now, if you want to delete all space including
>    newlines, you have to type M-- M-SPC M-- M-SPC M-- M-SPC which is
>    inconvenient.  If the initial arg was passed on, it would just be M--
>    M-SPC M-SPC M-SPC which is much easier to type.

After typing `M-- M-SPC' once, further incantations of that doesn't do
anything, does it?

> 2. With my configured emacs (but not with emacs -Q) it may take a
>    substantial amount of time (up to a second) until the action's effect
>    is displayed, most notably when cycling with negative prefix arg
>    where also newlines may be deleted.  Profiling revealed that this
>    comes mostly through stuff sitting in post-command-hook or
>    after-change-functions.  To name a few: aggressive-indent, show-paren
>    (which I use with the costly show-paren-context-when-offscreen
>    value 'child-frame), eldoc,...
>
>    Ok, aggressive-indent is countering manual spacing adjustments
>    fundamentally but can be tamed with:
>
>        (add-to-list 'aggressive-indent-dont-indent-if
>                     '(eq last-command 'cycle-spacing))
>
>    But is there some good way to tame the others?  It's hard to decide
>    which known performance hogs to inhibit and there might be much worse
>    unknown ones.  (Well, I also don't know how to inhibit.  I guess
>    let-binding post-command-hook in a command has no effect since it's
>    run after the command, right?)

I don't think this command should do anything about these hooks.  If the
user has put oddball stuff into the hooks, that's up to them.  (The
action is instantaneous for me.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no