From: Dmitry Gutov <dgutov@yandex.ru>
To: Leo Liu <sdl.web@gmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 18643@debbugs.gnu.org
Subject: bug#18643: 25.0.50; elisp--expect-function-p
Date: Fri, 10 Oct 2014 07:56:40 +0400 [thread overview]
Message-ID: <543758F8.2000207@yandex.ru> (raw)
In-Reply-To: <m338awreqw.fsf@gmail.com>
On 10/10/2014 03:43 AM, Leo Liu wrote:
> Is it possible to use weight or priority i.e. the context decided
> doesn't cut completion space to a subset but instead prioritise those
> fit into the context by putting them at the front. Or find a way to
> allow other completions to show up when the input matches none of the
> subset.
It wouldn't be the worst approach, but we should be able to do better.
> Also could we not force users to insert ` before any completion in
> strings or comments.
Please don't ignore the available information about why things work as
they do currently. Have you looked at the revision that introduced that
change? Do you have anything to add to the discussion in the related bug?
> BTW, this is what happens when false negative hits:
>
> 1. If I remember the completion and it is short I type it output but
> often I double check with C-h f or C-h v to make sure it is correct.
>
> 2. When it is long or I don't remember I have to use C-h f or C-h v and
> copy it over from the *Help* buffer.
>
> The cost is high and painful.
Personally, I use `hippie-expand' as an escape hatch, in the rare cases
I have this problem. It might be painful sometimes, but I don't think
it's frequent.
Here's what happens because of false positives:
1. Write some function call, need to pass in a dynamic variable, invoke
completion. Yeah, this one looks kinda right. `eval-defun', run... Nope!
This one was just a poorly named function.
2. The reverse, for a symbol in funcall position.
3. Type a short prefix, invoke completion. Get a myriad things to sort
through.
So, with code completion working this way you also have to use C-h f and
C-h v more often than you might have had to otherwise, if only to verify
that your code makes sense.
next prev parent reply other threads:[~2014-10-10 3:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-06 5:13 bug#18643: 25.0.50; elisp--expect-function-p Leo Liu
2014-10-09 2:50 ` Dmitry Gutov
2014-10-09 3:31 ` Leo Liu
2014-10-09 6:17 ` Dmitry Gutov
2014-10-09 15:27 ` Stefan Monnier
2014-10-09 23:43 ` Leo Liu
2014-10-10 1:16 ` Stefan Monnier
2014-10-10 4:07 ` Leo Liu
2014-10-10 13:25 ` Stefan Monnier
2014-10-10 20:53 ` Dmitry Gutov
2014-10-11 0:25 ` Leo Liu
2014-10-11 13:48 ` Stefan Monnier
2014-10-11 14:21 ` Leo Liu
2014-10-14 18:32 ` Stefan Monnier
2014-10-16 2:42 ` Dmitry Gutov
2014-10-16 13:10 ` Stefan Monnier
2014-10-11 13:47 ` Stefan Monnier
2014-10-11 16:18 ` Dmitry Gutov
2014-10-14 18:34 ` Stefan Monnier
2014-10-16 2:35 ` Dmitry Gutov
2014-10-16 3:36 ` Leo Liu
2014-10-16 9:59 ` Dmitry Gutov
2014-10-11 0:16 ` Leo Liu
2014-10-10 3:56 ` Dmitry Gutov [this message]
2014-10-10 4:33 ` Leo Liu
2014-10-11 16:31 ` Dmitry Gutov
2014-10-10 3:34 ` Dmitry Gutov
2014-10-10 13:20 ` Stefan Monnier
2014-10-11 17:07 ` Dmitry Gutov
2022-04-26 13:44 ` Lars Ingebrigtsen
2022-04-26 15:46 ` Leo Liu
2022-04-27 11:52 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=543758F8.2000207@yandex.ru \
--to=dgutov@yandex.ru \
--cc=18643@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.