Vexing problem with read-char-exclusive (ELISP)

Vexing problem with read-char-exclusive (ELISP)

[Bob Newell]

If you run this minimal code:

(defun minimal-function ()
  (interactive)
    (while t
      (read-char-exclusive " ")
    )
)

everything works as expected, that is typed characters are simply absorbed until C-g exits the loop. But notice the " " as the prompt arg in read-char-exclusive. Why is it there?

Because if you run this:

(defun minimal-function ()
  (interactive)
    (while t
      (read-char-exclusive)
    )
)

and you pause typing input characters briefly, everything you've typed since you've invoked the function shows up in the echo area, like this:

ESC x m i n i m a l - f u n c t i o n RET a b c d e f g    (etc.)

I thought this might have something to do with minibuffer history, but I can't verify that, and I've dived into EMACS source code without luck (maybe without skill, too). I'm deep into keyboard.c and wondering...

Any ideas, leads, or help much appreciated. Running EMACS 23.3 on Linux Mint 13.

Re: Vexing problem with read-char-exclusive (ELISP)

[Stefan Monnier]

>       (read-char-exclusive)

Hmm... now that's a rarely used function.  Makes me wonder what you use
it for.

> Any ideas, leads, or help much appreciated.  Running EMACS 23.3 on
> Linux Mint 13.

It sounds like a bug we may have fixed in the many years that passed
since 23.3 was released.


        Stefan

Re: Vexing problem with read-char-exclusive (ELISP)

[Stephen Berman]

On Wed, 31 Jul 2013 23:46:54 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>       (read-char-exclusive)
>
> Hmm... now that's a rarely used function.  Makes me wonder what you use
> it for.
>
>> Any ideas, leads, or help much appreciated.  Running EMACS 23.3 on
>> Linux Mint 13.
>
> It sounds like a bug we may have fixed in the many years that passed
> since 23.3 was released.

I see it with -Q in the current trunk (that is, I see the input echoed
in the echo area, but immediately, no typing pause is needed).

Steve Berman

Re: Vexing problem with read-char-exclusive (ELISP)

[Stefan Monnier]

> I see it with -Q in the current trunk (that is, I see the input echoed
> in the echo area, but immediately, no typing pause is needed).

Hmm... indeed... and I see now also that it's almost "by design".


        Stefan

Re: Vexing problem with read-char-exclusive (ELISP)

[Bob Newell]

On Thursday, August 1, 2013 5:03:28 AM UTC-10, Stefan Monnier wrote:
> > I see it with -Q in the current trunk (that is, I see the input echoed

Hmm. Then I won't push forward to 24.x quite yet :)
  
> Hmm... indeed... and I see now also that it's almost "by design".

I can understand that actually being a design choice for some circumstances, however, I think in other circumstances there should be a way to defeat this behavior. (Of course my workaround with a " " prompt seems to do that.)

I'm using read-char-exclusive (to answer an earlier question in this thread) so I can input chars one by one and ignore mouse events. This is part of a typewriter simulator that I posted about on gnu.emacs.sources; it's a relatively useless but somewhat entertaining little piece of code.

But what I think I've heard here is that maybe I should stay with my slightly odd but functional workaround for now.

Re: Vexing problem with read-char-exclusive (ELISP)

[Stefan Monnier]

> behavior. (Of course my workaround with a " " prompt seems to do that.)

A "" prompt would be the recommended workaround.


        Stefan

Re: Vexing problem with read-char-exclusive (ELISP)

[Bob Newell]

On Thursday, August 1, 2013 4:33:20 PM UTC-10, Stefan Monnier wrote:
> > behavior. (Of course my workaround with a " " prompt seems to do that.)
> 
> A "" prompt would be the recommended workaround.

That was my initial idea too, but unfortunately it doesn't work. It gives the same behavior as no prompt at all.

Re: Vexing problem with read-char-exclusive (ELISP)

[Stefan Monnier]

>> > behavior. (Of course my workaround with a " " prompt seems to do that.)
>> A "" prompt would be the recommended workaround.
> That was my initial idea too, but unfortunately it doesn't work. It gives
> the same behavior as no prompt at all.

This one does sound like a bug.  If you care about it, please
M-x report-emacs-bug.


        Stefan