unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Liu <sdl.web@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16346@debbugs.gnu.org, "João Távora" <joaotavora@gmail.com>
Subject: bug#16346: 24.3; electric-pair-mode close-paren issue
Date: Fri, 10 Jan 2014 11:24:24 +0800	[thread overview]
Message-ID: <m1ha9ciknr.fsf@gmail.com> (raw)
In-Reply-To: <jwviotthm85.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Thu, 09 Jan 2014 11:12:47 -0500")

On 2014-01-10 00:12 +0800, Stefan Monnier wrote:
> But you can get the same result with suitable use of eldoc-remove-command.

But in case of a read-only buffer, one may want the normal eldoc to show
arglist. So there is two use cases: one when editing and the other when
reading others code. I only enable eldoc-mode manually i.e. M-x
eldoc-mode when I need it.

>> In general I find the arglist (eldoc) most useful when editing text.
>
> Agreed.  But I usually need it *just before* typing.  IOW, I navigate to
> the point where I want to write, then look at the eldoc info, then start
> typing.  Sometimes the navigation is not in eldoc-message-commands, so
> I need to do something like "C-b C-f" to get eldoc to come up, but with
> eldoc-post-insert-mode it's worse, because the obvious "equivalent" of
> "SPC DEL" does not end with a self-insert so I need to do SPC, then read
> eldoc, then DEL which I find even more annoying.

But then when you go anywhere that you don't want to edit code (such as
just to copy some text) eldoc also prints the arglist. The latter
happens more often in my editing habit that it can be annoying.

But maybe eldoc-post-insert-mode (maybe even a new name
eldoc-edit-mode?) can check on char changes instead? Is this better?

>> Also getting the arglist can be expensive. For example in octave it has
>> to ask the running process (which can get stuck when the process is in
>> the middle of doing something else). In other cases it has to make
>> remote calls.
>
> Not sure why that's relevant.

For example, if a heavy job is running in the inferior octave buffer,
one normally don't want any movement to send a request to it asking for
arglist. It is my impression that eldoc might do that.

Leo





  reply	other threads:[~2014-01-10  3:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-05  2:57 bug#16346: 24.3; electric-pair-mode close-paren issue Leo Liu
2014-01-05 11:49 ` João Távora
2014-01-05 15:30   ` Leo Liu
2014-01-05 19:25     ` João Távora
2014-01-05 23:13     ` Stefan Monnier
2014-01-06  0:48       ` Leo Liu
2014-01-09 16:12         ` Stefan Monnier
2014-01-10  3:24           ` Leo Liu [this message]
2014-01-10  4:11             ` Leo Liu
2014-01-10 14:14             ` Stefan Monnier
2014-01-10 16:46               ` Leo Liu
2014-01-10 17:20                 ` Stefan Monnier
2014-01-11  4:38                   ` Leo Liu
2014-01-11  5:35                     ` Stefan Monnier
2014-01-11  6:11                       ` Leo Liu
2014-01-12  3:35                         ` Stefan Monnier
2014-01-12  4:21                           ` Leo Liu

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=m1ha9ciknr.fsf@gmail.com \
    --to=sdl.web@gmail.com \
    --cc=16346@debbugs.gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /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).