[debbugs-tracker] bug#19281: closed (11.86; environment update fails when environment name contains \)

[GNU bug Tracking System]

Your message dated Fri, 12 Dec 2014 17:41:21 +0100
with message-id <address@hidden>
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
address@hidden)


-- 
19281: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19281
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 11.86; environment update fails when environment name contains \
>
>
>
>
> Date: 
>
> Fri, 05 Dec 2014 17:17:33 +0100
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
>
>
>
>
>
> 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*]*\\)}"
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> 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 <address@hidden>:
> > Mosè Giordano <address@hidden> writes:
> >
> > Hi!
> >
> >> 2014-12-09 10:34 GMT+01:00 Tassilo Horn <address@hidden>:
> >>>> 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è
>
>
> --- End Message ---