From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Trunk emacs infelicity with linum mode Date: Thu, 04 Sep 2014 18:29:13 +0300 Message-ID: <83oauve75i.fsf@gnu.org> References: <87zjeix7hg.fsf@glaurung.internal.golden-gryphon.com> <838um1gar9.fsf@gnu.org> <87ppfdyhpf.fsf@glaurung.internal.golden-gryphon.com> <8361h5g7mv.fsf@gnu.org> <87zjehw5cs.fsf@glaurung.internal.golden-gryphon.com> <834mwog0u0.fsf@gnu.org> <87wq9kd5y3.fsf@glaurung.internal.golden-gryphon.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1409844581 22864 80.91.229.3 (4 Sep 2014 15:29:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 15:29:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Manoj Srivastava Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 04 17:29:34 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPYyb-0002rG-Vw for ged-emacs-devel@m.gmane.org; Thu, 04 Sep 2014 17:29:34 +0200 Original-Received: from localhost ([::1]:51807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPYyb-0000YE-IT for ged-emacs-devel@m.gmane.org; Thu, 04 Sep 2014 11:29:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPYyC-0000QS-1N for emacs-devel@gnu.org; Thu, 04 Sep 2014 11:29:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPYy6-0007H4-5H for emacs-devel@gnu.org; Thu, 04 Sep 2014 11:29:07 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:57167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPYy5-0007Gn-PK for emacs-devel@gnu.org; Thu, 04 Sep 2014 11:29:02 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NBD00L00UWJX000@mtaout29.012.net.il> for emacs-devel@gnu.org; Thu, 04 Sep 2014 18:28:47 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBD00HFYUZZOQ40@mtaout29.012.net.il>; Thu, 04 Sep 2014 18:28:47 +0300 (IDT) In-reply-to: <87wq9kd5y3.fsf@glaurung.internal.golden-gryphon.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174010 Archived-At: > From: Manoj Srivastava > 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=, character=12672242) at xfaces.c:3844 > #5 0x0000000000554fd2 in Ffuncall (nargs=, args=args@entry=0x7fffffffc438) at eval.c:2815 > #6 0x0000000000589bf3 in exec_byte_code (bytestr=, vector=16288805, maxdepth=, > args_template=, nargs=nargs@entry=1, args=, 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=, vector=19151957, maxdepth=, > args_template=, nargs=nargs@entry=1, args=, 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=) 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=, args=args@entry=0x7fffffffc7d0) at eval.c:2811 > #16 0x0000000000589bf3 in exec_byte_code (bytestr=, vector=16288725, maxdepth=, > args_template=, nargs=nargs@entry=1, args=, 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=, vector=16289461, maxdepth=, > args_template=, nargs=nargs@entry=0, args=, 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=, new_height=, > inhibit=, pretend=) at frame.c:582 > #26 0x000000000041e4ce in change_frame_size (pixelwise=, safe=, delay=, > pretend=, new_height=, new_width=, f=) 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=, new_height=, inhibit=0, > pretend=) 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.