Breakpoint ignored.

Breakpoint ignored.

[Óscar Fuentes]

I´m trying to debug bug 3681: using a USA keyboard with alt-intl
variant, when a composed character such as á is typed with
blink-cursor-mode off, the character is not displayed until another
character is typed. (When blink-cursor-mode is on the character is
displayed after the cursor blinks).

This affects emacs when running on X.

C-h k á says `self-insert-command' is invoked, wich is a built-in
function. So I follow the link to the source code to learn that the C
function is Fself_insert_command, then invoke emacs and set a breakpoint
on it, but gdb does not stop when a character is typed (and displayed),
as if no breakpoint was active.

What I'm missing?

oscar@qcore:~/dev/other/emacs/src$ gdb --args ./emacs -q --no-site-file --no-splash
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = xterm
Breakpoint 1 at 0x4caab0: file emacs.c, line 430.
Breakpoint 2 at 0x4ea8a0: file sysdep.c, line 1129.
(gdb) break Fself_insert_command
Breakpoint 3 at 0x50b060: file cmds.c, line 331.
(gdb) r
Starting program: /home/oscar/dev/other/emacs/src/emacs -q --no-site-file --no-splash
[Thread debugging using libthread_db enabled]
[New Thread 0x7fcea7e26740 (LWP 4731)]

-- 
Óscar

Re: Breakpoint ignored.

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Sun, 18 Oct 2009 04:55:52 +0200
> 
> C-h k á says `self-insert-command' is invoked, wich is a built-in
> function. So I follow the link to the source code to learn that the C
> function is Fself_insert_command, then invoke emacs and set a breakpoint
> on it, but gdb does not stop when a character is typed (and displayed),
> as if no breakpoint was active.
> 
> What I'm missing?

You are probably missing the fact that Emacs tries to optimize the
case of insertion of a single character.  See this part of keyboard.c:

	      else if (EQ (Vthis_command, Qself_insert_command)
		       /* Try this optimization only on char keystrokes.  */
		       && NATNUMP (last_command_event)
		       && CHAR_VALID_P (XFASTINT (last_command_event), 0))
		{
		  unsigned int c
		    = translate_char (Vtranslation_table_for_input,
				      XFASTINT (last_command_event));
		  int value;
		  if (NILP (Vexecuting_kbd_macro)
		      && !EQ (minibuf_window, selected_window))
		    {
		      if (!nonundocount || nonundocount >= 20)
			{
			  Fundo_boundary ();
			  nonundocount = 0;
			}
		      nonundocount++;
		    }

		  lose = ((XFASTINT (XWINDOW (selected_window)->last_modified)
			   < MODIFF)
			  || (XFASTINT (XWINDOW (selected_window)->last_overlay_modified)
			      < OVERLAY_MODIFF)
			  || (XFASTINT (XWINDOW (selected_window)->last_point)
			      != PT)
			  || MODIFF <= SAVE_MODIFF
			  || windows_or_buffers_changed
			  || !EQ (current_buffer->selective_display, Qnil)
			  || detect_input_pending ()
			  || !NILP (XWINDOW (selected_window)->column_number_displayed)
			  || !NILP (Vexecuting_kbd_macro));

		  value = internal_self_insert (c, 0);

		  if (value == 2)
		    nonundocount = 0;

                  frame_make_pointer_invisible ();

		  if (! NILP (Vpost_command_hook))
		    /* Put this before calling adjust_point_for_property
		       so it will only get called once in any case.  */
		    goto directly_done;

		  /* VALUE == 1 when AFTER-CHANGE functions are
		     installed which is the case most of the time
		     because FONT-LOCK installs one.  */
		  if (!lose && !value)
		    direct_output_for_insert (c);
		  goto directly_done;
		}

Re: Breakpoint ignored.

[Stefan Monnier]

>> C-h k á says `self-insert-command' is invoked, wich is a built-in
>> function. So I follow the link to the source code to learn that the C
>> function is Fself_insert_command, then invoke emacs and set a breakpoint
>> on it, but gdb does not stop when a character is typed (and displayed),
>> as if no breakpoint was active.
>> 
>> What I'm missing?

> You are probably missing the fact that Emacs tries to optimize the
> case of insertion of a single character.  See this part of keyboard.c:

Note also that you can remove this whole `if' if you want.  It's only
meant to be an optimization, so before trying to fix/debug the optimized
code, try and see if the problem manifests itself in the
non-optimized code.


        Stefan

Re: Breakpoint ignored.

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> C-h k á says `self-insert-command' is invoked, wich is a built-in
>>> function. So I follow the link to the source code to learn that the C
>>> function is Fself_insert_command, then invoke emacs and set a breakpoint
>>> on it, but gdb does not stop when a character is typed (and displayed),
>>> as if no breakpoint was active.
>>> 
>>> What I'm missing?
>
>> You are probably missing the fact that Emacs tries to optimize the
>> case of insertion of a single character.  See this part of keyboard.c:
>
> Note also that you can remove this whole `if' if you want.  It's only
> meant to be an optimization, so before trying to fix/debug the optimized
> code, try and see if the problem manifests itself in the
> non-optimized code.

Thanks. Already debugged the issue as far as my knowledge of emacs/X
goes.

command_loop_1 does not notice that á was typed until another character
comes. My guess is that emacs does not receive the notification until
something else comes from X (another character or an expired timer,
which is the case when blink-cursor-mode is on).

-- 
Óscar

Re: Breakpoint ignored.

[Richard Stallman]

    You are probably missing the fact that Emacs tries to optimize the
    case of insertion of a single character.

This optimization was very important in 1985.
But computers are much faster now.
Perhaps it would be ok to delete this optimization,
or add a variable to control it and turn on the variable
only on the slower computers.

Re: Breakpoint ignored.

[Stefan Monnier]

>     You are probably missing the fact that Emacs tries to optimize the
>     case of insertion of a single character.

> This optimization was very important in 1985.
> But computers are much faster now.
> Perhaps it would be ok to delete this optimization,
> or add a variable to control it and turn on the variable
> only on the slower computers.

I've removed the optimization here, and can't tell the difference even
on my 400MHz cell phone.


        Stefan

Re: Breakpoint ignored.

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>     You are probably missing the fact that Emacs tries to optimize the
>>     case of insertion of a single character.
>
>> or add a variable to control it and turn on the variable
>> only on the slower computers.
>
> I've removed the optimization here, and can't tell the difference even
> on my 400MHz cell phone.

Tho I imagine it's hard to type very quickly on a cell phone!
(at least compared to the speed of typing with a real keyboard)

-Miles

-- 
Yossarian was moved very deeply by the absolute simplicity of
this clause of Catch-22 and let out a respectful whistle.
"That's some catch, that Catch-22," he observed.
"It's the best there is," Doc Daneeka agreed.

Re: Breakpoint ignored.

[Stefan Monnier]

>>> You are probably missing the fact that Emacs tries to optimize the
>>> case of insertion of a single character.
>> 
>>> or add a variable to control it and turn on the variable
>>> only on the slower computers.
>> 
>> I've removed the optimization here, and can't tell the difference even
>> on my 400MHz cell phone.

> Tho I imagine it's hard to type very quickly on a cell phone!
> (at least compared to the speed of typing with a real keyboard)

No doubt, typing on a resistive touchscreen is not fast, but for those
tests, I remote-displayed on my desktop, so it was a normal keyboard
with a "normal" repeat rate (40Hz in my case).


        Stefan

Re: Breakpoint ignored.

[Richard Stallman]

    > I've removed the optimization here, and can't tell the difference even
    > on my 400MHz cell phone.

    Tho I imagine it's hard to type very quickly on a cell phone!
    (at least compared to the speed of typing with a real keyboard)

If Emacs has no trouble handling typing at real typing speed
then it is working fast enough.

Re: Breakpoint ignored.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > I've removed the optimization here, and can't tell the difference even
>     > on my 400MHz cell phone.
>
>     Tho I imagine it's hard to type very quickly on a cell phone!
>     (at least compared to the speed of typing with a real keyboard)
>
> If Emacs has no trouble handling typing at real typing speed
> then it is working fast enough.

I beg to differ.  A few hours ago I put a score book up on my laptop
(because my music stand is missing in action).  Half an hour later, I
found that it had pressed a key with auto repeat, with the cursor in
Firefox' location bar.  Now 15 characters per second for half an hour
without a newline is not "real typing speed".  Nevertheless, it was
completely annoying that Firefox was thrashing so hopelessly that after
a few minutes of trying to erase that long line in the location bar (C-a
DEL should have done the trick) I had to kill and restart Firefox.

I think that any tool with text entry should stand up to this sort of
abuse.

-- 
David Kastrup

Re: Breakpoint ignored.

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

[snip]

>> If Emacs has no trouble handling typing at real typing speed
>> then it is working fast enough.
>
> I beg to differ.  A few hours ago I put a score book up on my laptop
> (because my music stand is missing in action).  Half an hour later, I
> found that it had pressed a key with auto repeat, with the cursor in
> Firefox' location bar.  Now 15 characters per second for half an hour
> without a newline is not "real typing speed".  Nevertheless, it was
> completely annoying that Firefox was thrashing so hopelessly that after
> a few minutes of trying to erase that long line in the location bar (C-a
> DEL should have done the trick) I had to kill and restart Firefox.
>
> I think that any tool with text entry should stand up to this sort of
> abuse.

I think it is not related to the specific case being discused, but your
scenario looks quite extreme to me. Such abuse does not warrant
increasing complexity with optimizations or safeguards for
them. Guaranteeing that emacs (or firefox) behaves snappy after pressing
a key for half an hour (why not a month?) enters the paranoid field of
life-critical applications.

Looking at the documentation and being misguided by it with the
subsequent confusion and time waste is worse, IMO.

-- 
Óscar

Re: Breakpoint ignored.

[Stefan Monnier]

> I think it is not related to the specific case being discused, but your
> scenario looks quite extreme to me. Such abuse does not warrant
> increasing complexity with optimizations or safeguards for
> them. Guaranteeing that emacs (or firefox) behaves snappy after pressing
> a key for half an hour (why not a month?) enters the paranoid field of
> life-critical applications.

Agreed.  This said I think Emacs deals fairly poorly with such
situations and it is a problem in some real cases where people have to
handle files with really long lines.
We have an open bug-report about it.


        Stefan

Re: Breakpoint ignored.

[Richard Stallman]

You are right -- Emacs should keep up with auto-repeat too.

Re: Breakpoint ignored.

[Daniel Colascione]

On Oct 18, 2009, at 10:39 PM, Richard Stallman wrote:

>    You are probably missing the fact that Emacs tries to optimize the
>    case of insertion of a single character.
>
> This optimization was very important in 1985.
> But computers are much faster now.
> Perhaps it would be ok to delete this optimization,
> or add a variable to control it and turn on the variable
> only on the slower computers.

Given modern branch prediction and instruction caches, I wouldn't be  
surprised if removing the special cases in keyboard.c for self-insert- 
command, forward-char, backward-char were itself an optimization.

It'd also have the nice effect of making these commands behave  
normally for advice, redefinition, debugging, and so on.

Re: Breakpoint ignored.

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     You are probably missing the fact that Emacs tries to optimize the
>     case of insertion of a single character.
>
> This optimization was very important in 1985.
> But computers are much faster now.

It's more than about speed.  It also about making useful undo
boundaries, and this feature should not be killed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Breakpoint ignored.

[Stefan Monnier]

>> You are probably missing the fact that Emacs tries to optimize the
>> case of insertion of a single character.
>> 
>> This optimization was very important in 1985.
>> But computers are much faster now.

> It's more than about speed.  It also about making useful undo
> boundaries, and this feature should not be killed.

I added this feature to Fself_insert_command, so there shouldn't be any
such difference in this respect any more.


        Stefan


PS: The mere presence of such a difference counts as a bug to me.