From: Juri Linkov <juri@linkov.net>
To: Ergus <spacibba@aol.com>
Cc: Philip Kaludercic <philipk@posteo.net>, emacs-devel@gnu.org
Subject: Re: [PATCH] Re: Other details about completion.
Date: Thu, 07 Apr 2022 20:57:17 +0300 [thread overview]
Message-ID: <86y20g93pe.fsf@mail.linkov.net> (raw)
In-Reply-To: <20220407172201.qwggexthtersxi7x@Ergus> (Ergus's message of "Thu, 7 Apr 2022 19:22:01 +0200")
>> So why do you think that switching to the Completions window
>> is required to select a completion candidate?
>
> Basically because we don't need that exact behavior in all the details
> as our use case is a bit different different (and simpler). we use
> single commands most if the time. I mean, most of the completion we need
> are for single commands/candidates/files because we can't do things
> like: "M-x find-file /my/file/path" in a single line. (there are some
> exceptions line shell-commands or so... but those are the exception, not
> the rule)
>
> But also because emulating that from completions is straight forward
> considering that Completions is read-only and any edit attempt (insert a
> letter) will emit an error we can handle moving to the minibuffer and
> executing there whatever we need.
>
> zsh adds an extra space before the letter so even if it does not leave
> the command line completely there is a switch to a state where arrows
> navigate, a letter inserts a space and C-g restores to the initial... So
> there is a mode and context change.
So inserting a letter from the Completions buffer is the only thing
that you miss from zsh? But you also said above that this feature is
not important because such cases are rare: "M-x find-file /my/file/path".
In all other regards, currently it works exactly like in zsh:
'TAB TAB' selects the Completions window, and C-g cancels it.
>> But in zsh <up> and <down> wrap to the top/bottom of the same column.
>
> Yes, I already implemented that and you didn't liked because it was a
> bit long ;p... Now this is getting longer and longer....
Indeed, its logic looks complicated. But maybe we could implement
simple rules like in zsh? Then <up> ans <down> in the Completions
buffer could be bound to new commands.
>> Also in zsh TAB moves vertically when columns are sorted vertically.
>> Shouldn't TAB in Emacs move vertically too when 'completions-format'
>> is 'vertical'?
>
> Actually yes... But implementation will be long and ugly... I don't
> think it worth it...
>
> The ideal case may be to have some modes completions-vertical,
> completions-horizontal and completions-one-column that will handle all
> the pack together (bindings, order, formats)... but may break some of
> the external packages. Otherwise we will end with a code full of if-else
> and hard to maintain or extend...
Looks like the right thing to do.
next prev parent reply other threads:[~2022-04-07 17:57 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220401153839.idrzrbfl2yfzga3y.ref@Ergus>
2022-04-01 15:38 ` Other details about completion Ergus
2022-04-01 16:21 ` Eli Zaretskii
2022-04-01 16:43 ` Juri Linkov
2022-04-01 16:45 ` Ergus
2022-04-01 20:24 ` [PATCH] " Ergus
2022-04-02 18:09 ` Juri Linkov
2022-04-03 0:39 ` Ergus
2022-04-04 19:35 ` Ergus
2022-04-04 19:45 ` Juri Linkov
2022-04-04 20:31 ` Philip Kaludercic
2022-04-05 11:06 ` Ergus
2022-04-04 22:33 ` Ergus
2022-04-05 19:22 ` Juri Linkov
2022-04-05 23:20 ` Ergus
2022-04-06 7:35 ` Juri Linkov
2022-04-06 13:21 ` Ergus
2022-04-06 16:48 ` Juri Linkov
2022-04-06 17:45 ` [External] : " Drew Adams
2022-04-06 18:25 ` Juri Linkov
2022-04-06 20:01 ` Drew Adams
2022-04-06 17:45 ` Ergus
2022-04-06 18:29 ` Juri Linkov
2022-04-06 19:50 ` Ergus
2022-04-07 7:35 ` Juri Linkov
2022-04-07 9:16 ` Ergus
2022-04-07 16:53 ` Juri Linkov
2022-04-07 17:38 ` Ergus
2022-04-07 18:04 ` Juri Linkov
2022-04-07 18:35 ` Ergus
2022-04-08 7:40 ` Juri Linkov
2022-04-08 8:42 ` Ergus
2022-04-08 16:20 ` [External] : " Drew Adams
2022-04-08 16:46 ` Juri Linkov
2022-04-08 9:31 ` Philip Kaludercic
2022-04-08 16:20 ` [External] : " Drew Adams
2022-04-08 16:51 ` Juri Linkov
2022-04-08 20:12 ` Philip Kaludercic
2022-04-06 23:55 ` Ergus
2022-04-06 18:13 ` Ergus
2022-04-06 18:34 ` Juri Linkov
2022-04-06 20:34 ` Ergus
2022-04-07 7:39 ` Juri Linkov
2022-04-07 9:08 ` Ergus
2022-04-07 16:50 ` Juri Linkov
2022-04-07 17:22 ` Ergus
2022-04-07 17:57 ` Juri Linkov [this message]
2022-04-07 18:27 ` Ergus
2022-04-08 7:45 ` Juri Linkov
2022-04-08 8:46 ` Ergus
2022-04-08 16:20 ` [External] : " Drew Adams
2022-04-08 16:53 ` Juri Linkov
2022-04-06 9:07 ` Lars Ingebrigtsen
2022-04-06 16:43 ` Juri Linkov
2022-04-07 11:09 ` Lars Ingebrigtsen
2022-04-07 16:46 ` Juri Linkov
2022-04-08 12:59 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y20g93pe.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=emacs-devel@gnu.org \
--cc=philipk@posteo.net \
--cc=spacibba@aol.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).