A TAB operation reform question.

A TAB operation reform question.

[Vladimir Nikishkin]

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: A TAB operation reform question.

[Christopher Dimech]

> Sent: Tuesday, October 11, 2022 at 3:03 AM
> From: "Vladimir Nikishkin" <lockywolf@gmail.com>
> To: help-gnu-emacs@gnu.org
> Subject: A TAB operation reform question.
>
> 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.

I have also experienced TAB peculiar as per your description.

> 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: A TAB operation reform question.

[Emanuel Berg]

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.

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

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