From: Juri Linkov <juri@jurta.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 6076@debbugs.gnu.org, Leo <sdl.web@gmail.com>
Subject: bug#6076: 23.1.96; [PATCH] rcirc-complete for nicks and commands
Date: Mon, 10 May 2010 22:14:28 +0300 [thread overview]
Message-ID: <87ljbu36ed.fsf@mail.jurta.org> (raw)
In-Reply-To: <jwviq73qsl9.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Tue, 04 May 2010 17:18:55 -0400")
>> Isearch-like mode would be a good thing. Typing a key not bound
>> in its mode map will leave this mode and hide the *Completions* buffer.
>
> Right. But choosing which keys/events make it leave because we want it
> to be very lightweight (i.e. we want to leave as soon as possible), but
> we'd rather not leave when the user is still editing the completion.
>
> So self-insert-command should not leave, but then SPC (and several
> others likewise) probably should (even tho it's also
> self-insert-command) and maybe DEL shouldn't either, but what about
> C-f/C-b? I was thinking maybe we should decide it based on the position
> of point (whether it's still inside the completion text or not).
This is something that in other programs is called "in-place editing".
Usually a field for editing is highlighted with a different background.
In terms of Emacs this could be called "in-place completion". For its
implementation the most suitable feature is the `field' property.
When completion is activated, a field could be created in the buffer
and removed when completion is finished. I suggest using the same
key to finish completion as in the minibuffer, i.e. RET.
--
Juri Linkov
http://www.jurta.org/emacs/
next prev parent reply other threads:[~2010-05-10 19:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-02 8:49 bug#6076: 23.1.96; [PATCH] rcirc-complete for nicks and commands Leo
2010-05-02 9:01 ` Leo
2010-05-04 13:41 ` Leo
2010-05-03 16:37 ` Stefan Monnier
2010-05-03 17:45 ` Leo
2010-05-04 2:32 ` Stefan Monnier
2010-05-04 16:18 ` Juri Linkov
2010-05-04 18:29 ` Stefan Monnier
2010-05-04 20:01 ` Juri Linkov
2010-05-04 21:18 ` Stefan Monnier
2010-05-10 19:14 ` Juri Linkov [this message]
2010-05-11 1:14 ` Stefan Monnier
2010-05-11 16:54 ` Juri Linkov
2010-05-11 19:52 ` Stefan Monnier
2010-08-23 10:36 ` Leo
2010-09-03 22:13 ` Ryan Yeske
2010-09-04 8:24 ` Stefan Monnier
2010-09-04 10:21 ` Leo
2010-09-04 21:44 ` Stefan Monnier
2010-09-06 17:52 ` Leo
2010-09-11 12:55 ` Stefan Monnier
2010-09-11 13:03 ` Leo
2010-09-12 11:11 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ljbu36ed.fsf@mail.jurta.org \
--to=juri@jurta.org \
--cc=6076@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=sdl.web@gmail.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.