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.