From: Eli Zaretskii <eliz@gnu.org>
To: Manoj Srivastava <srivasta@ieee.org>
Cc: emacs-devel@gnu.org
Subject: Re: Trunk emacs infelicity with linum mode
Date: Thu, 04 Sep 2014 18:29:13 +0300 [thread overview]
Message-ID: <83oauve75i.fsf@gnu.org> (raw)
In-Reply-To: <87wq9kd5y3.fsf@glaurung.internal.golden-gryphon.com>
> 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.
next prev parent reply other threads:[~2014-09-04 15:29 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 17:22 Trunk emacs infelicity with linum mode Manoj Srivastava
2014-09-02 18:03 ` Eli Zaretskii
2014-09-02 18:56 ` Manoj Srivastava
2014-09-02 19:11 ` Eli Zaretskii
2014-09-03 7:06 ` Manoj Srivastava
2014-09-03 15:50 ` Eli Zaretskii
2014-09-03 16:28 ` Manoj Srivastava
2014-09-04 15:29 ` Eli Zaretskii [this message]
2014-09-04 15:56 ` Stefan Monnier
2014-09-04 18:37 ` Eli Zaretskii
2014-09-04 20:25 ` Stefan Monnier
2014-09-05 6:58 ` Eli Zaretskii
2014-09-05 15:23 ` Stefan Monnier
2014-09-05 15:32 ` Eli Zaretskii
2014-09-05 16:23 ` Stefan Monnier
2014-09-05 17:49 ` Eli Zaretskii
2014-09-06 1:19 ` Manoj Srivastava
2014-09-06 7:43 ` Eli Zaretskii
2014-09-06 15:23 ` Manoj Srivastava
2014-09-06 20:27 ` Stefan Monnier
2014-09-07 5:07 ` Manoj Srivastava
2014-09-08 0:28 ` Stefan Monnier
2014-09-05 18:48 ` Manoj Srivastava
2014-09-05 19:53 ` Eli Zaretskii
2014-09-06 8:52 ` martin rudalics
2014-09-06 11:18 ` martin rudalics
2014-09-07 15:24 ` Eli Zaretskii
2014-09-07 18:03 ` martin rudalics
2014-09-07 19:28 ` Eli Zaretskii
2014-09-08 9:31 ` martin rudalics
2014-09-07 18:09 ` martin rudalics
2014-09-07 19:34 ` Eli Zaretskii
2014-09-08 9:32 ` martin rudalics
2014-09-09 13:13 ` Eli Zaretskii
2014-09-10 8:03 ` martin rudalics
2014-09-10 17:39 ` Eli Zaretskii
2014-09-10 19:02 ` martin rudalics
2014-09-10 19:15 ` Eli Zaretskii
2014-09-10 19:25 ` Eli Zaretskii
2014-09-11 9:26 ` martin rudalics
2014-09-11 15:14 ` Eli Zaretskii
2014-09-11 16:40 ` martin rudalics
2014-09-11 16:53 ` Eli Zaretskii
2014-09-11 17:59 ` martin rudalics
2014-09-11 18:09 ` martin rudalics
2014-09-03 12:37 ` Herbert J. Skuhra
2014-09-03 15:31 ` Manoj Srivastava
2015-01-04 18:09 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83oauve75i.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=srivasta@ieee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.