* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
@ 2015-01-10 11:43 martin rudalics
2015-01-10 12:17 ` Eli Zaretskii
2015-01-12 17:34 ` martin rudalics
0 siblings, 2 replies; 17+ messages in thread
From: martin rudalics @ 2015-01-10 11:43 UTC (permalink / raw
To: 19554
With today's trunk/master and _my init files_ I currently see the
following problem. After coming up with the initial frame and hitting
C-x 5 2 I get
Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
(xref-marker-stack-empty-p)
(not (xref-marker-stack-empty-p))
x-create-frame(((visibility) (bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (tool-bar-lines . 0)))
x-create-frame-with-faces(((bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (cursor-color . "red3") (tool-bar-lines . 0)))
make-frame()
make-frame-command()
funcall-interactively(make-frame-command)
call-interactively(make-frame-command nil nil)
command-execute(make-frame-command)
and no frame is created. I leave the Backtrace open and do C-x 5 2.
Now a new frame is created. If I now do C-x C-c Emacs decides to die as
follows.
Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:352
352 signal (sig, SIG_DFL);
(gdb) bt
#0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:352
#1 0x0118363a in die (msg=0x14c1575 "glyph_matrix_count == 0", file=0x14c10dc "dispnew.c", line=2260) at alloc.c:7138
#2 0x0100693b in check_glyph_memory () at dispnew.c:2260
#3 0x01108c7c in shut_down_emacs (sig=0, stuff=...) at emacs.c:2004
#4 0x01108b4a in Fkill_emacs (arg=...) at emacs.c:1917
#5 0x011a4211 in Ffuncall (nargs=1, args=0x82c588) at eval.c:2707
#6 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82c8f0) at bytecode.c:919
#7 0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82c8ec) at eval.c:2874
#8 0x011a442f in Ffuncall (nargs=2, args=0x82c8e8) at eval.c:2756
#9 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82cd1c) at bytecode.c:919
#10 0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82cd18) at eval.c:2874
#11 0x011a442f in Ffuncall (nargs=2, args=0x82cd14) at eval.c:2756
#12 0x0119b17c in Ffuncall_interactively (nargs=2, args=0x82cd14) at callint.c:258
#13 0x011a40fe in Ffuncall (nargs=3, args=0x82cd10) at eval.c:2687
#14 0x0119d379 in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:864
#15 0x011a4266 in Ffuncall (nargs=4, args=0x82cfbc) at eval.c:2714
#16 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82d320) at bytecode.c:919
#17 0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82d31c) at eval.c:2874
#18 0x011a442f in Ffuncall (nargs=2, args=0x82d318) at eval.c:2756
#19 0x011a3d07 in call1 (fn=..., arg1=...) at eval.c:2560
#20 0x0110badd in command_loop_1 () at keyboard.c:1518
#21 0x011a0cea in internal_condition_case (bfun=0x110b29b <command_loop_1>, handlers=..., hfun=0x110a987 <cmd_error>) at eval.c:1334
#22 0x0110aecd in command_loop_2 (ignore=...) at keyboard.c:1139
#23 0x011a0220 in internal_catch (tag=..., func=0x110aea2 <command_loop_2>, arg=...) at eval.c:1095
#24 0x0110adf8 in command_loop () at keyboard.c:1110
#25 0x0110a4e5 in recursive_edit_1 () at keyboard.c:728
#26 0x0110a6d9 in Frecursive_edit () at keyboard.c:799
#27 0x011a41f4 in Ffuncall (nargs=1, args=0x82d650) at eval.c:2704
#28 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x82d9b4) at bytecode.c:919
#29 0x011a4a73 in funcall_lambda (fun=..., nargs=2, arg_vector=0x82d9b4) at eval.c:2874
#30 0x011a442f in Ffuncall (nargs=3, args=0x82d9b0) at eval.c:2756
#31 0x011a36e1 in Fapply (nargs=2, args=0x82da48) at eval.c:2323
#32 0x011a3cc1 in apply1 (fn=..., arg=...) at eval.c:2544
#33 0x0119de08 in call_debugger (arg=...) at eval.c:309
#34 0x011a1b0b in maybe_call_debugger (conditions=..., sig=..., data=...) at eval.c:1712
#35 0x011a139d in Fsignal (error_symbol=..., data=...) at eval.c:1530
#36 0x011a14b9 in xsignal (error_symbol=..., data=...) at eval.c:1567
#37 0x011a14ff in xsignal1 (error_symbol=..., arg=...) at eval.c:1582
#38 0x011a2ff1 in eval_sub (form=...) at eval.c:2216
#39 0x011a2d18 in eval_sub (form=...) at eval.c:2153
#40 0x011a25dd in Feval (form=..., lexical=...) at eval.c:1982
#41 0x01118cf8 in eval_dyn (form=...) at keyboard.c:7642
#42 0x011a0e08 in internal_condition_case_1 (bfun=0x1118cd7 <eval_dyn>, arg=..., handlers=..., hfun=0x1118c41 <menu_item_eval_property_1>) at eval.c:1358
#43 0x01118d5a in menu_item_eval_property (sexpr=...) at keyboard.c:7653
#44 0x01119665 in parse_menu_item (item=..., inmenubar=0) at keyboard.c:7762
#45 0x01087dff in single_menu_item (key=..., item=..., dummy=..., skp_v=0x82e004) at menu.c:334
#46 0x01123e27 in map_keymap_item (fun=0x1087dda <single_menu_item>, args=..., key=..., val=..., data=0x82e004) at keymap.c:560
#47 0x01124118 in map_keymap_internal (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e004) at keymap.c:599
#48 0x01124492 in map_keymap_canonical (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e004) at keymap.c:662
#49 0x01087c57 in single_keymap_panes (keymap=..., pane_name=..., prefix=..., maxdepth=9) at menu.c:300
#50 0x01088450 in single_menu_item (key=..., item=..., dummy=..., skp_v=0x82e1f4) at menu.c:443
#51 0x01123e27 in map_keymap_item (fun=0x1087dda <single_menu_item>, args=..., key=..., val=..., data=0x82e1f4) at keymap.c:560
#52 0x01124118 in map_keymap_internal (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e1f4) at keymap.c:599
#53 0x01124492 in map_keymap_canonical (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e1f4) at keymap.c:662
#54 0x01087c57 in single_keymap_panes (keymap=..., pane_name=..., prefix=..., maxdepth=10) at menu.c:300
#55 0x01088b55 in parse_single_submenu (item_key=..., item_name=..., maps=...) at menu.c:572
#56 0x012277b1 in set_frame_menubar (f=0x5a64788, first_time=true, deep_p=true) at w32menu.c:366
#57 0x01227c6e in initialize_frame_menubar (f=0x5a64788) at w32menu.c:522
#58 0x0121d6e4 in w32_window (f=0x5a64788, window_prompting=0, minibuffer_only=0) at w32fns.c:4237
#59 0x0121ece7 in Fx_create_frame (parameters=...) at w32fns.c:4659
#60 0x011a4211 in Ffuncall (nargs=2, args=0x82e794) at eval.c:2707
#61 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:919
#62 0x011a4eb0 in funcall_lambda (fun=..., nargs=1, arg_vector=0x12dc1cd) at eval.c:2940
#63 0x011a442f in Ffuncall (nargs=2, args=0x82eafc) at eval.c:2756
#64 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x82ee68) at bytecode.c:919
#65 0x011a4a73 in funcall_lambda (fun=..., nargs=0, arg_vector=0x82ee68) at eval.c:2874
#66 0x011a442f in Ffuncall (nargs=1, args=0x82ee64) at eval.c:2756
#67 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x82f35c) at bytecode.c:919
#68 0x011a4a73 in funcall_lambda (fun=..., nargs=0, arg_vector=0x82f35c) at eval.c:2874
#69 0x011a442f in Ffuncall (nargs=1, args=0x82f358) at eval.c:2756
#70 0x0119b17c in Ffuncall_interactively (nargs=1, args=0x82f358) at callint.c:258
#71 0x011a40fe in Ffuncall (nargs=2, args=0x82f354) at eval.c:2687
#72 0x011a3294 in Fapply (nargs=3, args=0x82f354) at eval.c:2275
#73 0x0119b60d in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:404
#74 0x011a4266 in Ffuncall (nargs=4, args=0x82f53c) at eval.c:2714
#75 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82f8a0) at bytecode.c:919
#76 0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82f89c) at eval.c:2874
#77 0x011a442f in Ffuncall (nargs=2, args=0x82f898) at eval.c:2756
#78 0x011a3d07 in call1 (fn=..., arg1=...) at eval.c:2560
#79 0x0110badd in command_loop_1 () at keyboard.c:1518
#80 0x011a0cea in internal_condition_case (bfun=0x110b29b <command_loop_1>, handlers=..., hfun=0x110a987 <cmd_error>) at eval.c:1334
#81 0x0110aecd in command_loop_2 (ignore=...) at keyboard.c:1139
#82 0x011a0220 in internal_catch (tag=..., func=0x110aea2 <command_loop_2>, arg=...) at eval.c:1095
#83 0x0110ae72 in command_loop () at keyboard.c:1118
#84 0x0110a4e5 in recursive_edit_1 () at keyboard.c:728
#85 0x0110a6d9 in Frecursive_edit () at keyboard.c:799
#86 0x0110857f in main (argc=1, argv=0xa32858) at emacs.c:1612
Lisp Backtrace:
Attempt to extract a component of a value that is not a structure.
(gdb)
Adding (require 'xref) to my .emacs solves the problem.
In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
of 2015-01-10 on MACHNO
Repository revision: c2208b3d913c2e53b96d7f11b31422a57366f601
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --prefix=/c/emacs-git/trunk --enable-checking=yes
--enable-check-lisp-object-type=yes 'CFLAGS=-O0 -g3'
CPPFLAGS=-DGLYPH_DEBUG=1'
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-10 11:43 bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort martin rudalics
@ 2015-01-10 12:17 ` Eli Zaretskii
2015-01-10 13:33 ` martin rudalics
2015-01-12 17:34 ` martin rudalics
1 sibling, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2015-01-10 12:17 UTC (permalink / raw
To: martin rudalics; +Cc: 19554
> Date: Sat, 10 Jan 2015 12:43:44 +0100
> From: martin rudalics <rudalics@gmx.at>
>
> With today's trunk/master and _my init files_ I currently see the
> following problem. After coming up with the initial frame and hitting
> C-x 5 2 I get
>
> Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
> (xref-marker-stack-empty-p)
> (not (xref-marker-stack-empty-p))
> x-create-frame(((visibility) (bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (tool-bar-lines . 0)))
> x-create-frame-with-faces(((bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (cursor-color . "red3") (tool-bar-lines . 0)))
> make-frame()
> make-frame-command()
> funcall-interactively(make-frame-command)
> call-interactively(make-frame-command nil nil)
> command-execute(make-frame-command)
>
> and no frame is created. I leave the Backtrace open and do C-x 5 2.
> Now a new frame is created. If I now do C-x C-c Emacs decides to die as
> follows.
>
> Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:352
> 352 signal (sig, SIG_DFL);
> (gdb) bt
> #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:352
> #1 0x0118363a in die (msg=0x14c1575 "glyph_matrix_count == 0", file=0x14c10dc "dispnew.c", line=2260) at alloc.c:7138
> #2 0x0100693b in check_glyph_memory () at dispnew.c:2260
Calling the Lisp debugger in some sensitive place during creating a
frame is known to cause this. If you can track this down and see
why we increment the reference count of the new frame where we
shouldn't, or declare the frame "official" too soon, perhaps this can
be fixed. But it's a low-priority issue, because this assertion
disappears in an optimized binary anyway. The main problem to tackle
is why do you get a Lisp error in this scenario -- that's the real
problem to fix.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-10 12:17 ` Eli Zaretskii
@ 2015-01-10 13:33 ` martin rudalics
2015-01-12 8:01 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2015-01-10 13:33 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 19554
> Calling the Lisp debugger in some sensitive place during creating a
> frame is known to cause this. If you can track this down and see
> why we increment the reference count of the new frame where we
> shouldn't, or declare the frame "official" too soon, perhaps this can
> be fixed. But it's a low-priority issue, because this assertion
> disappears in an optimized binary anyway.
I suppose it's the same as bug#10296 then.
> The main problem to tackle
> is why do you get a Lisp error in this scenario -- that's the real
> problem to fix.
Indeed. Another clue might be that when I try to access the menu bar
with the mouse I get
Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
(xref-marker-stack-empty-p)
(not (xref-marker-stack-empty-p))
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-10 13:33 ` martin rudalics
@ 2015-01-12 8:01 ` martin rudalics
2015-01-12 16:12 ` Eli Zaretskii
2015-01-13 3:00 ` Dmitry Gutov
0 siblings, 2 replies; 17+ messages in thread
From: martin rudalics @ 2015-01-12 8:01 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 19554
A simpler scenario: With emacs -Q I evaluate
(let ((params '((height . 25))))
(make-frame params) ;; f1
(modify-frame-parameters (make-frame) params)) ;; f2
in *scratch*. Gets me the now familiar
Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
(xref-marker-stack-empty-p)
(not (xref-marker-stack-empty-p))
x-create-frame(((visibility) (height . 25)))
x-create-frame-with-faces(((height . 25)))
make-frame(((height . 25)))
(let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params))
eval((let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params)) nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 8:01 ` martin rudalics
@ 2015-01-12 16:12 ` Eli Zaretskii
2015-01-12 16:35 ` martin rudalics
2015-01-13 3:00 ` Dmitry Gutov
1 sibling, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2015-01-12 16:12 UTC (permalink / raw
To: martin rudalics; +Cc: 19554
> Date: Mon, 12 Jan 2015 09:01:22 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19554@debbugs.gnu.org
>
> A simpler scenario: With emacs -Q I evaluate
>
> (let ((params '((height . 25))))
> (make-frame params) ;; f1
> (modify-frame-parameters (make-frame) params)) ;; f2
>
> in *scratch*. Gets me the now familiar
>
> Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
> (xref-marker-stack-empty-p)
> (not (xref-marker-stack-empty-p))
> x-create-frame(((visibility) (height . 25)))
> x-create-frame-with-faces(((height . 25)))
> make-frame(((height . 25)))
> (let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params))
> eval((let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params)) nil)
> elisp--eval-last-sexp(nil)
> eval-last-sexp(nil)
> funcall-interactively(eval-last-sexp nil)
> call-interactively(eval-last-sexp nil nil)
> command-execute(eval-last-sexp)
Doesn't happen to me here with the current master.
Could it be that you have stale *.elc files that need to be
recompiled?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 16:12 ` Eli Zaretskii
@ 2015-01-12 16:35 ` martin rudalics
2015-01-12 16:48 ` Dmitry Gutov
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2015-01-12 16:35 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 19554
> Doesn't happen to me here with the current master.
I understand that meanwhile.
> Could it be that you have stale *.elc files that need to be
> recompiled?
Might be, but where? I spent an hour boostrapping yesterday after make
distclean and the oldest .elc file in my entire trunk is cconv.elc.
I also don't have the slightest idea where `xref-marker-stack-empty-p'
could get called from.
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 16:35 ` martin rudalics
@ 2015-01-12 16:48 ` Dmitry Gutov
2015-01-12 17:06 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2015-01-12 16:48 UTC (permalink / raw
To: martin rudalics, Eli Zaretskii; +Cc: 19554
On 01/12/2015 07:35 PM, martin rudalics wrote:
> I also don't have the slightest idea where `xref-marker-stack-empty-p'
> could get called from.
It's called from lisp/menu-bar.el:384 (find-grep call could have told
you that, too).
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 16:48 ` Dmitry Gutov
@ 2015-01-12 17:06 ` martin rudalics
2015-01-12 17:21 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2015-01-12 17:06 UTC (permalink / raw
To: Dmitry Gutov, Eli Zaretskii; +Cc: 19554
>> I also don't have the slightest idea where `xref-marker-stack-empty-p'
>> could get called from.
>
> It's called from lisp/menu-bar.el:384 (find-grep call could have told you that, too).
Hmmm... indeed. No idea why I never found it. So maybe it's a missing
;;;###autoload
before the definition of `xref-marker-stack-empty-p'?
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 17:06 ` martin rudalics
@ 2015-01-12 17:21 ` Eli Zaretskii
2015-01-12 17:31 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2015-01-12 17:21 UTC (permalink / raw
To: martin rudalics; +Cc: dgutov, 19554
> Date: Mon, 12 Jan 2015 18:06:01 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19554@debbugs.gnu.org
>
> >> I also don't have the slightest idea where `xref-marker-stack-empty-p'
> >> could get called from.
> >
> > It's called from lisp/menu-bar.el:384 (find-grep call could have told you that, too).
>
> Hmmm... indeed. No idea why I never found it. So maybe it's a missing
>
> ;;;###autoload
>
> before the definition of `xref-marker-stack-empty-p'?
Try
$ make -C lisp autoloads && make
and see if that helps.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 17:21 ` Eli Zaretskii
@ 2015-01-12 17:31 ` martin rudalics
2015-01-12 18:14 ` Glenn Morris
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2015-01-12 17:31 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dgutov, 19554
>> Hmmm... indeed. No idea why I never found it. So maybe it's a missing
>>
>> ;;;###autoload
>>
>> before the definition of `xref-marker-stack-empty-p'?
>
> Try
>
> $ make -C lisp autoloads && make
>
> and see if that helps.
I added an autoload cookie now. If someone has an idea why it would be
_not_ needed please tell me so. Meanwhile closing this bug.
Thanks, martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-10 11:43 bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort martin rudalics
2015-01-10 12:17 ` Eli Zaretskii
@ 2015-01-12 17:34 ` martin rudalics
1 sibling, 0 replies; 17+ messages in thread
From: martin rudalics @ 2015-01-12 17:34 UTC (permalink / raw
To: 19554-done
> With today's trunk/master and _my init files_ I currently see the
> following problem. After coming up with the initial frame and hitting
> C-x 5 2 I get
>
> Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
> (xref-marker-stack-empty-p)
> (not (xref-marker-stack-empty-p))
> x-create-frame(((visibility) (bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (tool-bar-lines . 0)))
> x-create-frame-with-faces(((bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (cursor-color . "red3") (tool-bar-lines . 0)))
> make-frame()
> make-frame-command()
> funcall-interactively(make-frame-command)
> call-interactively(make-frame-command nil nil)
> command-execute(make-frame-command)
>
> and no frame is created.
This part fixed in commit e946a9a..cc59a3e. Bug closed.
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 17:31 ` martin rudalics
@ 2015-01-12 18:14 ` Glenn Morris
2015-01-13 3:06 ` Dmitry Gutov
0 siblings, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2015-01-12 18:14 UTC (permalink / raw
To: martin rudalics; +Cc: dgutov, 19554
martin rudalics wrote:
> I added an autoload cookie now. If someone has an idea why it would be
> _not_ needed please tell me so.
I suggest instead
:visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
to avoid needless autoloading.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 8:01 ` martin rudalics
2015-01-12 16:12 ` Eli Zaretskii
@ 2015-01-13 3:00 ` Dmitry Gutov
1 sibling, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2015-01-13 3:00 UTC (permalink / raw
To: martin rudalics, Eli Zaretskii; +Cc: 19554
On 01/12/2015 11:01 AM, martin rudalics wrote:
> A simpler scenario: With emacs -Q I evaluate
>
> (let ((params '((height . 25))))
> (make-frame params) ;; f1
> (modify-frame-parameters (make-frame) params)) ;; f2
On my machine, that still doesn't raise an error. Could it be that menu
items swallow errors with some toolkits, such as GTK3?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-12 18:14 ` Glenn Morris
@ 2015-01-13 3:06 ` Dmitry Gutov
2015-01-13 15:21 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2015-01-13 3:06 UTC (permalink / raw
To: Glenn Morris, martin rudalics; +Cc: 19554
On 01/12/2015 09:14 PM, Glenn Morris wrote:
> I suggest instead
>
> :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
>
> to avoid needless autoloading.
The autoload won't hurt in other uses, but this indeed looks like a
better solution to me. Installed.
If we're going to force autoloading of xref, we could as well preload it.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-13 3:06 ` Dmitry Gutov
@ 2015-01-13 15:21 ` Stefan Monnier
2015-01-13 21:21 ` Glenn Morris
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2015-01-13 15:21 UTC (permalink / raw
To: Dmitry Gutov; +Cc: 19554
>> :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
It's generally better to use (and (fboundp 'xref-marker-stack-empty-p)
(not (xref-marker-stack-empty-p))). E.g. the compiler understands it
(tho in this case, the compiler doesn't see this code anyway).
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-13 15:21 ` Stefan Monnier
@ 2015-01-13 21:21 ` Glenn Morris
2015-01-14 17:59 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2015-01-13 21:21 UTC (permalink / raw
To: Stefan Monnier; +Cc: Dmitry Gutov, 19554
Stefan Monnier wrote:
>>> :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
>
> It's generally better to use (and (fboundp 'xref-marker-stack-empty-p)
> (not (xref-marker-stack-empty-p))). E.g. the compiler understands it
> (tho in this case, the compiler doesn't see this code anyway).
But autoloaded-but-not-yet-loaded functions are fboundp,
so it isn't the same.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort
2015-01-13 21:21 ` Glenn Morris
@ 2015-01-14 17:59 ` Stefan Monnier
0 siblings, 0 replies; 17+ messages in thread
From: Stefan Monnier @ 2015-01-14 17:59 UTC (permalink / raw
To: Glenn Morris; +Cc: Dmitry Gutov, 19554
>>>> :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
>> It's generally better to use (and (fboundp 'xref-marker-stack-empty-p)
>> (not (xref-marker-stack-empty-p))). E.g. the compiler understands it
>> (tho in this case, the compiler doesn't see this code anyway).
> But autoloaded-but-not-yet-loaded functions are fboundp,
> so it isn't the same.
Duh! Right! Thanks for the reminder,
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-01-14 17:59 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-10 11:43 bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort martin rudalics
2015-01-10 12:17 ` Eli Zaretskii
2015-01-10 13:33 ` martin rudalics
2015-01-12 8:01 ` martin rudalics
2015-01-12 16:12 ` Eli Zaretskii
2015-01-12 16:35 ` martin rudalics
2015-01-12 16:48 ` Dmitry Gutov
2015-01-12 17:06 ` martin rudalics
2015-01-12 17:21 ` Eli Zaretskii
2015-01-12 17:31 ` martin rudalics
2015-01-12 18:14 ` Glenn Morris
2015-01-13 3:06 ` Dmitry Gutov
2015-01-13 15:21 ` Stefan Monnier
2015-01-13 21:21 ` Glenn Morris
2015-01-14 17:59 ` Stefan Monnier
2015-01-13 3:00 ` Dmitry Gutov
2015-01-12 17:34 ` martin rudalics
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.