GNU bug report logs - #19281
11.86; environment update fails when environment name contains \

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mosè Giordano <mose <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#19281: closed (11.86; environment update fails when
 environment name contains \)
Date: Fri, 12 Dec 2014 16:43:03 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 12 Dec 2014 17:41:21 +0100
with message-id <CAKtYQqRkOR5qTMVtvXfF0XUojyvv5bYSFwbr62hLt+9mzc7RtQ <at> mail.gmail.com>
and subject line Re: bug#19281: 11.86; environment update fails when environment name contains \
has caused the debbugs.gnu.org bug report #19281,
regarding 11.86; environment update fails when environment name contains \
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
19281: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19281
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Manuel Sorge <manuel.sorge <at> tu-berlin.de>
To: bug-auctex <at> gnu.org
Subject: 11.86; environment update fails when environment name contains \
Date: Fri, 05 Dec 2014 17:17:33 +0100

I tried to update an environment in a latex document via C-u C-c C-e or 
LaTeX-modify-environment but mistyped the name as 'theorem\'. I tried to 
correct my error via C-u C-c C-e again but I got a search failed message:

LaTeX-modify-environment: Search failed: "\\\\end{ *\\([a-zA-Z*]*\\)}"

[Message part 3 (message/rfc822, inline)]

From: Mosè Giordano <mose <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: Manuel Sorge <manuel.sorge <at> tu-berlin.de>, 19281-done <at> debbugs.gnu.org
Subject: Re: bug#19281: 11.86; environment update fails when environment name
 contains \
Date: Fri, 12 Dec 2014 17:41:21 +0100

Hi Tassilo,

2014-12-10 8:38 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
> Mosè Giordano <mose <at> gnu.org> writes:
>
> Hi!
>
>> 2014-12-09 10:34 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
>>>> Or matching everything between the opening and the closing brace
>>>> (allowing at least one level of braces)?
>>>
>>> Either that, or we could also rely on syntax tables.  I.e., since
>>> `LaTeX-find-matching-end' already brings us to the end of the
>>> environment name,
>>>
>>>   (let ((end (point)))
>>>     (forward-char)
>>>     (backward-sexp)
>>>     (forward-char)
>>>     (buffer-substring-no-properties (point) end))
>>>
>>> gives us the environment name.
>>
>> Good idea, except that `LaTeX-find-matching-end' fails to find the
>> closing brace of \end when the environment name is a macro with
>> arguments.
>
> Ah, indeed.  During my testing it always stopped at
> \end{\whatever{foo}|} with | being point, so I assumed that's where it's
> supposed to stop, i.e., right after the environment name, not right
> after the environment.
>
> I guess it's better to also test the simple cases, not only the complex
> ones. ;-)
>
>> The attached patch should fix this problem.
>> `LaTeX-environment-name-regexp' needs to be a function because if it
>> were a variable it would always keep the original value, also in
>> buffers with different values for `TeX-grop' and `TeX-grcl' (or not?).
>
> Correct.  Well, it could also be a variable that's initialized in
> `LaTeX-common-initialization' or so after a call to
> `hack-local-variables' to apply file local variables first.  But IMO
> it's better to have it as a function.
>
>> Probably `LaTeX-modify-environment' can be simplified following your
>> suggestion,
>
> On a second thought, the syntax-table approach will fail in case the
> environment name is something unbalanced like \foo[{] which is unlikely
> but possible.  So better stick to the regexp-search.
>
>> the patch sketches an idea how to fix `LaTeX-find-matching-end', but
>> can be improved.
>
> Looks good to me.

Ok, thanks, patch installed.

Bye,
Mosè

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.