Fwd: A TAB operation reform question.

Fwd: A TAB operation reform question.

[Vladimir Nikishkin]

I am sorry for "forwarding" an email, but I initially thought that
"help-gnu-emacs" would be more appropriate.

But still, I would like to ask what Emacs developers think about this
issue. Would it be possible to repurpose TAB from "sometimes TAB,
sometimes indent, sometimes complete", to a more general-purpose dwim
framework?

Vladimir Nikishkin <lockywolf@gmail.com> writes:

> Hello, Emacs users and developers
>
> I would like to ask if a reform to the way TAB (C-i) works has been
> considered? And if "yes", then how hard would it be to implement it?
>
> The motivation is the following:
>
> The way TAB works at the moment is peculiar.
>
> There is this "indent-for-tab-command", which either indents, or inserts
> a tab-character, or completes... unless "tab-always-indent" is set to
> some special value, but there are mode-specific
> modename-tab-always-indent, but they are also sometimes ignored. Also,
> org-mode overrides it with "org-cycle", and perhaps, other modes do too.
> Also, "tab" is considered to be "the place somehow close to completion
> functions", so M-C-i==M-TAB is "ispell-complete-word", and a lot of
> other packages try to make their completion somehow close to TAB.
>
> This looks a bit like a mess, partly because TAB is almost universally
> seen as a "dwim" entry point, but it is not officially so in Emacs.
>
> Could there be an alternative protocol? Could TAB be make a DWIM entry
> point "officially"?
>
> In particular, could it be possible to make a "hard-switch" variable
> "tab-always-inserts-tab", which would be the opposite of
> "tab-always-indent", but simpler, and it would be possible to override
> it in the major modes, thus making "c-tab-always-indent" unnecessary.
>
> If tab-always-inserts-tab is set to nil, TAB (for example) would be
> looking in some customizable list of functions, say
> "tab-dwim-list-functions", and run each function until some does not
> return non-nil. The default list could be something like
> (indent-if-possible indent-comment-if-possible hs-fold-if-possible
> complete-if-possible insert-tab).
> Using TAB with a prefix-argument would always insert a TAB. (which would
> be an exception to the rule "default prefix argument is 4", but I think
> it would be understandable.).
>
> This way, instead of rebinding tab to org-cycle, org-mode could prepend
> "org-cycle" to this list, or make it the only member of the list, but
> this would still allow the users to plug in custom dwim functions
> further into the list, such as ispell-word (not completion), jump
> between table cells, and such.


-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Fwd: A TAB operation reform question.

[Emanuel Berg]

Vladimir Nikishkin wrote:

> But still, I would like to ask what Emacs developers think
> about this issue. Would it be possible to repurpose TAB from
> "sometimes TAB, sometimes indent, sometimes complete", to
> a more general-purpose dwim framework?

What is it you want it to do, and when?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: A TAB operation reform question.

[Stefan Monnier]

I agree there's a problem that needs fixing.

TAB should be bound to a "DWIM" command which major modes should be able
to tweak and override any way they want, which basically means that this
command should do little more than run some kind of hook.

Maybe we should split the code of `indent-for-tab-command` into a few
separate functions, each one implementing a particular functionality
(one for indent, one for completion, one for inserting a TAB, one for
indent region, IIRC), and then recombine them into the original
functionality by compositing them with `add-function`.

The idea would be that major/minor modes would not (re)bind TAB any more
but would `add-function` to a new `tab-dwim-function` instead.

End-users would then be able to rebind TAB for their own use without
having to fight with all the major/minor modes doing their own
rebindings of TAB.  Of course, they'd also have the option of adding
their own functionality to that new `tab-dwim-function`.


        Stefan


Vladimir Nikishkin [2022-10-11 10:37:06] wrote:

> I am sorry for "forwarding" an email, but I initially thought that
> "help-gnu-emacs" would be more appropriate.
>
> But still, I would like to ask what Emacs developers think about this
> issue. Would it be possible to repurpose TAB from "sometimes TAB,
> sometimes indent, sometimes complete", to a more general-purpose dwim
> framework?
>
> Vladimir Nikishkin <lockywolf@gmail.com> writes:
>
>> Hello, Emacs users and developers
>>
>> I would like to ask if a reform to the way TAB (C-i) works has been
>> considered? And if "yes", then how hard would it be to implement it?
>>
>> The motivation is the following:
>>
>> The way TAB works at the moment is peculiar.
>>
>> There is this "indent-for-tab-command", which either indents, or inserts
>> a tab-character, or completes... unless "tab-always-indent" is set to
>> some special value, but there are mode-specific
>> modename-tab-always-indent, but they are also sometimes ignored. Also,
>> org-mode overrides it with "org-cycle", and perhaps, other modes do too.
>> Also, "tab" is considered to be "the place somehow close to completion
>> functions", so M-C-i==M-TAB is "ispell-complete-word", and a lot of
>> other packages try to make their completion somehow close to TAB.
>>
>> This looks a bit like a mess, partly because TAB is almost universally
>> seen as a "dwim" entry point, but it is not officially so in Emacs.
>>
>> Could there be an alternative protocol? Could TAB be make a DWIM entry
>> point "officially"?
>>
>> In particular, could it be possible to make a "hard-switch" variable
>> "tab-always-inserts-tab", which would be the opposite of
>> "tab-always-indent", but simpler, and it would be possible to override
>> it in the major modes, thus making "c-tab-always-indent" unnecessary.
>>
>> If tab-always-inserts-tab is set to nil, TAB (for example) would be
>> looking in some customizable list of functions, say
>> "tab-dwim-list-functions", and run each function until some does not
>> return non-nil. The default list could be something like
>> (indent-if-possible indent-comment-if-possible hs-fold-if-possible
>> complete-if-possible insert-tab).
>> Using TAB with a prefix-argument would always insert a TAB. (which would
>> be an exception to the rule "default prefix argument is 4", but I think
>> it would be understandable.).
>>
>> This way, instead of rebinding tab to org-cycle, org-mode could prepend
>> "org-cycle" to this list, or make it the only member of the list, but
>> this would still allow the users to plug in custom dwim functions
>> further into the list, such as ispell-word (not completion), jump
>> between table cells, and such.

Re: Fwd: A TAB operation reform question.

[Vladimir Nikishkin]

This is more or less what I would like to suggest, except I am not
particularly sure that advising is the way to go with this issue. I
think that a customizable "hook-list" would be a cleaner option.

Splitting `indent-for-tab-command' into separate functions would make
sense anyway, even if a "dwim" infrastructure does not end up eventually
adopted.

Regarding prior research, the Emacs Wiki seems to be listing just two
options for customizing TAB behaviour: smart-tab (available on melpa),
and "tabkey2", not available on melpa.

http://bazaar.launchpad.net/~nxhtml/nxhtml/main/view/head:/util/tabkey2.el

Looking at tabkey2, it seems that it is mostly written with the same
thoughts in mind, and it is problematic in the exactly the way mentioned
above: since it is not providing a "hook" (loosely speaking) for other
packages to connect to (due to being a standalone package), it has to
accommodate as many modes as possible by itself. (See
`tabkey2-company-backends' and `tabkey2-completion-functions')

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I agree there's a problem that needs fixing.
>
> TAB should be bound to a "DWIM" command which major modes should be able
> to tweak and override any way they want, which basically means that this
> command should do little more than run some kind of hook.
>
> Maybe we should split the code of `indent-for-tab-command` into a few
> separate functions, each one implementing a particular functionality
> (one for indent, one for completion, one for inserting a TAB, one for
> indent region, IIRC), and then recombine them into the original
> functionality by compositing them with `add-function`.
>
> The idea would be that major/minor modes would not (re)bind TAB any more
> but would `add-function` to a new `tab-dwim-function` instead.
>
> End-users would then be able to rebind TAB for their own use without
> having to fight with all the major/minor modes doing their own
> rebindings of TAB.  Of course, they'd also have the option of adding
> their own functionality to that new `tab-dwim-function`.
>
>
>         Stefan
>
>
> Vladimir Nikishkin [2022-10-11 10:37:06] wrote:
>
>> I am sorry for "forwarding" an email, but I initially thought that
>> "help-gnu-emacs" would be more appropriate.
>>
>> But still, I would like to ask what Emacs developers think about this
>> issue. Would it be possible to repurpose TAB from "sometimes TAB,
>> sometimes indent, sometimes complete", to a more general-purpose dwim
>> framework?
>>
>> Vladimir Nikishkin <lockywolf@gmail.com> writes:
>>
>>> Hello, Emacs users and developers
>>>
>>> I would like to ask if a reform to the way TAB (C-i) works has been
>>> considered? And if "yes", then how hard would it be to implement it?
>>>
>>> The motivation is the following:
>>>
>>> The way TAB works at the moment is peculiar.
>>>
>>> There is this "indent-for-tab-command", which either indents, or inserts
>>> a tab-character, or completes... unless "tab-always-indent" is set to
>>> some special value, but there are mode-specific
>>> modename-tab-always-indent, but they are also sometimes ignored. Also,
>>> org-mode overrides it with "org-cycle", and perhaps, other modes do too.
>>> Also, "tab" is considered to be "the place somehow close to completion
>>> functions", so M-C-i==M-TAB is "ispell-complete-word", and a lot of
>>> other packages try to make their completion somehow close to TAB.
>>>
>>> This looks a bit like a mess, partly because TAB is almost universally
>>> seen as a "dwim" entry point, but it is not officially so in Emacs.
>>>
>>> Could there be an alternative protocol? Could TAB be make a DWIM entry
>>> point "officially"?
>>>
>>> In particular, could it be possible to make a "hard-switch" variable
>>> "tab-always-inserts-tab", which would be the opposite of
>>> "tab-always-indent", but simpler, and it would be possible to override
>>> it in the major modes, thus making "c-tab-always-indent" unnecessary.
>>>
>>> If tab-always-inserts-tab is set to nil, TAB (for example) would be
>>> looking in some customizable list of functions, say
>>> "tab-dwim-list-functions", and run each function until some does not
>>> return non-nil. The default list could be something like
>>> (indent-if-possible indent-comment-if-possible hs-fold-if-possible
>>> complete-if-possible insert-tab).
>>> Using TAB with a prefix-argument would always insert a TAB. (which would
>>> be an exception to the rule "default prefix argument is 4", but I think
>>> it would be understandable.).
>>>
>>> This way, instead of rebinding tab to org-cycle, org-mode could prepend
>>> "org-cycle" to this list, or make it the only member of the list, but
>>> this would still allow the users to plug in custom dwim functions
>>> further into the list, such as ispell-word (not completion), jump
>>> between table cells, and such.


-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Fwd: A TAB operation reform question.

[Stefan Monnier]

Vladimir Nikishkin [2022-10-11 20:59:17] wrote:
> This is more or less what I would like to suggest, except I am not
> particularly sure that advising is the way to go with this issue.
> I think that a customizable "hook-list" would be a cleaner option.

I tried to use a standard hook with a list of function, but I found it
was not flexible enough to cover adequately the variety of interactions
between the different options (TAB is highly sought after, so the
existing interactions are sometimes fairly delicate).

A `tab-dwim-function` var is a bit more delicate to configure than
a `tab-dwim-functions` var, but I think neither of them would be usable
via Custom anyway (because it's often overridden buffer-locally by
major/minor modes).

This said, a `tab-dwim-functions` would be a great improvement over
what have, in any case.


        Stefan

Re: Fwd: A TAB operation reform question.

[Ihor Radchenko]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> A `tab-dwim-function` var is a bit more delicate to configure than
> a `tab-dwim-functions` var, but I think neither of them would be usable
> via Custom anyway (because it's often overridden buffer-locally by
> major/minor modes).
>
> This said, a `tab-dwim-functions` would be a great improvement over
> what have, in any case.

What about going further and allowing customization for dwim commands?

I imagine something like (defun-dwim ...), which can later be extended
to act differently depending on major mode or any other condition. For
example, special modes will then need not rely upon the key binding
conventions, say for next/previous line (C-n/C-p). If the user can
simply re-bind next-line-dwim/previous-line-dwim and get all the major
modes obey the new binding without a need to do major-mode-specific
customizations.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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: A TAB operation reform question.

[Thibaut Verron]

On 11/10/2022 02:01, Emanuel Berg wrote:
> Vladimir Nikishkin wrote:
>
>> In particular, could it be possible to make a "hard-switch"
>> variable "tab-always-inserts-tab", which would be the
>> opposite of "tab-always-indent", but simpler, and it would
>> be possible to override it in the major modes
> Not following 100% what you intend to happen but you can write
> a function and bind it to some keystroke (start with some
> other key than TAB perhaps) and when it works the way you want
> bind it to TAB globally or locally.
If I understand correctly, the point of the suggested change is to give 
a straightforward way for packages to implement their wanted behavior at 
the tab key, all while making it easy for users to prevent a complete 
hijack of the key.

A user-side configuration, or even a third-party package (there are 
several) don't really help with that: packages cannot be build on that 
facility, and for the user, the effort has to be repeated for each 
hijacking package.


> The challenge will be to make it transparently always fall
> back to the original bahvior when your special behavior isn't
> desired ...

That part is actually easier with your suggestion: just don't bind the 
function when the default behavior is what is wanted.

If you mean falling back to the original behavior when the special 
behavior is not possible, that is a bit more tricky but still not 
impossible.

It seems that a "run-hook-until-success" kind of function like the OP 
suggests is a straightforward solution to both cases.

Best wishes,

Thibaut

Re: A TAB operation reform question.

[Emanuel Berg]

Thibaut Verron wrote:

> If I understand correctly, the point of the suggested change
> is to give a straightforward way for packages to implement
> their wanted behavior at the tab key, all while making it easy
> for users to prevent a complete hijack of the key.

You save the original functions for the keymaps involved, then
write your own function.

Then write yet another function, a wrapper or interface, that
branches according to some condition - either execute the
original function for the current keymap, or execute the
other, new function..

Then bind the wrapper/interface function to TAB.

-- 
underground experts united
https://dataswamp.org/~incal