bug#7053: Reftex is fully broken

bug#7053: Reftex is fully broken

[Alpár Jüttner]

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

bug#7053: Reftex is fully broken

[Eli Zaretskii]

> 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").

bug#7053: Reftex is fully broken

[Alpár Jüttner]

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

bug#7053: Reftex is fully broken

[Eli Zaretskii]

> 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.

bug#7053: Reftex is fully broken

[Alpár Jüttner]

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

bug#7053: Reftex is fully broken

[Eli Zaretskii]

> 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
> 
> 

bug#7053: Reftex is fully broken

[Stefan Monnier]

> 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))))))

bug#7053: Reftex is fully broken

[Alpár Jüttner]

> 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))))))
> 

bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken

[Ralf Angeli]

* 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

bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken

[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, 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

bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken

[Ralf Angeli]

* 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

bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken

[Andreas Röhler]

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
>
>
>
>

bug#7053: [AUCTeX-devel] Re: bug#7053: Reftex is fully broken

[Stefan Monnier]

>> 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))))))

bug#7053: Reftex is fully broken

[Alpár Jüttner]

> 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
> > 
> > 
> 

bug#7053: Reftex is fully broken

[Eli Zaretskii]

> 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".

bug#7053: Reftex is fully broken

[Alpár Jüttner]

> > 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