* bug#7053: Reftex is fully broken @ 2010-09-17 9:41 Alpár Jüttner 2010-09-17 11:52 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Alpár Jüttner @ 2010-09-17 9:41 UTC (permalink / raw) To: 7053 Hi, The reftex package seems completely broken in the dev. version. Basically any reftex operation (e.g. table of contents, C-c =) freeze the full emacs. It starts using 100% but doesn't react to any keystroke, (including C-g), the menubar is frozen as well. The frame (X11 window) is refreshed, but I cannot close it by clicking on the "close window". It freezes even without using any explicit command: If I try to type \ref{label:valami} into a buffer, then it will freeze at the next character I press. I use this version: bzr log -r-1 -v ------------------------------------------------------------ revno: 101456 committer: Jan D <jan.h.d@swipnet.se> branch nick: trunk timestamp: Fri 2010-09-17 11:04:35 +0200 message: Expose tool-bar pixel width to lisp and use it for speedbar (Bug#7048) * dframe.el (dframe-reposition-frame-emacs): Use tool-bar-pixel-width in calculating new frame position. Add more space between new and parent on the left. * frame.c (Ftool_bar_pixel_width): New function to expose tool bar's pixel width to Lisp. modified: lisp/ChangeLog lisp/dframe.el src/ChangeLog src/frame.c ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-17 9:41 bug#7053: Reftex is fully broken Alpár Jüttner @ 2010-09-17 11:52 ` Eli Zaretskii 2010-09-17 13:49 ` Alpár Jüttner 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2010-09-17 11:52 UTC (permalink / raw) To: Alpár Jüttner; +Cc: 7053 > From: Alpár Jüttner <alpar@cs.elte.hu> > Date: Fri, 17 Sep 2010 11:41:27 +0200 > Cc: > > The reftex package seems completely broken in the dev. version. > Basically any reftex operation (e.g. table of contents, C-c =) freeze > the full emacs. It starts using 100% but doesn't react to any keystroke, > (including C-g), the menubar is frozen as well. The frame (X11 window) > is refreshed, but I cannot close it by clicking on the "close window". > > It freezes even without using any explicit command: If I try to type > \ref{label:valami} into a buffer, then it will freeze at the next > character I press. Can you run Emacs under GDB, and when it freezes, interrupt it and see where it is stuck? See the advice in etc/DEBUG for how to do that (look for "If Emacs hangs" and "If the symptom of the bug is that Emacs fails to respond"). ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-17 11:52 ` Eli Zaretskii @ 2010-09-17 13:49 ` Alpár Jüttner 2010-09-17 16:20 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Alpár Jüttner @ 2010-09-17 13:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7053 On Fri, 2010-09-17 at 13:52 +0200, Eli Zaretskii wrote: > > From: Alpár Jüttner <alpar@cs.elte.hu> > > Date: Fri, 17 Sep 2010 11:41:27 +0200 > > Cc: > > > > The reftex package seems completely broken in the dev. version. > > Basically any reftex operation (e.g. table of contents, C-c =) freeze > > the full emacs. It starts using 100% but doesn't react to any keystroke, > > (including C-g), the menubar is frozen as well. The frame (X11 window) > > is refreshed, but I cannot close it by clicking on the "close window". > > > > It freezes even without using any explicit command: If I try to type > > \ref{label:valami} into a buffer, then it will freeze at the next > > character I press. > > Can you run Emacs under GDB, and when it freezes, interrupt it and see > where it is stuck? See the advice in etc/DEBUG for how to do that > (look for "If Emacs hangs" and "If the symptom of the bug is that > Emacs fails to respond"). > Here is the GBD trace: (gdb) (gdb) bt #0 Fcdr (list=148598062) at data.c:510 #1 0x08198d03 in Feval (form=148598054) at eval.c:2255 #2 0x0819b9c1 in internal_lisp_condition_case (var=138760618, bodyform= 148598054, handlers=148598366) at eval.c:1407 #3 0x081cfbfd in Fbyte_code (bytestr=147116001, vector=148055397, maxdepth=<value optimized out>) at bytecode.c:869 #4 0x08199603 in funcall_lambda (fun=148055541, nargs=1, arg_vector= 0xbfffcf94) at eval.c:3174 #5 0x08199913 in Ffuncall (nargs=2, args=0xbfffcf90) at eval.c:3047 #6 0x081d0930 in Fbyte_code (bytestr=137143417, vector=137143437, maxdepth=<value optimized out>) at bytecode.c:679 #7 0x08199603 in funcall_lambda (fun=137143389, nargs=1, arg_vector= 0xbfffd0c4) at eval.c:3174 #8 0x08199913 in Ffuncall (nargs=2, args=0xbfffd0c0) at eval.c:3047 #9 0x081d0930 in Fbyte_code (bytestr=137144081, vector=137144109, maxdepth=<value optimized out>) at bytecode.c:679 #10 0x0819911c in Feval (form=137144070) at eval.c:2358 #11 0x0819b9c1 in internal_lisp_condition_case (var=138760618, bodyform= 137144070, handlers=137144134) at eval.c:1407 #12 0x081cfbfd in Fbyte_code (bytestr=137143993, vector=137144013, maxdepth=<value optimized out>) at bytecode.c:869 #13 0x08199603 in funcall_lambda (fun=137143965, nargs=1, arg_vector= 0xbfffd414) at eval.c:3174 ---Type <return> to continue, or q <return> to quit--- #14 0x08199913 in Ffuncall (nargs=2, args=0xbfffd410) at eval.c:3047 #15 0x081d0930 in Fbyte_code (bytestr=147933305, vector=149861133, maxdepth=<value optimized out>) at bytecode.c:679 #16 0x0819911c in Feval (form=150258198) at eval.c:2358 #17 0x0819b9c1 in internal_lisp_condition_case (var=138399914, bodyform= 150258198, handlers=150258150) at eval.c:1407 #18 0x081cfbfd in Fbyte_code (bytestr=147734337, vector=148891933, maxdepth=<value optimized out>) at bytecode.c:869 #19 0x0819911c in Feval (form=150258302) at eval.c:2358 #20 0x0819827a in internal_catch (tag=138515714, func=0x8198c30 <Feval>, arg= 150258302) at eval.c:1204 #21 0x081cfc43 in Fbyte_code (bytestr=147734561, vector=148892109, maxdepth=<value optimized out>) at bytecode.c:854 #22 0x08199603 in funcall_lambda (fun=148892237, nargs=2, arg_vector= 0xbfffd954) at eval.c:3174 #23 0x08199913 in Ffuncall (nargs=3, args=0xbfffd950) at eval.c:3047 #24 0x081d0930 in Fbyte_code (bytestr=147259833, vector=142470477, maxdepth=<value optimized out>) at bytecode.c:679 #25 0x08199603 in funcall_lambda (fun=142524045, nargs=1, arg_vector= 0xbfffda94) at eval.c:3174 #26 0x08199913 in Ffuncall (nargs=2, args=0xbfffda90) at eval.c:3047 #27 0x081d0930 in Fbyte_code (bytestr=147300169, vector=142370285, maxdepth=<value optimized out>) at bytecode.c:679 ---Type <return> to continue, or q <return> to quit--- #28 0x08199603 in funcall_lambda (fun=142370509, nargs=3, arg_vector= 0xbfffdbd4) at eval.c:3174 #29 0x08199913 in Ffuncall (nargs=4, args=0xbfffdbd0) at eval.c:3047 #30 0x081d0930 in Fbyte_code (bytestr=148159265, vector=149389813, maxdepth=<value optimized out>) at bytecode.c:679 #31 0x0819911c in Feval (form=149307686) at eval.c:2358 #32 0x0819827a in internal_catch (tag=138515714, func=0x8198c30 <Feval>, arg= 149307686) at eval.c:1204 #33 0x081cfc43 in Fbyte_code (bytestr=148227393, vector=141171397, maxdepth=<value optimized out>) at bytecode.c:854 #34 0x08199603 in funcall_lambda (fun=141171581, nargs=3, arg_vector= 0xbfffdf24) at eval.c:3174 #35 0x08199913 in Ffuncall (nargs=4, args=0xbfffdf20) at eval.c:3047 #36 0x081d0930 in Fbyte_code (bytestr=148241313, vector=148913701, maxdepth=<value optimized out>) at bytecode.c:679 #37 0x0819911c in Feval (form=149307510) at eval.c:2358 #38 0x0819946f in Fprogn (args=148598062) at eval.c:395 #39 0x0809ed0e in Fsave_window_excursion (args=149307478) at window.c:6471 #40 0x081cfc78 in Fbyte_code (bytestr=148245569, vector=148401309, maxdepth=<value optimized out>) at bytecode.c:840 #41 0x08199603 in funcall_lambda (fun=148406813, nargs=2, arg_vector= 0xbfffe1a4) at eval.c:3174 #42 0x08199913 in Ffuncall (nargs=3, args=0xbfffe1a0) at eval.c:3047 ---Type <return> to continue, or q <return> to quit--- #43 0x081d0930 in Fbyte_code (bytestr=148240937, vector=148406989, maxdepth=<value optimized out>) at bytecode.c:679 #44 0x08199603 in funcall_lambda (fun=148378517, nargs=1, arg_vector= 0xbfffe2d4) at eval.c:3174 #45 0x08199913 in Ffuncall (nargs=2, args=0xbfffe2d0) at eval.c:3047 #46 0x081d0930 in Fbyte_code (bytestr=149365417, vector=150383373, maxdepth=<value optimized out>) at bytecode.c:679 #47 0x08199603 in funcall_lambda (fun=150383845, nargs=0, arg_vector= 0xbfffe444) at eval.c:3174 #48 0x08199913 in Ffuncall (nargs=1, args=0xbfffe440) at eval.c:3047 #49 0x0819b383 in apply1 (fn=148549474, arg=148598062) at eval.c:2756 #50 0x08195637 in Fcall_interactively (function=148549474, record_flag= 138399914, keys=138428093) at callint.c:376 #51 0x08199bdb in Ffuncall (nargs=4, args=0xbfffe5d8) at eval.c:2996 #52 0x08199e01 in call3 (fn=138524954, arg1=148549474, arg2=138399914, arg3= 138399914) at eval.c:2820 #53 0x08139b3d in command_loop_1 () at keyboard.c:1737 #54 0x081981a0 in internal_condition_case (bfun=0x81397b0 <command_loop_1>, handlers=138430898, hfun=0x8134000 <cmd_error>) at eval.c:1460 #55 0x08133c95 in command_loop_2 (ignore=138399914) at keyboard.c:1338 #56 0x0819827a in internal_catch (tag=138428970, func= 0x8133c70 <command_loop_2>, arg=138399914) at eval.c:1204 #57 0x08133e47 in command_loop () at keyboard.c:1317 ---Type <return> to continue, or q <return> to quit--- #58 0x081341db in recursive_edit_1 () at keyboard.c:940 #59 0x08134324 in Frecursive_edit () at keyboard.c:1002 #60 0x08128b12 in main (argc=1, argv=0xbfffecd4) at emacs.c:1708 (gdb) Regards, Alpar ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-17 13:49 ` Alpár Jüttner @ 2010-09-17 16:20 ` Eli Zaretskii 2010-09-18 4:19 ` Alpár Jüttner 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2010-09-17 16:20 UTC (permalink / raw) To: Alpár Jüttner; +Cc: 7053 > From: Alpár Jüttner <alpar@cs.elte.hu> > Cc: 7053@debbugs.gnu.org > Date: Fri, 17 Sep 2010 15:49:48 +0200 > > Here is the GBD trace: Thanks. Unfortunately, this backtrace is not as useful as it could be, because you started GDB not from the src directory of the Emacs tree, and therefore it did not read the .gdbinit file in there. Could you please repeat this, after starting GDB from src? That will produce the Lisp-level backtrace in addition to the C backtrace. Given the large number of Ffuncall and Feval calls in this trace, the Lisp backtrace will make things much more clear. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-17 16:20 ` Eli Zaretskii @ 2010-09-18 4:19 ` Alpár Jüttner 2010-09-18 9:21 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Alpár Jüttner @ 2010-09-18 4:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7053 On Fri, 2010-09-17 at 18:20 +0200, Eli Zaretskii wrote: > > From: Alpár Jüttner <alpar@cs.elte.hu> > > Cc: 7053@debbugs.gnu.org > > Date: Fri, 17 Sep 2010 15:49:48 +0200 > > > > Here is the GBD trace: > > Thanks. Unfortunately, this backtrace is not as useful as it could > be, I'm sorry. Here comes the lisp backtrace (when pressing C-c = ): Lisp Backtrace: "forward-sexp" (0xbfffc9b4) "backward-sexp" (0xbfffcae4) ---Type <return> to continue, or q <return> to quit--- "latex-backward-sexp-1" (0xbfffcc24) "byte-code" (0xbfffccd0) "latex-forward-sexp" (0xbfffcf64) "forward-sexp" (0xbfffd094) "byte-code" (0xbfffd140) "up-list" (0xbfffd3e4) "byte-code" (0xbfffd490) "byte-code" (0xbfffd6b0) "reftex-what-macro" (0xbfffd924) "reftex-label-location" (0xbfffda64) "reftex-label-info" (0xbfffdba4) "byte-code" (0xbfffdc60) "reftex-parse-from-file" (0xbfffdef4) "byte-code" (0xbfffdfa0) "reftex-do-parse" (0xbfffe174) "reftex-access-scan-info" (0xbfffe2a4) "reftex-toc" (0xbfffe414) "call-interactively" (0xbfffe5ac) (gdb) And here is another one (typing \ref{valami}, it also freezes reftex): Lisp Backtrace: "up-list" (0xbfffcea4) "byte-code" (0xbfffcf50) "byte-code" (0xbfffd170) "reftex-what-macro" (0xbfffd3e4) "reftex-what-macro-safe" (0xbfffd514) "reftex-view-crossref" (0xbfffd654) "byte-code" (0xbfffd700) "reftex-view-crossref-when-idle" (0xbfffda48) "apply" (0xbfffda44) "byte-code" (0xbfffdaf0) "timer-event-handler" (0xbfffdd94) (gdb) Regards, Alpar ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-18 4:19 ` Alpár Jüttner @ 2010-09-18 9:21 ` Eli Zaretskii 2010-09-18 14:47 ` Stefan Monnier [not found] ` <83mxrfz9se.fsf@gnu.org> 2 siblings, 0 replies; 16+ messages in thread From: Eli Zaretskii @ 2010-09-18 9:21 UTC (permalink / raw) To: Alpár Jüttner; +Cc: auctex-devel, 7053, Carsten Dominik > From: Alpár Jüttner <alpar@cs.elte.hu> > Cc: 7053@debbugs.gnu.org > Date: Sat, 18 Sep 2010 06:19:31 +0200 > > On Fri, 2010-09-17 at 18:20 +0200, Eli Zaretskii wrote: > > > From: Alpár Jüttner <alpar@cs.elte.hu> > > > Cc: 7053@debbugs.gnu.org > > > Date: Fri, 17 Sep 2010 15:49:48 +0200 > > > > > > Here is the GBD trace: > > > > Thanks. Unfortunately, this backtrace is not as useful as it could > > be, > > > I'm sorry. Here comes the lisp backtrace (when pressing C-c = ): Thanks. It sounds like the problem is in reftex-what-macro. I'm CC'ing the reftex author and maintainers in the hope that they can find the culprit. Failing that, perhaps you could do a "bzr bisect" to find the revision which broke reftex. Thanks. > > Lisp Backtrace: > "forward-sexp" (0xbfffc9b4) > "backward-sexp" (0xbfffcae4) > ---Type <return> to continue, or q <return> to quit--- > "latex-backward-sexp-1" (0xbfffcc24) > "byte-code" (0xbfffccd0) > "latex-forward-sexp" (0xbfffcf64) > "forward-sexp" (0xbfffd094) > "byte-code" (0xbfffd140) > "up-list" (0xbfffd3e4) > "byte-code" (0xbfffd490) > "byte-code" (0xbfffd6b0) > "reftex-what-macro" (0xbfffd924) > "reftex-label-location" (0xbfffda64) > "reftex-label-info" (0xbfffdba4) > "byte-code" (0xbfffdc60) > "reftex-parse-from-file" (0xbfffdef4) > "byte-code" (0xbfffdfa0) > "reftex-do-parse" (0xbfffe174) > "reftex-access-scan-info" (0xbfffe2a4) > "reftex-toc" (0xbfffe414) > "call-interactively" (0xbfffe5ac) > (gdb) > > And here is another one (typing \ref{valami}, it also freezes reftex): > > Lisp Backtrace: > "up-list" (0xbfffcea4) > "byte-code" (0xbfffcf50) > "byte-code" (0xbfffd170) > "reftex-what-macro" (0xbfffd3e4) > "reftex-what-macro-safe" (0xbfffd514) > "reftex-view-crossref" (0xbfffd654) > "byte-code" (0xbfffd700) > "reftex-view-crossref-when-idle" (0xbfffda48) > "apply" (0xbfffda44) > "byte-code" (0xbfffdaf0) > "timer-event-handler" (0xbfffdd94) > (gdb) > > Regards, > Alpar > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-18 4:19 ` Alpár Jüttner 2010-09-18 9:21 ` Eli Zaretskii @ 2010-09-18 14:47 ` Stefan Monnier 2010-09-19 5:34 ` Alpár Jüttner [not found] ` <83mxrfz9se.fsf@gnu.org> 2 siblings, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2010-09-18 14:47 UTC (permalink / raw) To: Alpár Jüttner; +Cc: 7053, Carsten Dominik > I'm sorry. Here comes the lisp backtrace (when pressing C-c = ): > Lisp Backtrace: > "forward-sexp" (0xbfffc9b4) > "backward-sexp" (0xbfffcae4) > ---Type <return> to continue, or q <return> to quit--- > "latex-backward-sexp-1" (0xbfffcc24) > "byte-code" (0xbfffccd0) > "latex-forward-sexp" (0xbfffcf64) > "forward-sexp" (0xbfffd094) > "byte-code" (0xbfffd140) > "up-list" (0xbfffd3e4) > "byte-code" (0xbfffd490) > "byte-code" (0xbfffd6b0) > "reftex-what-macro" (0xbfffd924) > "reftex-label-location" (0xbfffda64) > "reftex-label-info" (0xbfffdba4) > "byte-code" (0xbfffdc60) > "reftex-parse-from-file" (0xbfffdef4) > "byte-code" (0xbfffdfa0) > "reftex-do-parse" (0xbfffe174) > "reftex-access-scan-info" (0xbfffe2a4) > "reftex-toc" (0xbfffe414) > "call-interactively" (0xbfffe5ac) > (gdb) Can you try the patch below, to see if it fixes your problem? Stefan === modified file 'lisp/textmodes/reftex-parse.el' --- lisp/textmodes/reftex-parse.el 2010-08-29 22:13:49 +0000 +++ lisp/textmodes/reftex-parse.el 2010-09-18 14:45:39 +0000 @@ -778,13 +778,15 @@ (narrow-to-region (max (point-min) bound) (point-max)) ;; move back out of the current parenthesis (while (condition-case nil - (progn (up-list -1) t) + (let ((forward-sexp-function nil)) + (up-list -1) t) (error nil)) (setq cnt 1 cnt-opt 0) ;; move back over any touching sexps (while (and (reftex-move-to-previous-arg bound) (condition-case nil - (progn (backward-sexp) t) + (let ((forward-sexp-function nil)) + (backward-sexp) t) (error nil))) (if (eq (following-char) ?\[) (incf cnt-opt)) (incf cnt)) @@ -973,7 +975,7 @@ (min (+ (point) 150) (point-max) (condition-case nil - (progn + (let ((forward-sexp-function nil)) (up-list 1) (1- (point))) (error (point-max)))))) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-18 14:47 ` Stefan Monnier @ 2010-09-19 5:34 ` Alpár Jüttner 0 siblings, 0 replies; 16+ messages in thread From: Alpár Jüttner @ 2010-09-19 5:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: 7053, Carsten Dominik > Can you try the patch below, to see if it fixes your problem? Yes, it works fine with the patch. Many thanks for it. How will I see when it goes to the bzr repo? (I try not to pull until it happens). Regards, Alpar > > > Stefan > > > === modified file 'lisp/textmodes/reftex-parse.el' > --- lisp/textmodes/reftex-parse.el 2010-08-29 22:13:49 +0000 > +++ lisp/textmodes/reftex-parse.el 2010-09-18 14:45:39 +0000 > @@ -778,13 +778,15 @@ > (narrow-to-region (max (point-min) bound) (point-max)) > ;; move back out of the current parenthesis > (while (condition-case nil > - (progn (up-list -1) t) > + (let ((forward-sexp-function nil)) > + (up-list -1) t) > (error nil)) > (setq cnt 1 cnt-opt 0) > ;; move back over any touching sexps > (while (and (reftex-move-to-previous-arg bound) > (condition-case nil > - (progn (backward-sexp) t) > + (let ((forward-sexp-function nil)) > + (backward-sexp) t) > (error nil))) > (if (eq (following-char) ?\[) (incf cnt-opt)) > (incf cnt)) > @@ -973,7 +975,7 @@ > (min (+ (point) 150) > (point-max) > (condition-case nil > - (progn > + (let ((forward-sexp-function nil)) > (up-list 1) > (1- (point))) > (error (point-max)))))) > ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <83mxrfz9se.fsf@gnu.org>]
* bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken [not found] ` <83mxrfz9se.fsf@gnu.org> @ 2010-09-18 15:16 ` Ralf Angeli [not found] ` <87vd635bfi.fsf@caeruleus.net> 2010-09-19 5:24 ` Alpár Jüttner 2 siblings, 0 replies; 16+ messages in thread From: Ralf Angeli @ 2010-09-18 15:16 UTC (permalink / raw) To: Eli Zaretskii Cc: auctex-devel, 7053, Alpár Jüttner, Carsten Dominik * Eli Zaretskii (2010-09-18) writes: > Thanks. It sounds like the problem is in reftex-what-macro. I'm > CC'ing the reftex author and maintainers in the hope that they can > find the culprit. Since I've never gotten commit access to the Emacs repository I haven't bothered to follow the switch to Bazaar. It might take a while to make myself acquainted with it. And unfortunately I failed to find a web interface to the current Emacs sources in order to find out if somebody has changed the RefTeX files, or in which way. At the moment I can only say that the RefTeX version maintained in the AUCTeX repository is working fine with a one year old development version of Emacs, but that likely doesn't help much. (c: -- Ralf ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <87vd635bfi.fsf@caeruleus.net>]
* bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken [not found] ` <87vd635bfi.fsf@caeruleus.net> @ 2010-09-18 16:11 ` Stefan Monnier [not found] ` <jwv62y39gts.fsf-monnier+emacs@gnu.org> 1 sibling, 0 replies; 16+ messages in thread From: Stefan Monnier @ 2010-09-18 16:11 UTC (permalink / raw) To: Ralf Angeli; +Cc: auctex-devel, 7053, Carsten, Alpár Jüttner, Dominik > Since I've never gotten commit access to the Emacs repository I haven't That should be easy to fix. Get a Savannah account, and from there, ask for membership to the Emacs group. > bothered to follow the switch to Bazaar. It might take a while to make > myself acquainted with it. And unfortunately I failed to find a web > interface to the current Emacs sources in order to find out if somebody > has changed the RefTeX files, or in which way. I suspect the change is not in the reftex file but in the behavior of up-list which now obeys forward-sexp-function, which means that under latex-mode, it will now move from \begin{foo} >here< \end{foo} to just before the \begin. So if the reftex code does not expect that (and/or for performance reason doesn't want that), it should protect against it by binding forward-sexp-function around calls to up-list and friends. Stefan ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <jwv62y39gts.fsf-monnier+emacs@gnu.org>]
* bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken [not found] ` <jwv62y39gts.fsf-monnier+emacs@gnu.org> @ 2010-09-18 16:28 ` Ralf Angeli 2010-09-19 8:48 ` Andreas Röhler 2010-09-20 23:40 ` Stefan Monnier 2 siblings, 0 replies; 16+ messages in thread From: Ralf Angeli @ 2010-09-18 16:28 UTC (permalink / raw) To: Stefan Monnier Cc: auctex-devel, 7053, Carsten, Alpár Jüttner, Dominik * Stefan Monnier (2010-09-18) writes: >> Since I've never gotten commit access to the Emacs repository I haven't > > That should be easy to fix. Get a Savannah account, and from there, ask > for membership to the Emacs group. Um, I've been having a Savannah account since 2003 because AUCTeX is also maintained on Savannah. Whom do I have to ask for a membership to the Emacs group? > I suspect the change is not in the reftex file but in the behavior of > up-list which now obeys forward-sexp-function, which means that under > latex-mode, it will now move from > > \begin{foo} > >here< > \end{foo} > > to just before the \begin. So if the reftex code does not expect that > (and/or for performance reason doesn't want that), it should protect > against it by binding forward-sexp-function around calls to up-list > and friends. So that means the upcoming Emacs release will break the externally maintained version of RefTeX? AUCTeX also uses `up-list' at a few occasions (it's even bound to a key for AUCTeX users), so I'll have to check if the respective functions will be broken by the changes in Emacs as well. -- Ralf ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken [not found] ` <jwv62y39gts.fsf-monnier+emacs@gnu.org> 2010-09-18 16:28 ` Ralf Angeli @ 2010-09-19 8:48 ` Andreas Röhler 2010-09-20 23:40 ` Stefan Monnier 2 siblings, 0 replies; 16+ messages in thread From: Andreas Röhler @ 2010-09-19 8:48 UTC (permalink / raw) To: bug-gnu-emacs; +Cc: Stefan Monnier Am 18.09.2010 18:11, schrieb Stefan Monnier: >> Since I've never gotten commit access to the Emacs repository I haven't > > That should be easy to fix. Get a Savannah account, and from there, ask > for membership to the Emacs group. > >> bothered to follow the switch to Bazaar. It might take a while to make >> myself acquainted with it. And unfortunately I failed to find a web >> interface to the current Emacs sources in order to find out if somebody >> has changed the RefTeX files, or in which way. > > I suspect the change is not in the reftex file but in the behavior of > up-list which now obeys forward-sexp-function, if thats a case, a lot of code will be broken. Suggest to revert this change. Both forms differ considerable from the users view BTW. While the list handling code is easy to grasp and looks well defined, the sexp-grammar with its "balanced expression" even after years sounds arcane for me. forward-list etc. also have been reliable to deal with in coding, sexp... not that much Please keep the lisp-list-functions. Thanks Andreas which means that under > latex-mode, it will now move from > > \begin{foo} > >here< > \end{foo} > > to just before the \begin. So if the reftex code does not expect that > (and/or for performance reason doesn't want that), it should protect > against it by binding forward-sexp-function around calls to up-list > and friends. > > > Stefan > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken [not found] ` <jwv62y39gts.fsf-monnier+emacs@gnu.org> 2010-09-18 16:28 ` Ralf Angeli 2010-09-19 8:48 ` Andreas Röhler @ 2010-09-20 23:40 ` Stefan Monnier 2 siblings, 0 replies; 16+ messages in thread From: Stefan Monnier @ 2010-09-20 23:40 UTC (permalink / raw) To: Ralf Angeli; +Cc: auctex-devel, Alpár Jüttner, Carsten Dominik >> bothered to follow the switch to Bazaar. It might take a while to make >> myself acquainted with it. And unfortunately I failed to find a web >> interface to the current Emacs sources in order to find out if somebody >> has changed the RefTeX files, or in which way. > I suspect the change is not in the reftex file but in the behavior of > up-list which now obeys forward-sexp-function, which means that under > latex-mode, it will now move from > \begin{foo} >> here< > \end{foo} > to just before the \begin. So if the reftex code does not expect that > (and/or for performance reason doesn't want that), it should protect > against it by binding forward-sexp-function around calls to up-list > and friends. I think in the end, the core reason for the problem was a bug in the new up-list code (it just silently did nothing when reaching BOB), which I've just fixed. I also additionally installed the patch below which circumvents the bug and also avoids slowing things down unnecessarily. Stefan === modified file 'lisp/ChangeLog' --- lisp/ChangeLog 2010-09-20 21:45:09 +0000 +++ lisp/ChangeLog 2010-09-20 22:35:46 +0000 @@ -1,5 +1,9 @@ 2010-09-20 Stefan Monnier <monnier@iro.umontreal.ca> + * textmodes/reftex-parse.el (reftex-what-macro) + (reftex-context-substring): Let-bind forward-sexp-function to nil + since we don't need/want to treat \begin...\end as a block. + * emacs-lisp/lisp.el (up-list): Don't do nothing silently. * simple.el (blink-matching-open): Use syntax-class. === modified file 'lisp/textmodes/reftex-parse.el' --- lisp/textmodes/reftex-parse.el 2010-09-20 13:27:59 +0000 +++ lisp/textmodes/reftex-parse.el 2010-09-20 22:35:33 +0000 @@ -385,7 +385,7 @@ (defun reftex-section-info (file) ;; Return a section entry for the current match. - ;; Carefull: This function expects the match-data to be still in place! + ;; Careful: This function expects the match-data to be still in place! (let* ((marker (set-marker (make-marker) (1- (match-beginning 3)))) (macro (reftex-match-string 3)) (prefix (save-match-data @@ -778,13 +778,15 @@ (narrow-to-region (max (point-min) bound) (point-max)) ;; move back out of the current parenthesis (while (condition-case nil - (progn (up-list -1) t) + (let ((forward-sexp-function nil)) + (up-list -1) t) (error nil)) (setq cnt 1 cnt-opt 0) ;; move back over any touching sexps (while (and (reftex-move-to-previous-arg bound) (condition-case nil - (progn (backward-sexp) t) + (let ((forward-sexp-function nil)) + (backward-sexp) t) (error nil))) (if (eq (following-char) ?\[) (incf cnt-opt)) (incf cnt)) @@ -965,15 +967,14 @@ (if (re-search-forward "\\\\end{" nil t) (match-beginning 0) (point-max)))))) - ((or (= (preceding-char) ?\{) - (= (preceding-char) ?\[)) + ((memq (preceding-char) '(?\{ ?\[)) ;; Inside a list - get only the list. (buffer-substring-no-properties (point) (min (+ (point) 150) (point-max) (condition-case nil - (progn + (let ((forward-sexp-function nil)) ;Unneeded fanciness. (up-list 1) (1- (point))) (error (point-max)))))) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken [not found] ` <83mxrfz9se.fsf@gnu.org> 2010-09-18 15:16 ` bug#7053: [AUCTeX-devel] " Ralf Angeli [not found] ` <87vd635bfi.fsf@caeruleus.net> @ 2010-09-19 5:24 ` Alpár Jüttner 2010-09-19 5:58 ` Eli Zaretskii [not found] ` <E1OxCvN-0001nb-Jl@fencepost.gnu.org> 2 siblings, 2 replies; 16+ messages in thread From: Alpár Jüttner @ 2010-09-19 5:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: auctex-devel, 7053, Carsten Dominik > Thanks. It sounds like the problem is in reftex-what-macro. I'm > CC'ing the reftex author and maintainers in the hope that they can > find the culprit. > > Failing that, perhaps you could do a "bzr bisect" to find the revision > which broke reftex. I try to avoid to do it as far as I can. I'm a big fan of distributed version control systems. I use hg in several project with grate success and satisfaction. I people have also very good experience with git. But bzr is so much pain to use. A 'bzr pull' triggers tens of MB net traffic every time (and takes long minutes), operations that are instantaneous on hg/git takes ages here (log, update, status, diff). I simply can't understand why emacs chose bzr. Regards, Alpar > > Thanks. > > > > > Lisp Backtrace: > > "forward-sexp" (0xbfffc9b4) > > "backward-sexp" (0xbfffcae4) > > ---Type <return> to continue, or q <return> to quit--- > > "latex-backward-sexp-1" (0xbfffcc24) > > "byte-code" (0xbfffccd0) > > "latex-forward-sexp" (0xbfffcf64) > > "forward-sexp" (0xbfffd094) > > "byte-code" (0xbfffd140) > > "up-list" (0xbfffd3e4) > > "byte-code" (0xbfffd490) > > "byte-code" (0xbfffd6b0) > > "reftex-what-macro" (0xbfffd924) > > "reftex-label-location" (0xbfffda64) > > "reftex-label-info" (0xbfffdba4) > > "byte-code" (0xbfffdc60) > > "reftex-parse-from-file" (0xbfffdef4) > > "byte-code" (0xbfffdfa0) > > "reftex-do-parse" (0xbfffe174) > > "reftex-access-scan-info" (0xbfffe2a4) > > "reftex-toc" (0xbfffe414) > > "call-interactively" (0xbfffe5ac) > > (gdb) > > > > And here is another one (typing \ref{valami}, it also freezes reftex): > > > > Lisp Backtrace: > > "up-list" (0xbfffcea4) > > "byte-code" (0xbfffcf50) > > "byte-code" (0xbfffd170) > > "reftex-what-macro" (0xbfffd3e4) > > "reftex-what-macro-safe" (0xbfffd514) > > "reftex-view-crossref" (0xbfffd654) > > "byte-code" (0xbfffd700) > > "reftex-view-crossref-when-idle" (0xbfffda48) > > "apply" (0xbfffda44) > > "byte-code" (0xbfffdaf0) > > "timer-event-handler" (0xbfffdd94) > > (gdb) > > > > Regards, > > Alpar > > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7053: Reftex is fully broken 2010-09-19 5:24 ` Alpár Jüttner @ 2010-09-19 5:58 ` Eli Zaretskii [not found] ` <E1OxCvN-0001nb-Jl@fencepost.gnu.org> 1 sibling, 0 replies; 16+ messages in thread From: Eli Zaretskii @ 2010-09-19 5:58 UTC (permalink / raw) To: Alpár Jüttner; +Cc: auctex-devel, 7053, dominik > From: Alpár Jüttner <alpar@cs.elte.hu> > Cc: 7053@debbugs.gnu.org, Carsten Dominik <dominik@science.uva.nl>, > auctex-devel@gnu.org > Date: Sun, 19 Sep 2010 07:24:13 +0200 > > > Failing that, perhaps you could do a "bzr bisect" to find the revision > > which broke reftex. > > I try to avoid to do it as far as I can. I'm a big fan of distributed > version control systems. I use hg in several project with grate success > and satisfaction. I people have also very good experience with git. > > But bzr is so much pain to use. A 'bzr pull' triggers tens of MB net > traffic every time (and takes long minutes), operations that are > instantaneous on hg/git takes ages here (log, update, status, diff). If you have a bzr repository on your machine, then "bzr bisect" is a local operation that doesn't involve any network traffic or negotiation with the remote repository. So there's no reason not to use "bzr bisect". ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <E1OxCvN-0001nb-Jl@fencepost.gnu.org>]
* bug#7053: Reftex is fully broken [not found] ` <E1OxCvN-0001nb-Jl@fencepost.gnu.org> @ 2010-09-19 6:42 ` Alpár Jüttner 0 siblings, 0 replies; 16+ messages in thread From: Alpár Jüttner @ 2010-09-19 6:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: auctex-devel, 7053, dominik > > I try to avoid to do it as far as I can. I'm a big fan of distributed > > version control systems. I use hg in several project with grate success > > and satisfaction. I people have also very good experience with git. > > > > But bzr is so much pain to use. A 'bzr pull' triggers tens of MB net > > traffic every time (and takes long minutes), operations that are > > instantaneous on hg/git takes ages here (log, update, status, diff). > > If you have a bzr repository on your machine, then "bzr bisect" is a > local operation that doesn't involve any network traffic or > negotiation with the remote repository. I know that. I meant I try to use bzr for nothing else that is absolute necessary to get the latest dev version. > So there's no reason not to > use "bzr bisect". I feel there are many good reasons not to use bzr at all. There are much better alternatives. But it is very off topic here, so please forget about my enthusiastic expression of my dissatisfaction with bzr. Sorry for the noise. Regards, Alpar ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2010-09-20 23:40 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-17 9:41 bug#7053: Reftex is fully broken Alpár Jüttner 2010-09-17 11:52 ` Eli Zaretskii 2010-09-17 13:49 ` Alpár Jüttner 2010-09-17 16:20 ` Eli Zaretskii 2010-09-18 4:19 ` Alpár Jüttner 2010-09-18 9:21 ` Eli Zaretskii 2010-09-18 14:47 ` Stefan Monnier 2010-09-19 5:34 ` Alpár Jüttner [not found] ` <83mxrfz9se.fsf@gnu.org> 2010-09-18 15:16 ` bug#7053: [AUCTeX-devel] " Ralf Angeli [not found] ` <87vd635bfi.fsf@caeruleus.net> 2010-09-18 16:11 ` Stefan Monnier [not found] ` <jwv62y39gts.fsf-monnier+emacs@gnu.org> 2010-09-18 16:28 ` Ralf Angeli 2010-09-19 8:48 ` Andreas Röhler 2010-09-20 23:40 ` Stefan Monnier 2010-09-19 5:24 ` Alpár Jüttner 2010-09-19 5:58 ` Eli Zaretskii [not found] ` <E1OxCvN-0001nb-Jl@fencepost.gnu.org> 2010-09-19 6:42 ` Alpár Jüttner
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).