all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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/





  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.