[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16346: 24.3; electric-pair-mode close-paren issue

From: Leo Liu
Subject: bug#16346: 24.3; electric-pair-mode close-paren issue
Date: Fri, 10 Jan 2014 11:24:24 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.9.1)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]