Trunk emacs infelicity with linum mode

Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

Hi,

        To reproduce, on a graphical display:
 emacs -Q
 M-x load-library<RET>
 linum<RET>
 M-x linum-mode
 C-x 5 2

       This results in an error, the contents of the *Messages* buffer
 is: 
--8<---------------cut here---------------start------------->8---
Loading linum...done
Global-Linum mode enabled
linum--face-height: Invalid face: linum [3 times]
Mark set
--8<---------------cut here---------------end--------------->8---

        Is anyone else seeing this?

        manoj
-- 
[The French Riviera is] a sunny place for shady people. Somerset Maugham
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Manoj Srivastava <srivasta@ieee.org>
> Date: Tue, 02 Sep 2014 10:22:35 -0700
> 
>         To reproduce, on a graphical display:
>  emacs -Q
>  M-x load-library<RET>
>  linum<RET>
>  M-x linum-mode
>  C-x 5 2
> 
>        This results in an error, the contents of the *Messages* buffer
>  is: 
> --8<---------------cut here---------------start------------->8---
> Loading linum...done
> Global-Linum mode enabled
> linum--face-height: Invalid face: linum [3 times]
> Mark set
> --8<---------------cut here---------------end--------------->8---
> 
>         Is anyone else seeing this?

I don't.

Suggest that you set debug-on-error non-nil and show the backtrace.

Also, are you sure you aren't using some version of linum that did not
come with Emacs?

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

On Tue, Sep 02 2014, Eli Zaretskii wrote:

>> From: Manoj Srivastava <srivasta@ieee.org>
>> Date: Tue, 02 Sep 2014 10:22:35 -0700
>> 
>>         To reproduce, on a graphical display:
>>  emacs -Q
>>  M-x load-library<RET>
>>  linum<RET>
>>  M-x linum-mode
>>  C-x 5 2

>>        This results in an error, the contents of the *Messages* buffer
>>  is: 
>> --8<---------------cut here---------------start------------->8---
>> Loading linum...done
>> Global-Linum mode enabled
>> linum--face-height: Invalid face: linum [3 times]
>> Mark set
>> --8<---------------cut here---------------end--------------->8---
>> 
>>         Is anyone else seeing this?

> I don't.

> Suggest that you set debug-on-error non-nil and show the backtrace.

> Also, are you sure you aren't using some version of linum that did not
> come with Emacs?


        M-x locate-library linum says:
 Library is file /usr/local/share/emacs/24.4.50/lisp/linum.elc
 Which is the one that comes with emacs. I removed that directory,
 recompiled and re-installed the latest emacs. There is no change in
 behaviour. This is Debian Sid,  also updated very recently.

        I do not get any return from debug-on-error or debug-on-quit set
 to t, All I get is a beep, and the error message in the nodeline and
 the *Messages* buffer.

        I am also seeing the same behaviour on my laptop, also running
 Debian unstable. This might be related to the undated gcc tool chain
 that has hit Debian, or this could be mere coincidence. I'll continue
 looking (the strace output is pretty noisy,)

        manoj
-- 
You have a message from the operator.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Manoj Srivastava <srivasta@ieee.org>
> Date: Tue, 02 Sep 2014 11:56:28 -0700
> 
>         M-x locate-library linum says:
>  Library is file /usr/local/share/emacs/24.4.50/lisp/linum.elc
>  Which is the one that comes with emacs. I removed that directory,
>  recompiled and re-installed the latest emacs. There is no change in
>  behaviour. This is Debian Sid,  also updated very recently.
> 
>         I do not get any return from debug-on-error or debug-on-quit set
>  to t, All I get is a beep, and the error message in the nodeline and
>  the *Messages* buffer.

Try loading linum.el, not linum.elc.

Also, after you load it, do you see the 'linum' face in the buffer
popped up by "M-x list-faces-display"?

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

On Tue, Sep 02 2014, Eli Zaretskii wrote:

>> From: Manoj Srivastava <srivasta@ieee.org>
>> Date: Tue, 02 Sep 2014 11:56:28 -0700
>> 
>>         M-x locate-library linum says:
>>  Library is file /usr/local/share/emacs/24.4.50/lisp/linum.elc
>>  Which is the one that comes with emacs. I removed that directory,
>>  recompiled and re-installed the latest emacs. There is no change in
>>  behaviour. This is Debian Sid,  also updated very recently.
>> 
>>         I do not get any return from debug-on-error or debug-on-quit set
>>  to t, All I get is a beep, and the error message in the nodeline and
>>  the *Messages* buffer.

> Try loading linum.el, not linum.elc.

        No difference. I still get no backtrace with debug-on-error set
 to t, but the error message is still there.

> Also, after you load it, do you see the 'linum' face in the buffer
> popped up by "M-x list-faces-display"?

        Yes, the face  does exist. I can also see the same face in the
 line numbers on the left. In previous sessions, I had tried
 customizing the face, to no avail (I have since removed the
 customization).

        manoj
-- 
Oh, by the way, which one's Pink? Pink Floyd
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Manoj Srivastava <srivasta@ieee.org>
> Date: Wed, 03 Sep 2014 00:06:11 -0700
> 
> > Also, after you load it, do you see the 'linum' face in the buffer
> > popped up by "M-x list-faces-display"?
> 
>         Yes, the face  does exist. I can also see the same face in the
>  line numbers on the left. In previous sessions, I had tried
>  customizing the face, to no avail (I have since removed the
>  customization).

I don't understand how is this possible.  I can only suggest to run
Emacs under GDB, put a breakpoint on the line in  xfaces.c marked below:

  static Lisp_Object
  lface_from_face_name_no_resolve (struct frame *f, Lisp_Object face_name,
				   int signal_p)
  {
    Lisp_Object lface;

    if (f)
      lface = assq_no_quit (face_name, f->face_alist);
    else
      lface = assq_no_quit (face_name, Vface_new_frame_defaults);

    if (CONSP (lface))
      lface = XCDR (lface);
    else if (signal_p)
      signal_error ("Invalid face", face_name);  <<<<<<<<<<<<<<<<<<<<<<

    check_lface (lface);

    return lface;
  }

and then post the backtrace when the breakpoint breaks.

(Please make sure GDB reads the .gdbinit file when you start it, so
that the backtrace includes the Lisp level.)

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

On Wed, Sep 03 2014, Eli Zaretskii wrote:

F>> From: Manoj Srivastava <srivasta@ieee.org>
>> Date: Wed, 03 Sep 2014 00:06:11 -0700

>> > Also, after you load it, do you see the 'linum' face in the buffer
>> > popped up by "M-x list-faces-display"?

>>         Yes, the face  does exist. I can also see the same face in the
>>  line numbers on the left. In previous sessions, I had tried
>>  customizing the face, to no avail (I have since removed the
>>  customization).

> I don't understand how is this possible.  I can only suggest to run
> Emacs under GDB, put a breakpoint on the line in  xfaces.c marked below:
> and then post the backtrace when the breakpoint breaks.

> (Please make sure GDB reads the .gdbinit file when you start it, so
> that the backtrace includes the Lisp level.)

--8<---------------cut here---------------start------------->8---
(gdb) list lface_from_face_name_no_resolve
1951       signal an error if FACE_NAME is not a valid face name.  If SIGNAL_P
1952       is zero, value is nil if FACE_NAME is not a valid face name.  */
1953    static Lisp_Object
1954    lface_from_face_name_no_resolve (struct frame *f, Lisp_Object face_name,
1955                                     int signal_p)
1956    {
1957      Lisp_Object lface;
1958
1959      if (f)
1960        lface = assq_no_quit (face_name, f->face_alist);
(gdb) list
1961      else
1962        lface = assq_no_quit (face_name, Vface_new_frame_defaults);
1963
1964      if (CONSP (lface))
1965        lface = XCDR (lface);
1966      else if (signal_p)
1967        signal_error ("Invalid face", face_name);
1968
1969      check_lface (lface);
1970
(gdb) break 1967
Breakpoint 3 at 0x4b0429: file xfaces.c, line 1967.
(gdb) run -Q
Starting program: /usr/local/src/emacs/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe794b700 (LWP 2199)]
[New Thread 0x7fffe6d32700 (LWP 2200)]
[New Thread 0x7fffe6531700 (LWP 2201)]

Breakpoint 3, lface_from_face_name_no_resolve (f=f@entry=0x120f6d0, face_name=face_name@entry=17204162, signal_p=signal_p@entry=1)
    at xfaces.c:1967
1967        signal_error ("Invalid face", face_name);
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
#0  lface_from_face_name_no_resolve (f=f@entry=0x120f6d0, face_name=face_name@entry=17204162, signal_p=signal_p@entry=1)
    at xfaces.c:1967
#1  0x00000000004b047b in get_lface_attributes_no_remap (f=f@entry=0x120f6d0, face_name=face_name@entry=17204162, 
    attrs=attrs@entry=0x7fffffffc2c0, signal_p=signal_p@entry=1) at xfaces.c:2003
#2  0x00000000004b160f in get_lface_attributes (f=f@entry=0x120f6d0, face_name=17204162, attrs=attrs@entry=0x7fffffffc2c0, signal_p=1, 
    named_merge_points=named_merge_points@entry=0x0) at xfaces.c:2050
#3  0x00000000004b7569 in lookup_named_face (f=f@entry=0x120f6d0, symbol=symbol@entry=17204162, signal_p=signal_p@entry=1)
    at xfaces.c:4503
#4  0x00000000004b760e in Fface_font (face=17204162, frame=<optimized out>, character=12672242) at xfaces.c:3844
#5  0x0000000000554fd2 in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffc438) at eval.c:2815
#6  0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=16288805, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffc438) at bytecode.c:920
#7  0x0000000000554b47 in funcall_lambda (fun=22295153, nargs=nargs@entry=1, arg_vector=0x7fffffffc438, 
    arg_vector@entry=0x7fffffffc5a8) at eval.c:2976
#8  0x0000000000554e0b in Ffuncall (nargs=2, args=args@entry=0x7fffffffc5a0) at eval.c:2869
#9  0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=19151957, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffc5a0) at bytecode.c:920
#10 0x0000000000554b47 in funcall_lambda (fun=22294961, nargs=nargs@entry=1, arg_vector=0x7fffffffc5a0, 
    arg_vector@entry=0x7fffffffc6e8) at eval.c:2976
#11 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffc6e0) at eval.c:2869
#12 0x00000000005551ca in call1 (fn=fn@entry=22953634, arg1=<optimized out>) at eval.c:2607
#13 0x000000000055c7f2 in mapcar1 (leni=1, vals=vals@entry=0x0, fn=fn@entry=22953634, seq=seq@entry=17119974) at fns.c:2591
#14 0x000000000055ca32 in Fmapc (function=22953634, sequence=17119974) at fns.c:2680
#15 0x0000000000554fe2 in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffc7d0) at eval.c:2811
#16 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=16288725, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffc7d0) at bytecode.c:920
#17 0x0000000000554b47 in funcall_lambda (fun=22295569, nargs=nargs@entry=1, arg_vector=0x7fffffffc7d0, 
    arg_vector@entry=0x7fffffffc910) at eval.c:2976
#18 0x0000000000554e0b in Ffuncall (nargs=2, args=args@entry=0x7fffffffc908) at eval.c:2869
#19 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=16289461, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x7fffffffc908) at bytecode.c:920
#20 0x0000000000554b47 in funcall_lambda (fun=22296849, nargs=nargs@entry=0, arg_vector=0x7fffffffc908, 
    arg_vector@entry=0x7fffffffca30) at eval.c:2976
#21 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffffca28) at eval.c:2869
#22 0x00000000005551e8 in call0 (fn=22958818) at eval.c:2592
#23 0x000000000046bda6 in run_funs (funs=17204162) at window.c:3315
#24 0x000000000047188d in run_window_configuration_change_hook (f=f@entry=0x120f6d0) at window.c:3369
#25 0x0000000000420db1 in adjust_frame_size (f=0x120f6d0, new_width=<optimized out>, new_height=<optimized out>, 
    inhibit=<optimized out>, pretend=<optimized out>) at frame.c:582
#26 0x000000000041e4ce in change_frame_size (pixelwise=<optimized out>, safe=<optimized out>, delay=<optimized out>, 
    pretend=<optimized out>, new_height=<optimized out>, new_width=<optimized out>, f=<optimized out>) at dispnew.c:5560
#27 do_pending_window_change (safe=false) at dispnew.c:5487
#28 0x0000000000420e27 in adjust_frame_size (f=0x120f6d0, new_width=<optimized out>, new_height=<optimized out>, inhibit=0, 
    pretend=<optimized out>) at frame.c:484
#29 0x00000000004cfd62 in Fx_create_frame (parms=17204162) at xfns.c:3244
#30 0x0000000000554fee in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffccf8) at eval.c:2808
#31 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=9233173, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0) at bytecode.c:920
#32 0x0000000000554aaf in funcall_lambda (fun=9233077, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffcea0) at eval.c:3042
#33 0x0000000000554e0b in Ffuncall (nargs=2, args=args@entry=0x7fffffffce98) at eval.c:2869
#34 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=9882037, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0) at bytecode.c:920
#35 0x0000000000554aaf in funcall_lambda (fun=9881949, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffd040) at eval.c:3042
#36 0x0000000000554e0b in Ffuncall (nargs=1, args=args@entry=0x7fffffffd038) at eval.c:2869
#37 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=9881709, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0) at bytecode.c:920
#38 0x0000000000554aaf in funcall_lambda (fun=9881621, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffd350) at eval.c:3042
#39 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffffd348) at eval.c:2869
#40 0x000000000055078a in Ffuncall_interactively (nargs=1, args=0x7fffffffd348) at callint.c:270
#41 0x0000000000554ee1 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd340) at eval.c:2789
#42 0x0000000000555c4c in Fapply (nargs=nargs@entry=3, args=args@entry=0x7fffffffd340) at eval.c:2290
#43 0x0000000000550d5c in Fcall_interactively (function=20495666, record_flag=12672242, keys=12707029) at callint.c:419
#44 0x0000000000554fd2 in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffd428) at eval.c:2815
#45 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=9622181, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffd428) at bytecode.c:920
#46 0x0000000000554b47 in funcall_lambda (fun=9622145, nargs=nargs@entry=1, arg_vector=0x7fffffffd428, arg_vector@entry=0x7fffffffd568)
    at eval.c:2976
#47 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd560) at eval.c:2869
#48 0x00000000005551ca in call1 (fn=<optimized out>, arg1=<optimized out>) at eval.c:2607
#49 0x00000000004eff4d in command_loop_1 () at keyboard.c:1569
#50 0x0000000000553367 in internal_condition_case (bfun=bfun@entry=0x4efbc0 <command_loop_1>, handlers=<optimized out>, 
    hfun=hfun@entry=0x4e6e00 <cmd_error>) at eval.c:1347
#51 0x00000000004e256e in command_loop_2 (ignore=ignore@entry=12672242) at keyboard.c:1193
#52 0x000000000055324b in internal_catch (tag=12720194, func=func@entry=0x4e2550 <command_loop_2>, arg=12672242) at eval.c:1111
#53 0x00000000004e252b in command_loop () at keyboard.c:1172
#54 0x00000000004e69ef in recursive_edit_1 () at keyboard.c:782
#55 0x00000000004e6d30 in Frecursive_edit () at keyboard.c:853
#56 0x0000000000414791 in main (argc=0, argv=0x7fffffffd908) at emacs.c:1642

Lisp Backtrace:
"face-font" (0xffffc440)
"linum--face-height" (0xffffc5a8)
"linum-update-window" (0xffffc6e8)
"mapc" (0xffffc7d8)
"linum-update" (0xffffc910)
"linum-update-current" (0xffffca30)
"x-create-frame" (0xffffcd00)
"x-create-frame-with-faces" (0xffffcea0)
"make-frame" (0xffffd040)
"make-frame-command" (0xffffd350)
"funcall-interactively" (0xffffd348)
"call-interactively" (0xffffd430)
"command-execute" (0xffffd568)
--8<---------------cut here---------------end--------------->8---

        Thanks for looking into this

        manoj
-- 
You have a tendency to feel you are superior to most computers.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Manoj Srivastava <srivasta@ieee.org>
> Date: Wed, 03 Sep 2014 09:28:20 -0700
> 
> Breakpoint 3, lface_from_face_name_no_resolve (f=f@entry=0x120f6d0, face_name=face_name@entry=17204162, signal_p=signal_p@entry=1)
>     at xfaces.c:1967
> 1967        signal_error ("Invalid face", face_name);
> --8<---------------cut here---------------end--------------->8---
> 
> --8<---------------cut here---------------start------------->8---
> #0  lface_from_face_name_no_resolve (f=f@entry=0x120f6d0, face_name=face_name@entry=17204162, signal_p=signal_p@entry=1)
>     at xfaces.c:1967
> #1  0x00000000004b047b in get_lface_attributes_no_remap (f=f@entry=0x120f6d0, face_name=face_name@entry=17204162, 
>     attrs=attrs@entry=0x7fffffffc2c0, signal_p=signal_p@entry=1) at xfaces.c:2003
> #2  0x00000000004b160f in get_lface_attributes (f=f@entry=0x120f6d0, face_name=17204162, attrs=attrs@entry=0x7fffffffc2c0, signal_p=1, 
>     named_merge_points=named_merge_points@entry=0x0) at xfaces.c:2050
> #3  0x00000000004b7569 in lookup_named_face (f=f@entry=0x120f6d0, symbol=symbol@entry=17204162, signal_p=signal_p@entry=1)
>     at xfaces.c:4503
> #4  0x00000000004b760e in Fface_font (face=17204162, frame=<optimized out>, character=12672242) at xfaces.c:3844
> #5  0x0000000000554fd2 in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffc438) at eval.c:2815
> #6  0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=16288805, maxdepth=<optimized out>, 
>     args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffc438) at bytecode.c:920
> #7  0x0000000000554b47 in funcall_lambda (fun=22295153, nargs=nargs@entry=1, arg_vector=0x7fffffffc438, 
>     arg_vector@entry=0x7fffffffc5a8) at eval.c:2976
> #8  0x0000000000554e0b in Ffuncall (nargs=2, args=args@entry=0x7fffffffc5a0) at eval.c:2869
> #9  0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=19151957, maxdepth=<optimized out>, 
>     args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffc5a0) at bytecode.c:920
> #10 0x0000000000554b47 in funcall_lambda (fun=22294961, nargs=nargs@entry=1, arg_vector=0x7fffffffc5a0, 
>     arg_vector@entry=0x7fffffffc6e8) at eval.c:2976
> #11 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffc6e0) at eval.c:2869
> #12 0x00000000005551ca in call1 (fn=fn@entry=22953634, arg1=<optimized out>) at eval.c:2607
> #13 0x000000000055c7f2 in mapcar1 (leni=1, vals=vals@entry=0x0, fn=fn@entry=22953634, seq=seq@entry=17119974) at fns.c:2591
> #14 0x000000000055ca32 in Fmapc (function=22953634, sequence=17119974) at fns.c:2680
> #15 0x0000000000554fe2 in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffc7d0) at eval.c:2811
> #16 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=16288725, maxdepth=<optimized out>, 
>     args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffc7d0) at bytecode.c:920
> #17 0x0000000000554b47 in funcall_lambda (fun=22295569, nargs=nargs@entry=1, arg_vector=0x7fffffffc7d0, 
>     arg_vector@entry=0x7fffffffc910) at eval.c:2976
> #18 0x0000000000554e0b in Ffuncall (nargs=2, args=args@entry=0x7fffffffc908) at eval.c:2869
> #19 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>, vector=16289461, maxdepth=<optimized out>, 
>     args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x7fffffffc908) at bytecode.c:920
> #20 0x0000000000554b47 in funcall_lambda (fun=22296849, nargs=nargs@entry=0, arg_vector=0x7fffffffc908, 
>     arg_vector@entry=0x7fffffffca30) at eval.c:2976
> #21 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffffca28) at eval.c:2869
> #22 0x00000000005551e8 in call0 (fn=22958818) at eval.c:2592
> #23 0x000000000046bda6 in run_funs (funs=17204162) at window.c:3315
> #24 0x000000000047188d in run_window_configuration_change_hook (f=f@entry=0x120f6d0) at window.c:3369
> #25 0x0000000000420db1 in adjust_frame_size (f=0x120f6d0, new_width=<optimized out>, new_height=<optimized out>, 
>     inhibit=<optimized out>, pretend=<optimized out>) at frame.c:582
> #26 0x000000000041e4ce in change_frame_size (pixelwise=<optimized out>, safe=<optimized out>, delay=<optimized out>, 
>     pretend=<optimized out>, new_height=<optimized out>, new_width=<optimized out>, f=<optimized out>) at dispnew.c:5560
> #27 do_pending_window_change (safe=false) at dispnew.c:5487
> #28 0x0000000000420e27 in adjust_frame_size (f=0x120f6d0, new_width=<optimized out>, new_height=<optimized out>, inhibit=0, 
>     pretend=<optimized out>) at frame.c:484
> #29 0x00000000004cfd62 in Fx_create_frame (parms=17204162) at xfns.c:3244

When I follow this recipe on my machine, I see no call to
run_window_configuration_change_hook, because adjust_frame_size
returns before that, having discovered (around line 500) that the new
and the old dimensions are identical, and therefore no resize is
needed.

Can you see why this is not so in your case?  Perhaps the calculations
of frame dimensions in the case of Lucid are to blame?

Also, I think linum-update-window should do nothing if 'linum' is not
a valid face on the selected frame, because functions in
window-configuration-change-hook can be called in many situations on
which linum has no control.

Re: Trunk emacs infelicity with linum mode

[Stefan Monnier]

> Also, I think linum-update-window should do nothing if 'linum' is not
> a valid face on the selected frame, because functions in
> window-configuration-change-hook can be called in many situations on
> which linum has no control.

This brings a new concept to me: how can a face be invalid in a specific
frame?  I thought a face either existed (globally) or not.  It can have
different "values" in different frames, but this is the first time
I hear mention of a face being *invalid* in a particular frame while
existing in other frames.

I think it would be better if we can get rid of this subtlety.


        Stefan

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Manoj Srivastava <srivasta@ieee.org>, emacs-devel@gnu.org
> Date: Thu, 04 Sep 2014 11:56:09 -0400
> 
> > Also, I think linum-update-window should do nothing if 'linum' is not
> > a valid face on the selected frame, because functions in
> > window-configuration-change-hook can be called in many situations on
> > which linum has no control.
> 
> This brings a new concept to me: how can a face be invalid in a specific
> frame?

I think it's because the face was not yet realized for that frame.

Before we create a new frame, we realize its basic faces, but not the
rest.  I think.

Re: Trunk emacs infelicity with linum mode

[Stefan Monnier]

>> This brings a new concept to me: how can a face be invalid in a specific
>> frame?
> I think it's because the face was not yet realized for that frame.
> Before we create a new frame, we realize its basic faces, but not the
> rest.  I think.

Yes, I kind of guessed this part, but it would be good to try and not
expose those details to Elisp.  IOW I think it's a bug that Elisp gets
to know about "not yet realized faces".

I guess in the present case, the underlying problem is that we run
window-configuration-change-hook too early.


        Stefan

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: srivasta@ieee.org, emacs-devel@gnu.org
> Date: Thu, 04 Sep 2014 16:25:09 -0400
> 
> I guess in the present case, the underlying problem is that we run
> window-configuration-change-hook too early.

Yes, I think so.  But then not many packages (ab)use that hook like
linum does.

Re: Trunk emacs infelicity with linum mode

[Stefan Monnier]

> Yes, I think so.  But then not many packages (ab)use that hook like
> linum does.

I'd be happy to use some other mechanism in (n)linum to setup the
margin, but window-configuration-change-hook is the best I found so far.


        Stefan

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: srivasta@ieee.org,  emacs-devel@gnu.org
> Date: Fri, 05 Sep 2014 11:23:52 -0400
> 
> > Yes, I think so.  But then not many packages (ab)use that hook like
> > linum does.
> 
> I'd be happy to use some other mechanism in (n)linum to setup the
> margin, but window-configuration-change-hook is the best I found so far.

Setting up the margins is not the problem.  Redrawing the display
using the special face is.

Re: Trunk emacs infelicity with linum mode

[Stefan Monnier]

>> I'd be happy to use some other mechanism in (n)linum to setup the
>> margin, but window-configuration-change-hook is the best I found so far.
> Setting up the margins is not the problem.  Redrawing the display
> using the special face is.

Hmm... so you're saying on linum.el is problematic, whereas nlinum.el
is fine?


        Stefan

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: srivasta@ieee.org,  emacs-devel@gnu.org
> Date: Fri, 05 Sep 2014 12:23:11 -0400
> 
> >> I'd be happy to use some other mechanism in (n)linum to setup the
> >> margin, but window-configuration-change-hook is the best I found so far.
> > Setting up the margins is not the problem.  Redrawing the display
> > using the special face is.
> 
> Hmm... so you're saying on linum.el is problematic, whereas nlinum.el
> is fine?

Most probably, although I didn't try.  Perhaps Manoj could try in his
setup.

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Fri, Sep 05 2014, Eli Zaretskii wrote:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: srivasta@ieee.org,  emacs-devel@gnu.org
>> Date: Fri, 05 Sep 2014 12:23:11 -0400
>> 
>> >> I'd be happy to use some other mechanism in (n)linum to setup the
>> >> margin, but window-configuration-change-hook is the best I found so far.
>> > Setting up the margins is not the problem.  Redrawing the display
>> > using the special face is.
>> 
>> Hmm... so you're saying on linum.el is problematic, whereas nlinum.el
>> is fine?
>
> Most probably, although I didn't try.  Perhaps Manoj could try in his
> setup.

        I am willing to give this a try. Where do I find nlinum.el?

        manoj
-- 
In Nature there are neither rewards nor punishments, there are
consequences. R.G. Ingersoll
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Manoj Srivastava <srivasta@ieee.org>
> Date: Fri, 05 Sep 2014 18:19:45 -0700
> 
> On Fri, Sep 05 2014, Eli Zaretskii wrote:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: srivasta@ieee.org,  emacs-devel@gnu.org
> >> Date: Fri, 05 Sep 2014 12:23:11 -0400
> >> 
> >> >> I'd be happy to use some other mechanism in (n)linum to setup the
> >> >> margin, but window-configuration-change-hook is the best I found so far.
> >> > Setting up the margins is not the problem.  Redrawing the display
> >> > using the special face is.
> >> 
> >> Hmm... so you're saying on linum.el is problematic, whereas nlinum.el
> >> is fine?
> >
> > Most probably, although I didn't try.  Perhaps Manoj could try in his
> > setup.
> 
>         I am willing to give this a try. Where do I find nlinum.el?

On ELPA.

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Sat, Sep 06 2014, Eli Zaretskii wrote:

>> From: Manoj Srivastava <srivasta@ieee.org>
>> Date: Fri, 05 Sep 2014 18:19:45 -0700
>> 
>> On Fri, Sep 05 2014, Eli Zaretskii wrote:
>> 
>> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> >> Cc: srivasta@ieee.org,  emacs-devel@gnu.org
>> >> Date: Fri, 05 Sep 2014 12:23:11 -0400
>> >> 
>> >> >> I'd be happy to use some other mechanism in (n)linum to setup the
>> >> >> margin, but window-configuration-change-hook is the best I found so far.
>> >> > Setting up the margins is not the problem.  Redrawing the display
>> >> > using the special face is.
>> >> 
>> >> Hmm... so you're saying on linum.el is problematic, whereas nlinum.el
>> >> is fine?
>> >
>> > Most probably, although I didn't try.  Perhaps Manoj could try in his
>> > setup.
>> 
>>         I am willing to give this a try. Where do I find nlinum.el?
>
> On ELPA.

        For the record, nliunum.el does not work (it requires linum.el,
 and I think Martin is on the right track). I will be traveling this
 weekend and next week, so I might not be able to test out any fixes
 until next weekend.

        Thanks for the help,

        manoj
-- 
He that teaches himself has a fool for a master. Benjamin Franklin
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[Stefan Monnier]

>         For the record, nliunum.el does not work

As stated, that is simply untrue.  So please clarify,


        Stefan

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Sat, Sep 06 2014, Stefan Monnier wrote:

>>         For the record, nliunum.el does not work
>
> As stated, that is simply untrue.  So please clarify,

        Untrue? Strong words.

        You conveniently elided the  context. It does not work in the
 context that linum..el was also not working. If you are interested in
 the details, read the context you excluded. I am not all that
 interested in providing proof that I am speaking the truth.

        manoj
-- 
Slow day.  Practice crawling.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[Stefan Monnier]

>         You conveniently elided the  context. It does not work in the
>  context that linum..el was also not working.

So you're saying it gives the same error?
OK, thanks for testing,


        Stefan

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 12948 bytes --]

On Thu, Sep 04 2014, Eli Zaretskii wrote:

>> From: Manoj Srivastava <srivasta@ieee.org>
>> Date: Wed, 03 Sep 2014 09:28:20 -0700
>> 
>> Breakpoint 3, lface_from_face_name_no_resolve (f=f@entry=0x120f6d0,
>> face_name=face_name@entry=17204162, signal_p=signal_p@entry=1)
>>     at xfaces.c:1967
>> 1967        signal_error ("Invalid face", face_name);
>> --8<---------------cut here---------------end--------------->8---
>> 
>> --8<---------------cut here---------------start------------->8---
>> #0 lface_from_face_name_no_resolve (f=f@entry=0x120f6d0,
>> face_name=face_name@entry=17204162, signal_p=signal_p@entry=1)
>>     at xfaces.c:1967
>> #1 0x00000000004b047b in get_lface_attributes_no_remap
>> (f=f@entry=0x120f6d0, face_name=face_name@entry=17204162,
>>     attrs=attrs@entry=0x7fffffffc2c0, signal_p=signal_p@entry=1) at xfaces.c:2003
>> #2 0x00000000004b160f in get_lface_attributes (f=f@entry=0x120f6d0,
>> face_name=17204162, attrs=attrs@entry=0x7fffffffc2c0, signal_p=1,
>>     named_merge_points=named_merge_points@entry=0x0) at xfaces.c:2050
>> #3 0x00000000004b7569 in lookup_named_face (f=f@entry=0x120f6d0,
>> symbol=symbol@entry=17204162, signal_p=signal_p@entry=1)
>>     at xfaces.c:4503
>> #4 0x00000000004b760e in Fface_font (face=17204162, frame=<optimized
>> out>, character=12672242) at xfaces.c:3844
>> #5  0x0000000000554fd2 in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffc438) at eval.c:2815
>> #6 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>,
>> vector=16288805, maxdepth=<optimized out>,
>>     args_template=<optimized out>, nargs=nargs@entry=1,
>> args=<optimized out>, args@entry=0x7fffffffc438) at bytecode.c:920
>> #7  0x0000000000554b47 in funcall_lambda (fun=22295153, nargs=nargs@entry=1, arg_vector=0x7fffffffc438, 
>>     arg_vector@entry=0x7fffffffc5a8) at eval.c:2976
>> #8  0x0000000000554e0b in Ffuncall (nargs=2, args=args@entry=0x7fffffffc5a0) at eval.c:2869
>> #9 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>,
>> vector=19151957, maxdepth=<optimized out>,
>>     args_template=<optimized out>, nargs=nargs@entry=1,
>> args=<optimized out>, args@entry=0x7fffffffc5a0) at bytecode.c:920
>> #10 0x0000000000554b47 in funcall_lambda (fun=22294961, nargs=nargs@entry=1, arg_vector=0x7fffffffc5a0, 
>>     arg_vector@entry=0x7fffffffc6e8) at eval.c:2976
>> #11 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffc6e0) at eval.c:2869
>> #12 0x00000000005551ca in call1 (fn=fn@entry=22953634, arg1=<optimized out>) at eval.c:2607
>> #13 0x000000000055c7f2 in mapcar1 (leni=1, vals=vals@entry=0x0,
>> fn=fn@entry=22953634, seq=seq@entry=17119974) at fns.c:2591
>> #14 0x000000000055ca32 in Fmapc (function=22953634, sequence=17119974) at fns.c:2680
>> #15 0x0000000000554fe2 in Ffuncall (nargs=<optimized out>, args=args@entry=0x7fffffffc7d0) at eval.c:2811
>> #16 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>,
>> vector=16288725, maxdepth=<optimized out>,
>>     args_template=<optimized out>, nargs=nargs@entry=1,
>> args=<optimized out>, args@entry=0x7fffffffc7d0) at bytecode.c:920
>> #17 0x0000000000554b47 in funcall_lambda (fun=22295569, nargs=nargs@entry=1, arg_vector=0x7fffffffc7d0, 
>>     arg_vector@entry=0x7fffffffc910) at eval.c:2976
>> #18 0x0000000000554e0b in Ffuncall (nargs=2, args=args@entry=0x7fffffffc908) at eval.c:2869
>> #19 0x0000000000589bf3 in exec_byte_code (bytestr=<optimized out>,
>> vector=16289461, maxdepth=<optimized out>,
>>     args_template=<optimized out>, nargs=nargs@entry=0,
>> args=<optimized out>, args@entry=0x7fffffffc908) at bytecode.c:920
>> #20 0x0000000000554b47 in funcall_lambda (fun=22296849, nargs=nargs@entry=0, arg_vector=0x7fffffffc908, 
>>     arg_vector@entry=0x7fffffffca30) at eval.c:2976
>> #21 0x0000000000554e0b in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffffca28) at eval.c:2869
>> #22 0x00000000005551e8 in call0 (fn=22958818) at eval.c:2592
>> #23 0x000000000046bda6 in run_funs (funs=17204162) at window.c:3315
>> #24 0x000000000047188d in run_window_configuration_change_hook (f=f@entry=0x120f6d0) at window.c:3369
>> #25 0x0000000000420db1 in adjust_frame_size (f=0x120f6d0,
>> new_width=<optimized out>, new_height=<optimized out>,
>>     inhibit=<optimized out>, pretend=<optimized out>) at frame.c:582
>> #26 0x000000000041e4ce in change_frame_size (pixelwise=<optimized
>> out>, safe=<optimized out>, delay=<optimized out>,
>>     pretend=<optimized out>, new_height=<optimized out>,
>> new_width=<optimized out>, f=<optimized out>) at dispnew.c:5560
>> #27 do_pending_window_change (safe=false) at dispnew.c:5487
>> #28 0x0000000000420e27 in adjust_frame_size (f=0x120f6d0,
>> new_width=<optimized out>, new_height=<optimized out>, inhibit=0,
>>     pretend=<optimized out>) at frame.c:484
>> #29 0x00000000004cfd62 in Fx_create_frame (parms=17204162) at xfns.c:3244
>
> When I follow this recipe on my machine, I see no call to
> run_window_configuration_change_hook, because adjust_frame_size
> returns before that, having discovered (around line 500) that the new
> and the old dimensions are identical, and therefore no resize is
> needed.
>
> Can you see why this is not so in your case?  Perhaps the calculations
> of frame dimensions in the case of Lucid are to blame?
>
> Also, I think linum-update-window should do nothing if 'linum' is not
> a valid face on the selected frame, because functions in
> window-configuration-change-hook can be called in many situations on
> which linum has no control.

        Here is an gdb session with more breakpoints.
 
--8<---------------cut here---------------start------------->8---
(gdb) list
484           x_set_window_size (f, 0, new_text_width, new_text_height, 1);
485           f->resized_p = true;
486
487           return;
488         }
489     #endif
490
491       if (new_text_width == old_text_width
492           && new_text_height == old_text_height
493           && new_windows_width == old_windows_width
(gdb) list
494           && new_windows_height == old_windows_height
495           && new_pixel_width == old_pixel_width
496           && new_pixel_height == old_pixel_height)
497         /* No change.  Sanitize window sizes and return.  */
498         {
499           sanitize_window_sizes (frame, Qt);
500           sanitize_window_sizes (frame, Qnil);
501
502           return;
503         }
(gdb) list
504
505       block_input ();
506
507     #ifdef MSDOS
508       /* We only can set screen dimensions to certain values supported
509          by our video hardware.  Try to find the smallest size greater
510          or equal to the requested dimensions.  */
511       dos_set_window_size (&new_lines, &new_cols);
512     #endif
513
(gdb) list
514       if (new_windows_width != old_windows_width)
515         {
516           resize_frame_windows (f, new_windows_width, 1, 1);
517
518           /* MSDOS frames cannot PRETEND, as they change frame size by
519              manipulating video hardware.  */
520           if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
521             FrameCols (FRAME_TTY (f)) = new_cols;
522
523     #if defined (HAVE_WINDOW_SYSTEM) && ! defined (USE_GTK) && ! defined (HAVE_NS)
(gdb) list
524           if (WINDOWP (f->tool_bar_window))
525             {
526               XWINDOW (f->tool_bar_window)->pixel_width = new_windows_width;
527               XWINDOW (f->tool_bar_window)->total_cols
528                 = new_windows_width / unit_width;
529             }
530     #endif
531         }
532
--8<---------------cut here---------------end--------------->8---

        For some reason, all the values for the old window are set to
 10. Here is the session:
--8<---------------cut here---------------start------------->8---
Breakpoint 4, adjust_frame_size (f=0x11db380, new_width=<optimized out>, new_height=<optimized out>, inhibit=5, 
    pretend=<optimized out>) at frame.c:514
514       if (new_windows_width != old_windows_width)
(gdb) list
509          by our video hardware.  Try to find the smallest size greater
510          or equal to the requested dimensions.  */
511       dos_set_window_size (&new_lines, &new_cols);
512     #endif
513
514       if (new_windows_width != old_windows_width)
515         {
516           resize_frame_windows (f, new_windows_width, 1, 1);
517
518           /* MSDOS frames cannot PRETEND, as they change frame size by
(gdb) print new_windows_width
$1 = 106
(gdb) print old_windows_width
$2 = 10
 ...
*(gdb) print new_text_width
$4 = 90
*(gdb) print old_text_width
$5 = 10
(gdb) print new_windows_width
$6 = 106
*(gdb) print old_windows_width
$7 = 10
(gdb) print new_windows_height
$8 = 230
*(gdb) print old_windows_height
$9 = 10
(gdb) print new_pixel_width
$10 = 108
*(gdb) print old_pixel_width
$11 = 10
--8<---------------cut here---------------end--------------->8---




        Here are the inputs to the function adjust_frame_seze: 
--8<---------------cut here---------------start------------->8---
(gdb) print *f
$12 = {
  header = {
    size = 4611686018477899797
  }, 
  name = 16103377, 
  icon_name = 12672242, 
  title = 12672242, 
  focus_frame = 12672242, 
  root_window = 19015685, 
  selected_window = 19015685, 
  minibuffer_window = 19019797, 
  param_alist = 17180166, 
  scroll_bars = 12672242, 
  condemned_scroll_bars = 12672242, 
  menu_bar_items = 12672242, 
  face_alist = 17323366, 
  menu_bar_vector = 12672242, 
  buffer_predicate = 12672242, 
  buffer_list = 17066726, 
  buried_buffer_list = 12672242, 
  tool_bar_window = 12672242, 
  desired_tool_bar_string = 12672242, 
  current_tool_bar_string = 12672242, 
  tool_bar_items = 12672242, 
  font_data = 12672242, 
  face_cache = 0xc84ae0, 
  last_tool_bar_item = -1, 
  menu_bar_items_used = 0, 
  namebuf = 0x0, 
  shell_position = 0x0, 
  current_pool = 0x0, 
  desired_pool = 0x0, 
  desired_matrix = 0x0, 
  current_matrix = 0x0, 
  glyphs_initialized_p = true, 
  resized_p = false, 
  default_face_done_p = true, 
  already_hscrolled_p = false, 
  updated_p = false, 
  minimize_tool_bar_window_p = false, 
  fonts_changed = false, 
  cursor_type_changed = false, 
  redisplay = true, 
  external_menu_bar = false, 
  visible = 0, 
  iconified = false, 
  garbaged = true, 
  wants_modeline = true, 
  auto_raise = false, 
  auto_lower = false, 
  no_split = false, 
  explicit_name = false, 
  window_sizes_changed = false, 
  mouse_moved = false, 
  pointer_invisible = false, 
  frozen_window_starts = false, 
  output_method = output_x_window, 
  want_fullscreen = FULLSCREEN_NONE, 
  vertical_scroll_bar_type = vertical_scroll_bar_left, 
  horizontal_scroll_bars = false, 
  new_pixelwise = false, 
  official = false,
    tool_bar_lines = 0, 
  tool_bar_height = 0, 
  n_tool_bar_rows = 0, 
  n_tool_bar_items = 0, 
  decode_mode_spec_buffer = 0xd17040 "\220\263T\001", 
  insert_line_cost = 0x0, 
  delete_line_cost = 0x0, 
  insert_n_lines_cost = 0x0, 
  delete_n_lines_cost = 0x0, 
  text_cols = 10, 
  text_lines = 10, 
  total_cols = 10, 
  total_lines = 10, 
  text_width = 10, 
  text_height = 10, 
  new_width = 0, 
  new_height = 0, 
  left_pos = 0, 
  top_pos = 0, 
  pixel_width = 10, 
  pixel_height = 10, 
  x_pixels_diff = 0, 
  y_pixels_diff = 0, 
  win_gravity = 0, 
  size_hint_flags = 0, 
  border_width = 0, 
  internal_border_width = 1, 
  right_divider_width = 0, 
  bottom_divider_width = 0, 
  left_fringe_width = 8, 
  right_fringe_width = 8, 
  fringe_cols = 2, 
  menu_bar_lines = 0, 
  menu_bar_height = 0, 
  column_width = 9, 
  line_height = 23, 
  terminal = 0xfedbd8, 
  output_data = {
    tty = 0xd0f750, 
    x = 0xd0f750, 
    w32 = 0xd0f750, 
    ns = 0xd0f750, 
    nothing = 13694800
  }, 
  font_driver_list = 0x13e4040, 
  wait_event_type = 0, 
  desired_cursor = FILLED_BOX_CURSOR, 
  cursor_width = 0, 
  blink_off_cursor = FILLED_BOX_CURSOR, 
  blink_off_cursor_width = 0, 
  config_scroll_bar_width = 0, 
  config_scroll_bar_cols = 2, 
  config_scroll_bar_height = 0, 
  config_scroll_bar_lines = 0, 
  cost_calculation_baud_rate = 0, 
  alpha = {0, 0}, 
  gamma = 0, 
  extra_line_spacing = 0, 
  background_pixel = 16777215, 
  foreground_pixel = 0
}
(gdb) print new_height
$14 = <optimized out>
(gdb) print new_width
$15 = <optimized out>
(gdb) print inhibit
$16 = 5
*(gdb) print pretend
$17 = <optimized out>
--8<---------------cut here---------------end--------------->8---

        manoj
-- 
A pencil with no point needs no eraser.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> From: Manoj Srivastava <srivasta@ieee.org>
> Date: Fri, 05 Sep 2014 11:48:09 -0700
> 
>         For some reason, all the values for the old window are set to
>  10. Here is the session:
> --8<---------------cut here---------------start------------->8---
> Breakpoint 4, adjust_frame_size (f=0x11db380, new_width=<optimized out>, new_height=<optimized out>, inhibit=5, 
>     pretend=<optimized out>) at frame.c:514
> 514       if (new_windows_width != old_windows_width)
> (gdb) list
> 509          by our video hardware.  Try to find the smallest size greater
> 510          or equal to the requested dimensions.  */
> 511       dos_set_window_size (&new_lines, &new_cols);
> 512     #endif
> 513
> 514       if (new_windows_width != old_windows_width)
> 515         {
> 516           resize_frame_windows (f, new_windows_width, 1, 1);
> 517
> 518           /* MSDOS frames cannot PRETEND, as they change frame size by
> (gdb) print new_windows_width
> $1 = 106
> (gdb) print old_windows_width
> $2 = 10
>  ...
> *(gdb) print new_text_width
> $4 = 90
> *(gdb) print old_text_width
> $5 = 10
> (gdb) print new_windows_width
> $6 = 106
> *(gdb) print old_windows_width
> $7 = 10
> (gdb) print new_windows_height
> $8 = 230
> *(gdb) print old_windows_height
> $9 = 10
> (gdb) print new_pixel_width
> $10 = 108
> *(gdb) print old_pixel_width
> $11 = 10

Thanks.

Martin, could you take a look at this?  The 10x10 are the dimensiuons
used when there's nothing to use initially, AFAIR.

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 >> $1 = 106
 >> (gdb) print old_windows_width
 >> $2 = 10
 >>   ...
 >> *(gdb) print new_text_width
 >> $4 = 90
 >> *(gdb) print old_text_width
 >> $5 = 10
 >> (gdb) print new_windows_width
 >> $6 = 106
 >> *(gdb) print old_windows_width
 >> $7 = 10
 >> (gdb) print new_windows_height
 >> $8 = 230
 >> *(gdb) print old_windows_height
 >> $9 = 10
 >> (gdb) print new_pixel_width
 >> $10 = 108
 >> *(gdb) print old_pixel_width
 >> $11 = 10
 >
 > Thanks.
 >
 > Martin, could you take a look at this?  The 10x10 are the dimensiuons
 > used when there's nothing to use initially, AFAIR.

These are the old dimensions that should be replaced with new dimensions
here.  There's nothing strange in this adjust_frame_size call if it
happens on line 3163 of xfns.c.  However, that call should neither
provoke a subsequent x_set_window_size call nor should it run any
`window-configuration-change-hook'.  It would be strange if the values
above were printed after the call on line 3238 of xfns.c, though.  At
that time the old dimensions should have been replaced already.  I'll
try to look into this.

martin

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 From the frame creation code everything is normal AFAICT.  The problem
is with `linum--face-height' added on 2014-07-08 to the linum.el code:

(defun linum--face-height (face)
   (aref (font-info (face-font face)) 2))

...

     (when (display-graphic-p)
       (setq width (ceiling
                    ;; We'd really want to check the widths rather than the
                    ;; heights, but it's a start.
                    (/ (* width 1.0 (linum--face-height 'linum))
                       (frame-char-height)))))

If you take these out, the frame is created as usual.

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Sat, 06 Sep 2014 13:18:34 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
>  From the frame creation code everything is normal AFAICT.  The problem
> is with `linum--face-height' added on 2014-07-08 to the linum.el code:
> 
> (defun linum--face-height (face)
>    (aref (font-info (face-font face)) 2))
> 
> ...
> 
>      (when (display-graphic-p)
>        (setq width (ceiling
>                     ;; We'd really want to check the widths rather than the
>                     ;; heights, but it's a start.
>                     (/ (* width 1.0 (linum--face-height 'linum))
>                        (frame-char-height)))))
> 
> If you take these out, the frame is created as usual.

Yes, but how does that help us resolve this problem?  There's nothing
wrong in general with calling face-font, so linum-mode doesn't do
anything blatantly incorrect here.  It's just that this function is
called "too early" in the frame creation process.

How about adding some simple flag that would avoid calling
window-configuration-change-hook when adjust_frame_size is called from
x-create-frame?

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 > Yes, but how does that help us resolve this problem?  There's nothing
 > wrong in general with calling face-font, so linum-mode doesn't do
 > anything blatantly incorrect here.  It's just that this function is
 > called "too early" in the frame creation process.

At the time `window-configuration-change-hook' is called, the frame is
considered "official" already.  Do you really want to wait calling it
until redisplay has passed over the frame at least once?

 > How about adding some simple flag that would avoid calling
 > window-configuration-change-hook when adjust_frame_size is called from
 > x-create-frame?

There is such a flag: f->official.  It does exactly that for all
adjust_frame_size calls before the last one that causes trouble.  But if
we don't run `window-configuration-change-hook' here, we might not run
it at all when creating a new frame.

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Sun, 07 Sep 2014 20:03:27 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: srivasta@ieee.org, emacs-devel@gnu.org
> 
>  > Yes, but how does that help us resolve this problem?  There's nothing
>  > wrong in general with calling face-font, so linum-mode doesn't do
>  > anything blatantly incorrect here.  It's just that this function is
>  > called "too early" in the frame creation process.
> 
> At the time `window-configuration-change-hook' is called, the frame is
> considered "official" already.  Do you really want to wait calling it
> until redisplay has passed over the frame at least once?

Redisplay is not the issue here; non-basic faces are.  See below.

>  > How about adding some simple flag that would avoid calling
>  > window-configuration-change-hook when adjust_frame_size is called from
>  > x-create-frame?
> 
> There is such a flag: f->official.  It does exactly that for all
> adjust_frame_size calls before the last one that causes trouble.  But if
> we don't run `window-configuration-change-hook' here, we might not run
> it at all when creating a new frame.

f->official only means that the basic faces were realized; all the
other faces are not realized yet.  So if you want that flag to be it,
we will have to make sure all the faces are realized before we set
that flag.  I believe the faces are realized in
face-set-after-frame-default.

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 > f->official only means that the basic faces were realized; all the
 > other faces are not realized yet.  So if you want that flag to be it,
 > we will have to make sure all the faces are realized before we set
 > that flag.  I believe the faces are realized in
 > face-set-after-frame-default.

OK.  I can offer a number of ways to approach this problem:

(1) Do not run `window-configuration-change-hook' while creating a
     frame.

(2) Run `window-configuration-change-hook' from
     `tty-create-frame-with-faces' and `x-create-frame-with-faces' if
     `success' is non-nil in the unwindform.

(3) Like (2) but in addition set f->official t if `success' is non-nil
     in the unwindform.

martin

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 > Yes, but how does that help us resolve this problem?  There's nothing
 > wrong in general with calling face-font, so linum-mode doesn't do
 > anything blatantly incorrect here.  It's just that this function is
 > called "too early" in the frame creation process.

Ahh, I forgot: Any clues why the bug doesn't trigger on Gtk and Windows
builds?

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Sun, 07 Sep 2014 20:09:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: srivasta@ieee.org, emacs-devel@gnu.org
> 
>  > Yes, but how does that help us resolve this problem?  There's nothing
>  > wrong in general with calling face-font, so linum-mode doesn't do
>  > anything blatantly incorrect here.  It's just that this function is
>  > called "too early" in the frame creation process.
> 
> Ahh, I forgot: Any clues why the bug doesn't trigger on Gtk and Windows
> builds?

On Windows it's because the new frame's dimensions are already correct
(not 10x10) when adjust_frame_size is called.

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 > On Windows it's because the new frame's dimensions are already correct
 > (not 10x10) when adjust_frame_size is called.

The only way to change the coordinates from 10x10 to something else is
via adjust_frame_size.

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Mon, 08 Sep 2014 11:32:03 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: srivasta@ieee.org, emacs-devel@gnu.org
> 
>  > On Windows it's because the new frame's dimensions are already correct
>  > (not 10x10) when adjust_frame_size is called.
> 
> The only way to change the coordinates from 10x10 to something else is
> via adjust_frame_size.

You are welcome to step through x_create_frame on Windows, after
typing "C-x 5 2", and see how it avoids that.

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 >> The only way to change the coordinates from 10x10 to something else is
 >> via adjust_frame_size.
 >
 > You are welcome to step through x_create_frame on Windows, after
 > typing "C-x 5 2", and see how it avoids that.

Here, I get

(gdb) bt
#0  adjust_frame_size (f=0x49b98a8, new_width=80, new_height=160, inhibit=5, pretend=true) at frame.c:390
#1  0x0120420c in Fx_create_frame (parameters=...) at w32fns.c:4609
[...]

and

(gdb) p FRAME_TEXT_HEIGHT (f)
$1 = 10
(gdb) p  FRAME_TEXT_WIDTH (f)
$2 = 10

Stepping through adjust_frame_size now gets me on line 550 of frame.c

(gdb) p  FRAME_TEXT_WIDTH (f)
$8 = 80
(gdb) p FRAME_TEXT_HEIGHT (f)
$9 = 160
(gdb)

Or what did you mean?

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Wed, 10 Sep 2014 10:03:40 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: srivasta@ieee.org, emacs-devel@gnu.org
> 
>  >> The only way to change the coordinates from 10x10 to something else is
>  >> via adjust_frame_size.
>  >
>  > You are welcome to step through x_create_frame on Windows, after
>  > typing "C-x 5 2", and see how it avoids that.
> 
> Here, I get
> 
> (gdb) bt
> #0  adjust_frame_size (f=0x49b98a8, new_width=80, new_height=160, inhibit=5, pretend=true) at frame.c:390
> #1  0x0120420c in Fx_create_frame (parameters=...) at w32fns.c:4609

Is that in Fx_create_frame called because of "C-x 5 2"?  If so, it is
very strange, because I see something very different with the trunk
from a few days ago.  Please find below a GDB session stepping through
the code that should hopefully be self-explanatory.

======================================================================
(gdb) break Fx_create_frame
Breakpoint 3 at 0x120132f: file w32fns.c, line 4414.
(gdb) disable 3
(gdb) break Fredraw_display
Breakpoint 4 at 0x100805d: file dispnew.c, line 3023.
(gdb) r -Q
Starting program: d:\usr\eli\emacs\emacs-trunk_2014-09-01\src\emacs.exe -Q
Breakpoint 4, Fredraw_display () at dispnew.c:3023
3023      FOR_EACH_FRAME (tail, frame)
(gdb) enable 3
(gdb) c
Continuing.
Breakpoint 3, Fx_create_frame (parameters=117344758) at w32fns.c:4414
4414      int minibuffer_only = 0;
(gdb) until 4678
Fx_create_frame (parameters=117344750) at w32fns.c:4678
4678      adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, 1);
(gdb) s
adjust_frame_size (f=0x6feff78, new_width=640, new_height=560, inhibit=0,
    pretend=true) at frame.c:390
390       int unit_width = FRAME_COLUMN_WIDTH (f);
(gdb) n
391       int unit_height = FRAME_LINE_HEIGHT (f);
(gdb)
392       int old_pixel_width = FRAME_PIXEL_WIDTH (f);
(gdb) n
393       int old_pixel_height = FRAME_PIXEL_HEIGHT (f);
(gdb)
399       int windows_width = FRAME_WINDOWS_WIDTH (f);
(gdb)
400       int windows_height = FRAME_WINDOWS_HEIGHT (f);
(gdb)
403       struct window *r = XWINDOW (FRAME_ROOT_WINDOW (f));
(gdb)
404       int old_windows_width = WINDOW_PIXEL_WIDTH (r);
(gdb)
406         = (WINDOW_PIXEL_HEIGHT (r)
(gdb)
407            + (FRAME_HAS_MINIBUF_P (f)
(gdb) n
409               : 0));
(gdb)
407            + (FRAME_HAS_MINIBUF_P (f)
(gdb)
408               ? WINDOW_PIXEL_HEIGHT (XWINDOW (FRAME_MINIBUF_WINDOW (f)))
(gdb)
409               : 0));
(gdb)
405       int old_windows_height
(gdb)
411       int old_text_width = FRAME_TEXT_WIDTH (f);
(gdb) p old_windows_height
$1 = 577
(gdb) n
412       int old_text_height = FRAME_TEXT_HEIGHT (f);
(gdb)
414       int new_text_width = (new_width >= 0) ? new_width : old_text_width;
(gdb) p old_windows_width
$2 = 673
(gdb) n
415       int new_text_height = (new_height >= 0) ? new_height : old_text_height;
(gdb)
420       XSETFRAME (frame, f);
(gdb) p new_text_width
$3 = 640
(gdb) p new_text_height
$4 = 560
(gdb) p old_text_width
$5 = 640
(gdb) p old_text_height
$6 = 560
(gdb) n
424       min_windows_width = frame_windows_min_size (frame, Qt, Qt);
(gdb)
425       min_windows_height = frame_windows_min_size (frame, Qnil, Qt);
(gdb)
427       if (inhibit >= 2 && inhibit <= 4)
(gdb) p min_windows_width
$7 = 80
(gdb) p min_windows_height
$8 = 80
(gdb) n
441         inhibit_horizontal = inhibit_vertical = inhibit == 5;
(gdb)
443       new_pixel_width = ((inhibit_horizontal && (inhibit < 5))
(gdb) n
445                          : max (FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width),
(gdb)
443       new_pixel_width = ((inhibit_horizontal && (inhibit < 5))
(gdb)
448       new_windows_width = new_pixel_width - 2 * FRAME_INTERNAL_BORDER_WIDTH (f);
(gdb) p new_pixel_width
$9 = 673
(gdb) n
449       new_text_width = FRAME_PIXEL_TO_TEXT_WIDTH (f, new_pixel_width);
(gdb)
450       new_cols = new_text_width / unit_width;
(gdb) p new_text_width
$10 = 640
(gdb) n
452       new_pixel_height = ((inhibit_vertical && (inhibit < 5))
(gdb) p new_cols
$11 = 80
(gdb) n
454                           : max (FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_hei
ght),
(gdb)
452       new_pixel_height = ((inhibit_vertical && (inhibit < 5))
(gdb)
459                             - FRAME_TOP_MARGIN_HEIGHT (f)
(gdb)
460                             - 2 * FRAME_INTERNAL_BORDER_WIDTH (f));
(gdb)
458       new_windows_height = (new_pixel_height
(gdb)
461       new_text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, new_pixel_height);
(gdb)
462       new_lines = new_text_height / unit_height;
(gdb)
465       if (FRAME_WINDOW_P (f)
(gdb) p new_pixel_height
$12 = 611
(gdb) p new_windows_height
$13 = 577
(gdb) p new_text_height
$14 = 560
(gdb) p new_lines
$15 = 35
(gdb) p old_lines
$16 = (struct row_entry **) 0x6f9b550
(gdb) n
466           && f->official
(gdb)
467           && ((!inhibit_horizontal
(gdb)
468                && (new_pixel_width != old_pixel_width
(gdb)
469                    || inhibit == 0 || inhibit == 2))
(gdb) n
479           if (inhibit_horizontal)
(gdb)
481           else if (inhibit_vertical)
(gdb)
484           x_set_window_size (f, 0, new_text_width, new_text_height, 1);
(gdb) s
x_set_window_size (f=0x6feff78, change_gravity=0, width=640, height=560,
    pixelwise=true) at w32term.c:6092
6092      block_input ();
(gdb) n
6094      if (pixelwise)
(gdb)
6096          pixelwidth = FRAME_TEXT_TO_PIXEL_WIDTH (f, width);
(gdb)
6097          pixelheight = FRAME_TEXT_TO_PIXEL_HEIGHT (f, height);
(gdb)
6105      f->win_gravity = NorthWestGravity;
(gdb) p pixelwidth
$17 = 673
(gdb) p pixelheight
$18 = 611
(gdb) n
6106      x_wm_set_size_hint (f, (long) 0, 0);
(gdb) n
6108      f->want_fullscreen = FULLSCREEN_NONE;
(gdb)
6109      w32fullscreen_hook (f);
(gdb)
6111      rect.left = rect.top = 0;
(gdb)
6112      rect.right = pixelwidth;
(gdb)
6113      rect.bottom = pixelheight;
(gdb)
6116                        FRAME_EXTERNAL_MENU_BAR (f));
(gdb)
6115      AdjustWindowRect (&rect, f->output_data.w32->dwStyle,
(gdb)
6122                         rect.bottom - rect.top,
(gdb)
6121                         rect.right - rect.left,
(gdb)
6118      my_set_window_pos (FRAME_W32_WINDOW (f),
(gdb)
6152      if (w32_enable_frame_resize_hack)
(gdb)
6156                             FRAME_PIXEL_TO_TEXT_HEIGHT (f, pixelheight),
(gdb)
6155          change_frame_size (f, FRAME_PIXEL_TO_TEXT_WIDTH (f, pixelwidth),
(gdb) s
change_frame_size (f=0x6feff78, new_width=640, new_height=560, pretend=false,
    delay=true, safe=false, pixelwise=true) at dispnew.c:5559
5559        change_frame_size_1 (f, new_width, new_height, pretend, delay, safe,
(gdb) s
change_frame_size_1 (f=0x6feff78, new_width=640, new_height=560,
    pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5498
5498      if (delay || (redisplaying_p && !safe))
(gdb) n
5500          f->new_width = new_width;
(gdb)
5501          f->new_height = new_height;
(gdb)
5502          f->new_pixelwise = pixelwise;
(gdb)
5503          delayed_size_change = 1;
(gdb)
5530    }
(gdb) n
change_frame_size (f=0x6feff78, new_width=640, new_height=560, pretend=false,
    delay=true, safe=false, pixelwise=true) at dispnew.c:5561
5561    }
(gdb)
x_set_window_size (f=0x6feff78, change_gravity=0, width=640, height=560,
    pixelwise=true) at w32term.c:6158
6158          SET_FRAME_GARBAGED (f);
(gdb)
6161          mark_window_cursors_off (XWINDOW (f->root_window));
(gdb)
6168          cancel_mouse_face (f);
(gdb)
6171      unblock_input ();
(gdb)
6173      do_pending_window_change (0);
(gdb) s
do_pending_window_change (safe=false) at dispnew.c:5472
5472      if (redisplaying_p && !safe)
(gdb) p redisplaying_p
$19 = false
(gdb) n
5475      while (delayed_size_change)
(gdb) p delayed_size_change
$20 = true
(gdb) n
5479          delayed_size_change = 0;
(gdb)
5481          FOR_EACH_FRAME (tail, frame)
(gdb)
5483              struct frame *f = XFRAME (frame);
(gdb)
5485              if (f->new_height != 0 || f->new_width != 0)
(gdb) p f->new_height
$21 = 560
(gdb) p f->new_width
$22 = 640
(gdb) n
5487                                   0, 0, safe, f->new_pixelwise);
(gdb) s
5486                change_frame_size (f, f->new_width, f->new_height,
(gdb) s
change_frame_size (f=0x6feff78, new_width=640, new_height=560, pretend=false,
    delay=false, safe=false, pixelwise=true) at dispnew.c:5559
5559        change_frame_size_1 (f, new_width, new_height, pretend, delay, safe,
(gdb) s
change_frame_size_1 (f=0x5703b60, new_width=640, new_height=560,
    pretend=false, delay=false, safe=false, pixelwise=true) at dispnew.c:5498
5498      if (delay || (redisplaying_p && !safe))
(gdb) n
5508          f->new_height = 0;
(gdb)
5509          f->new_width = 0;
(gdb)
5510          f->new_pixelwise = 0;
(gdb)
5513          if (pixelwise)
(gdb)
5515              new_width = (new_width <= 0) ? FRAME_TEXT_WIDTH (f) : new_width;
(gdb)
5516              new_height = (new_height <= 0) ? FRAME_TEXT_HEIGHT (f) : new_height;
(gdb)
5528          adjust_frame_size (f, new_width, new_height, 5, pretend);
(gdb) p new_width
$1 = 640
(gdb) p new_height
$2 = 560
(gdb) s
adjust_frame_size (f=0x5703b60, new_width=640, new_height=560, inhibit=5,
    pretend=false) at frame.c:390
390       int unit_width = FRAME_COLUMN_WIDTH (f);
(gdb) n
391       int unit_height = FRAME_LINE_HEIGHT (f);
(gdb)
392       int old_pixel_width = FRAME_PIXEL_WIDTH (f);
(gdb)
393       int old_pixel_height = FRAME_PIXEL_HEIGHT (f);
(gdb)
399       int windows_width = FRAME_WINDOWS_WIDTH (f);
(gdb)
400       int windows_height = FRAME_WINDOWS_HEIGHT (f);
(gdb)
403       struct window *r = XWINDOW (FRAME_ROOT_WINDOW (f));
(gdb)
404       int old_windows_width = WINDOW_PIXEL_WIDTH (r);
(gdb)
406         = (WINDOW_PIXEL_HEIGHT (r)
(gdb)
407            + (FRAME_HAS_MINIBUF_P (f)
(gdb)
409               : 0));
(gdb)
407            + (FRAME_HAS_MINIBUF_P (f)
(gdb)
408               ? WINDOW_PIXEL_HEIGHT (XWINDOW (FRAME_MINIBUF_WINDOW (f)))
(gdb)
409               : 0));
(gdb)
405       int old_windows_height
(gdb)
411       int old_text_width = FRAME_TEXT_WIDTH (f);
(gdb)
412       int old_text_height = FRAME_TEXT_HEIGHT (f);
(gdb)
414       int new_text_width = (new_width >= 0) ? new_width : old_text_width;
(gdb)
415       int new_text_height = (new_height >= 0) ? new_height : old_text_height;
(gdb)
420       XSETFRAME (frame, f);
(gdb)
424       min_windows_width = frame_windows_min_size (frame, Qt, Qt);
(gdb)
425       min_windows_height = frame_windows_min_size (frame, Qnil, Qt);
(gdb)
427       if (inhibit >= 2 && inhibit <= 4)
(gdb)
441         inhibit_horizontal = inhibit_vertical = inhibit == 5;
(gdb)
443       new_pixel_width = ((inhibit_horizontal && (inhibit < 5))
(gdb)
445                          : max (FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width),
(gdb)
443       new_pixel_width = ((inhibit_horizontal && (inhibit < 5))
(gdb)
445                          : max (FRAME_TEXT_TO_PIXEL_WIDTH (f, new_text_width),
(gdb)
443       new_pixel_width = ((inhibit_horizontal && (inhibit < 5))
(gdb)
448       new_windows_width = new_pixel_width - 2 * FRAME_INTERNAL_BORDER_WIDTH (f);
(gdb)
449       new_text_width = FRAME_PIXEL_TO_TEXT_WIDTH (f, new_pixel_width);
(gdb)
450       new_cols = new_text_width / unit_width;
(gdb)
452       new_pixel_height = ((inhibit_vertical && (inhibit < 5))
(gdb)
454                           : max (FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height),
(gdb)
452       new_pixel_height = ((inhibit_vertical && (inhibit < 5))
(gdb)
454                           : max (FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height),
(gdb)
452       new_pixel_height = ((inhibit_vertical && (inhibit < 5))
(gdb)
459                             - FRAME_TOP_MARGIN_HEIGHT (f)
(gdb)
460                             - 2 * FRAME_INTERNAL_BORDER_WIDTH (f));
(gdb)
458       new_windows_height = (new_pixel_height
(gdb)
461       new_text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, new_pixel_height);
(gdb)
462       new_lines = new_text_height / unit_height;
(gdb)
465       if (FRAME_WINDOW_P (f)
(gdb)
466           && f->official
(gdb)
467           && ((!inhibit_horizontal
(gdb)
470               || (!inhibit_vertical
(gdb)
491       if (new_text_width == old_text_width
(gdb)
492           && new_text_height == old_text_height
(gdb)
493           && new_windows_width == old_windows_width
(gdb)
494           && new_windows_height == old_windows_height
(gdb)
495           && new_pixel_width == old_pixel_width
(gdb)
496           && new_pixel_height == old_pixel_height)
(gdb)
499           sanitize_window_sizes (frame, Qt);
(gdb) p new_text_height
$3 = 560
(gdb) p old_text_height
$4 = 560
(gdb) p new_text_width
$5 = 640
(gdb) p old_text_width
$6 = 640
(gdb) n
500           sanitize_window_sizes (frame, Qnil);
(gdb)
502           return;
(gdb)
do_pending_window_change (safe=false) at dispnew.c:5481
5481          FOR_EACH_FRAME (tail, frame)
(gdb)
5483              struct frame *f = XFRAME (frame);
(gdb)
5485              if (f->new_height != 0 || f->new_width != 0)
(gdb) p f->new_height
$23 = 0
(gdb) p f->new_width
$24 = 0
(gdb) n
5481          FOR_EACH_FRAME (tail, frame)
(gdb)
5475      while (delayed_size_change)
(gdb)
5490    }
(gdb) n
x_set_window_size (f=0x6feff78, change_gravity=0, width=640, height=560,
    pixelwise=true) at w32term.c:6174
6174    }
(gdb)
adjust_frame_size (f=0x6feff78, new_width=640, new_height=560, inhibit=0,
    pretend=true) at frame.c:485
485           f->resized_p = true;
(gdb)
487           return;
(gdb)
583     }
(gdb)
Fx_create_frame (parameters=117344750) at w32fns.c:4683
4683      block_input ();
(gdb)
4684      x_wm_set_size_hint (f, window_prompting, 0);
(gdb) c
Continuing.

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 > (gdb) break Fx_create_frame
 > Breakpoint 3 at 0x120132f: file w32fns.c, line 4414.
 > (gdb) disable 3
 > (gdb) break Fredraw_display
 > Breakpoint 4 at 0x100805d: file dispnew.c, line 3023.
 > (gdb) r -Q
 > Starting program: d:\usr\eli\emacs\emacs-trunk_2014-09-01\src\emacs.exe -Q
 > Breakpoint 4, Fredraw_display () at dispnew.c:3023
 > 3023      FOR_EACH_FRAME (tail, frame)
 > (gdb) enable 3
 > (gdb) c
 > Continuing.
 > Breakpoint 3, Fx_create_frame (parameters=117344758) at w32fns.c:4414
 > 4414      int minibuffer_only = 0;
 > (gdb) until 4678

Why "until 4678"?  The call where this happens is on line 4609 of
w32fns.c

   adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
		     FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 5, 1);

 > Fx_create_frame (parameters=117344750) at w32fns.c:4678
 > 4678      adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, 1);
 > (gdb) s
 > adjust_frame_size (f=0x6feff78, new_width=640, new_height=560, inhibit=0,
 >     pretend=true) at frame.c:390

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Wed, 10 Sep 2014 21:02:49 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: srivasta@ieee.org, emacs-devel@gnu.org
> 
>  > (gdb) break Fx_create_frame
>  > Breakpoint 3 at 0x120132f: file w32fns.c, line 4414.
>  > (gdb) disable 3
>  > (gdb) break Fredraw_display
>  > Breakpoint 4 at 0x100805d: file dispnew.c, line 3023.
>  > (gdb) r -Q
>  > Starting program: d:\usr\eli\emacs\emacs-trunk_2014-09-01\src\emacs.exe -Q
>  > Breakpoint 4, Fredraw_display () at dispnew.c:3023
>  > 3023      FOR_EACH_FRAME (tail, frame)
>  > (gdb) enable 3
>  > (gdb) c
>  > Continuing.
>  > Breakpoint 3, Fx_create_frame (parameters=117344758) at w32fns.c:4414
>  > 4414      int minibuffer_only = 0;
>  > (gdb) until 4678
> 
> Why "until 4678"?

That's where the call to adjust_frame_size was on Sep 1, which was the
date I took the trunk snapshot where I investigated this.

When I do the same with today's trunk, I indeed see that
adjust_frame_size is called with the 10x10 frame size.  So something
has changed during the last 10 days that caused this difference in
behavior.

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Wed, 10 Sep 2014 22:15:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: srivasta@ieee.org, emacs-devel@gnu.org
> 
> > Why "until 4678"?
> 
> That's where the call to adjust_frame_size was on Sep 1, which was the
> date I took the trunk snapshot where I investigated this.

Err... scratch that.  I entered the wrong call to adjust_frame_size.
Inside the first call to adjust_frame_size, the one from line 4609, we
do call run_window_configuration_change_hook.  But it doesn't abort
here.

If I set a breakpoint in Fface_font, which is what barfed in the OP's
case, the breakpoint doesn't break inside the call to
adjust_frame_size or Fx_create_frame, it breaks after Fx_create_frame
already returned.  I don't know why the difference.

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 > Inside the first call to adjust_frame_size, the one from line 4609, we
 > do call run_window_configuration_change_hook.  But it doesn't abort
 > here.

Because the frame is not official yet so

   if (NILP (Vrun_hooks) || !(f->official))
     return;

will return immediately.

 > If I set a breakpoint in Fface_font, which is what barfed in the OP's
 > case, the breakpoint doesn't break inside the call to
 > adjust_frame_size or Fx_create_frame, it breaks after Fx_create_frame
 > already returned.  I don't know why the difference.

I suppose the OP confused two calls of adjust_frame_size - the one at
line 4609 and the one at line 4678.  The latter indeed does run the
functions on `window-configuration-change-hook' and breaks in
Fface_font.  It doesn't break on Windows or Gtk because there apparently
the sizes do not change any more.  I still don't know why the sizes
change on Motif/Lucid.

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Thu, 11 Sep 2014 11:26:00 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: srivasta@ieee.org, emacs-devel@gnu.org
> 
>  > Inside the first call to adjust_frame_size, the one from line 4609, we
>  > do call run_window_configuration_change_hook.  But it doesn't abort
>  > here.
> 
> Because the frame is not official yet so
> 
>    if (NILP (Vrun_hooks) || !(f->official))
>      return;
> 
> will return immediately.

Right.  Which in retrospect is the _real_ answer to your 'Why "until
4678"?' question: I was trying to reproduce what happened on Manoj's
machine, guided by the backtrace he posted.

>  > If I set a breakpoint in Fface_font, which is what barfed in the OP's
>  > case, the breakpoint doesn't break inside the call to
>  > adjust_frame_size or Fx_create_frame, it breaks after Fx_create_frame
>  > already returned.  I don't know why the difference.
> 
> I suppose the OP confused two calls of adjust_frame_size - the one at
> line 4609 and the one at line 4678.

Or maybe we confused that.

> The latter indeed does run the functions on
> `window-configuration-change-hook' and breaks in Fface_font.  It
> doesn't break on Windows or Gtk because there apparently the sizes
> do not change any more.  I still don't know why the sizes change on
> Motif/Lucid.

Probably because of the tool bar or the scroll bars -- these are the
only differences between the builds, AFAIR.

What will break if we set f->official true only _after_ the second
adjust_frame_size returns?

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 >>   > If I set a breakpoint in Fface_font, which is what barfed in the OP's
 >>   > case, the breakpoint doesn't break inside the call to
 >>   > adjust_frame_size or Fx_create_frame, it breaks after Fx_create_frame
 >>   > already returned.  I don't know why the difference.
 >>
 >> I suppose the OP confused two calls of adjust_frame_size - the one at
 >> line 4609 and the one at line 4678.
 >
 > Or maybe we confused that.

We won't be able to tell but among the values he posted we have an
old_text_width of 10 which is inherently incompatible with a call from
line 4678 and a frame column width of 9.

 > Probably because of the tool bar or the scroll bars -- these are the
 > only differences between the builds, AFAIR.

The tool bar is set before calling x_figure_window_size so I suspect
it's the scroll bar height call which in adjust_frame_size already sets
all values just as the change_frame_size callback triggered by the call
on line 4678 wants them.  This would explain that the hook is _not_
triggered by the call on line 4678.  It doesn't explain why it's
triggered on Motif/Lucid where I basically "do the same thing" (though
apparently I don't).

 > What will break if we set f->official true only _after_ the second
 > adjust_frame_size returns?

Nothing, I presume.  More so, because the fact that the hook is not
triggered on Windows and Gtk, already constitutes a bug which makes the
use of the hook during frame setup impractical on these systems.  Note,
however, that the hook might still trigger any time in between setting
f->official and executing

(face-set-after-frame-default frame parameters)

though currently I can't see how that could happen.

martin

Re: Trunk emacs infelicity with linum mode

[Eli Zaretskii]

> Date: Thu, 11 Sep 2014 18:40:09 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: srivasta@ieee.org, emacs-devel@gnu.org
> 
>  > What will break if we set f->official true only _after_ the second
>  > adjust_frame_size returns?
> 
> Nothing, I presume.  More so, because the fact that the hook is not
> triggered on Windows and Gtk, already constitutes a bug which makes the
> use of the hook during frame setup impractical on these systems.  Note,
> however, that the hook might still trigger any time in between setting
> f->official and executing
> 
> (face-set-after-frame-default frame parameters)
> 
> though currently I can't see how that could happen.

So I suggest that Manoj tries that, and if that solves that problem,
let's install this change on the trunk.

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 >>   > What will break if we set f->official true only _after_ the second
 >>   > adjust_frame_size returns?
 >>
 >> Nothing, I presume.  More so, because the fact that the hook is not
 >> triggered on Windows and Gtk, already constitutes a bug which makes the
 >> use of the hook during frame setup impractical on these systems.  Note,
 >> however, that the hook might still trigger any time in between setting
 >> f->official and executing
 >>
 >> (face-set-after-frame-default frame parameters)
 >>
 >> though currently I can't see how that could happen.
 >
 > So I suggest that Manoj tries that, and if that solves that problem,
 > let's install this change on the trunk.

I just tried and it neither works on Lucid nor on Motif.  Apparently,
the change_frame_size call arrives after exiting Fx_create_frame but
before `face-set-after-frame-default' gets executed.  When I make the
frame official at the end of `x-create-frame-with-faces' it works.  Now
the problem is that making the frame official in
`x-create-frame-with-faces' means that if someone calls Fx_create_frame
from somewhere else, the frame never gets official.

martin

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

> Now
> the problem is that making the frame official in
> `x-create-frame-with-faces' means that if someone calls Fx_create_frame
> from somewhere else, the frame never gets official.

... so I probably have to make the frame official in `make-frame' around
the time we run `after-make-frame-functions'.

martin

Re: Trunk emacs infelicity with linum mode

[Herbert J. Skuhra]

On Tue, 02 Sep 2014 10:22:35 -0700
Manoj Srivastava wrote:

> Hi,
> 
>         To reproduce, on a graphical display:
>  emacs -Q
>  M-x load-library<RET>
>  linum<RET>
>  M-x linum-mode
>  C-x 5 2
> 
>        This results in an error, the contents of the *Messages* buffer
>  is: 
> --8<---------------cut here---------------start------------->8---
> Loading linum...done
> Global-Linum mode enabled
> linum--face-height: Invalid face: linum [3 times]
> Mark set
> --8<---------------cut here---------------end--------------->8---
> 
>         Is anyone else seeing this?

Yes, I do.

Obviously, this error only occurs if Emacs is built with
'--with-x-toolkit=lucid'. I don't get this error with GTK2/GTK3.

No backtrace.

--
Herbert

Re: Trunk emacs infelicity with linum mode

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Wed, Sep 03 2014, Herbert J. Skuhra wrote:

> On Tue, 02 Sep 2014 10:22:35 -0700
> Manoj Srivastava wrote:

>>         To reproduce, on a graphical display:
>>  emacs -Q
>>  M-x load-library<RET>
>>  linum<RET>
>>  M-x linum-mode
>>  C-x 5 2

>>        This results in an error, the contents of the *Messages* buffer
>>  is: 
>> --8<---------------cut here---------------start------------->8---
>> Loading linum...done
>> Global-Linum mode enabled
>> linum--face-height: Invalid face: linum [3 times]
>> Mark set
>> --8<---------------cut here---------------end--------------->8---

>>         Is anyone else seeing this?

> Yes, I do.

> Obviously, this error only occurs if Emacs is built with
> '--with-x-toolkit=lucid'. I don't get this error with GTK2/GTK3.

> No backtrace.

        An additional data point: Merely loading linum,el(c) does tno
 trigger this. You need to have linum mode active in at least one
 buffer, Turning linum mode off make everything work again.

        The reason I am using lucid mode is that a long time ago I read
 that it worked better when emacs starts as a daemon. If that is not the
 case any more, I will happily stop using that option

        manoj
-- 
Look ere ye leap. John Heywood
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 582 bytes --]

Re: Trunk emacs infelicity with linum mode

[martin rudalics]

 > Manoj Srivastava wrote:
 >
 >> Hi,
 >>
 >>          To reproduce, on a graphical display:
 >>   emacs -Q
 >>   M-x load-library<RET>
 >>   linum<RET>
 >>   M-x linum-mode
 >>   C-x 5 2
 >>
 >>         This results in an error, the contents of the *Messages* buffer
 >>   is:
 >> --8<---------------cut here---------------start------------->8---
 >> Loading linum...done
 >> Global-Linum mode enabled
 >> linum--face-height: Invalid face: linum [3 times]
 >> Mark set
 >> --8<---------------cut here---------------end--------------->8---
 >>
 >>          Is anyone else seeing this?
 >
 > Yes, I do.
 >
 > Obviously, this error only occurs if Emacs is built with
 > '--with-x-toolkit=lucid'. I don't get this error with GTK2/GTK3.

Please try again with latest trunk/master.  This should have been fixed
now.

Thanks, martin