Bug: org-kill-line shouldn't assume visual-line-mode means kill-visual-line

Bug: org-kill-line shouldn't assume visual-line-mode means kill-visual-line

[Nathan Collins]

Hello,

In the latest version of org.el, at line 21367 [1], inside `defun
org-kill-line`, we have

     (if (bound-and-true-p visual-line-mode) 'kill-visual-line 'kill-line)))

but I think instead this should just call whatever `kill-line` is
bound to in `visual-line-mode-map`. By default, `visual-line-mode-map`
remaps `kill-line` to `kill-visual-line`, but I remove this remap
because I prefer the default `C-k` behavior. But in org-mode, I can't
figure out a way to disable this behavior of `org-kill-line`, except
by removing org-mode's remap of `kill-line` to `org-kill-line`, which
loses the other fancy logic of `org-kill-line`.

Cheers,

-nathan

[1]: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org.el#n213667

How to handle both minor mode and major mode remapping a command? (was: Bug: org-kill-line shouldn't assume visual-line-mode means kill-visual-line)

[Ihor Radchenko]

Hi,

We have the following situation in Org mode:

1. Org mode remaps `kill-line' to `org-kill-line'
2. `org-kill-line' performs special action when point is on a heading
   and otherwise falls back to `kill-line'
3. visual-line-mode, if active, sets up minor mode map remapping
   `kill-line' to `kill-visual-line'

In the past, activating `visual-line-mode' caused Org mode binding to be
completely shadowed.

Later, we tried to fix the problem by
1. Overriding `visual-line-mode' remapping by force
2. Hard-coding a special case for `visual-line-mode' to call
   `kill-visual-line' instead of `kill-line' as a fallback in
   `org-kill-line'

However, the situation is not ideal.
Below is a recent bug report where user changed the default
remapping in `visual-line-mode-map' to something else (not considered by
Org)

I am wondering if there is some canonical way to handle similar scenarios
recommended for major modes.

Any suggestions?

Nathan Collins <nathan.collins@gmail.com> writes:

> Hello,
>
> In the latest version of org.el, at line 21367 [1], inside `defun
> org-kill-line`, we have
>
>      (if (bound-and-true-p visual-line-mode) 'kill-visual-line 'kill-line)))
>
> but I think instead this should just call whatever `kill-line` is
> bound to in `visual-line-mode-map`. By default, `visual-line-mode-map`
> remaps `kill-line` to `kill-visual-line`, but I remove this remap
> because I prefer the default `C-k` behavior. But in org-mode, I can't
> figure out a way to disable this behavior of `org-kill-line`, except
> by removing org-mode's remap of `kill-line` to `org-kill-line`, which
> loses the other fancy logic of `org-kill-line`.
>
> Cheers,
>
> -nathan
>
> [1]: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org.el#n213667
>

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: How to handle both minor mode and major mode remapping a command?

[Michael Heerdegen]

Ihor Radchenko <yantar92@posteo.net> writes:

> I am wondering if there is some canonical way to handle similar scenarios
> recommended for major modes.
>
> Any suggestions?

Why not, as in similar situations, define a `kill-line-function'
variable with default value `kill-line-default-function' which is a
function (more or less our current `kill-line').

Any mode that wants to modify the behavior would `add-function' on that
variable binding.  We would have one single place where the thing is
controlled, while the behavior can still be modified by future modes.

`add-function' has priorities that can be used to specify which mode
should win in case of conflicts.


Michael.

Re: How to handle both minor mode and major mode remapping a command?

[Ihor Radchenko]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> I am wondering if there is some canonical way to handle similar scenarios
>> recommended for major modes.
>>
>> Any suggestions?
>
> Why not, as in similar situations, define a `kill-line-function'
> variable with default value `kill-line-default-function' which is a
> function (more or less our current `kill-line').
>
> Any mode that wants to modify the behavior would `add-function' on that
> variable binding.  We would have one single place where the thing is
> controlled, while the behavior can still be modified by future modes.

That will, of course, work. However, I feel that it will only solve this
exact problem, but nothing more.

Just in Org mode, we also need special handling of
`move-beginning-of-line' and `move-end-of-line' for visual mode (for the
same reasons). Does it mean that we need to introduce yet more
"*-function" variables? It will not be scalable.

What I was thinking about is some way for command remapping to:

1. remap overriding minor modes
2. be able to access commands (possible remapped) that are shadowed by
   current remapping

Maybe what I want is advice flexibility for keymaps. (not sure)

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: How to handle both minor mode and major mode remapping a command?

[Michael Heerdegen]

Ihor Radchenko <yantar92@posteo.net> writes:

> That will, of course, work. However, I feel that it will only solve this
> exact problem, but nothing more.
>
> Just in Org mode, we also need special handling of
> `move-beginning-of-line' and `move-end-of-line' for visual mode (for the
> same reasons). Does it mean that we need to introduce yet more
> "*-function" variables? It will not be scalable.

We would factor out the common part (whose semantic changes) and make
that the thing that `add-function' would modify.  A function value that
returns the positions of beginning and end of a line when called,
something like that.


> What I was thinking about is some way for command remapping to:
>
> 1. remap overriding minor modes
> 2. be able to access commands (possible remapped) that are shadowed by
>    current remapping
>
> Maybe what I want is advice flexibility for keymaps. (not sure)

What would one be able to do using that imagined mechanism that one
cannot do with `add-function'?


Michael.

Re: How to handle both minor mode and major mode remapping a command?

[Ihor Radchenko]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> What I was thinking about is some way for command remapping to:
>>
>> 1. remap overriding minor modes
>> 2. be able to access commands (possible remapped) that are shadowed by
>>    current remapping
>>
>> Maybe what I want is advice flexibility for keymaps. (not sure)
>
> What would one be able to do using that imagined mechanism that one
> cannot do with `add-function'?

My main problem with the idea of kill-line-function is that I do not
fully understand how it can work in all cases. Specifically, imagine
what happens when visual-line-mode is activated _after_ Org mode is
activated. How can Org mode make sure that kill-visual-line does not
unconditionally override Org bindings?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: How to handle both minor mode and major mode remapping a command?

[Michael Heerdegen]

Ihor Radchenko <yantar92@posteo.net> writes:

> My main problem with the idea of kill-line-function is that I do not
> fully understand how it can work in all cases. Specifically, imagine
> what happens when visual-line-mode is activated _after_ Org mode is
> activated. How can Org mode make sure that kill-visual-line does not
> unconditionally override Org bindings?

`add-function' wrappers are all combined, and that in a well defined
way.  When specifying the 'depth' property in the optional PROPS
argument (using different depths of course), the order (or invocation
times) of `add-function' calls of a place are irrelevant, the resulting
semantics is controlled by the specified depths - for example:

#+begin_src emacs-lisp
(defvar my-f (lambda (x) (* x x)))

(add-function :around my-f
  (lambda (o-f x)
    (if (< 0 x) 'important (funcall o-f x)))
  '((depth . -10) (name . outermost)))

(add-function :filter-return my-f #'1+)

(funcall my-f 2) --> important
#+end_src

A layer at the top has complete control over the behavior of the
function since it can completely discard the code of the inner layers.
It can also do that conditionally and fall back to or use the existing
implementation only in some cases.  As you see, this outermost layer is
installed first in the above example.

[ A second dimension of control: Outer layers can bind special
variables around the call of the remaining layers (like (funcall o-f x)
above) to modify the semantics of those inner layers when their
implementation refers to those variables. ]

For my taste this well defined function-only approach is better than
trying to control competing keymaps using different mechanisms (minor
vs. major modes vs. transient maps; key bindings vs. command
remappings).


Michael.