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)