[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21154: 24.5.50; LaTeX mode complains about mismatched parentheses on

From: Marcin Borkowski
Subject: bug#21154: 24.5.50; LaTeX mode complains about mismatched parentheses on end commands
Date: Fri, 06 May 2016 14:56:50 +0200
User-agent: mu4e 0.9.13; emacs

On 2016-05-02, at 12:32, Marcin Borkowski <address@hidden> wrote:

> On 2016-04-30, at 14:13, Marcin Borkowski <address@hidden> wrote:
>> On 2015-07-28, at 20:43, Jeff Clough <address@hidden> wrote:
>>> When writing LaTeX, typing the closing curly brace of an end
>>> command (\end{document} for instance) causes a "Mismatched parentheses"
>>> complaint to appear in the minibuffer, even when this seems to be false.
>>> Steps to reproduce:
>>> Create a new ".tex" file with the following contents (note the missing
>>> curly brace at the very end...
>>> \documentclass{article}
>>> \begin{document}
>>> \end{document
>>> Watch the minibuffer, type the closing curly brace, and witness the
>>> complaint. The only ever appears to happen on an end command, and it
>>> happens on every single end command no matter where it appears.
>> Confirmed on GNU Emacs (commit a3b46e0).  I'll try to
>> investigate it.
> Here's my conjecture: the problematic message is displayed by
> `blink-matching-open'.  After cursory examination, it seems that the
> problem is caused by the fact that `forward-sexp-function' in tex-mode
> is trying to be smart and jumps to the beginning of the environment when
> after "\end{...}".  Since there is no opening brace there,
> `blink-matching-open' thinks there's a mismatch.
> I'll try to come up with a patch.
> Incidentally, AUC-TeX does not have this problem.

OK, so it seems a tad harder than I thought.  I mean, making a patch
that works is easy; making a patch that works _and_ doesn't break
anything else may be slightly tricky.

My proposal is to temporarily bind `forward-sexp-function' to nil in
`blink-matching-open' so that it finds the opening brace correctly.
(Effectively, making `forward-sexp' fall back to `scan-sexps'.)  Could
anyone imagine a situation where this would break something?  There
doesn't seem to exist a lot of modes in core Emacs which set
`forward-sexp-function' to a non-nil value, so I may just look at all
occurences of that variable in the codebase if that is reasonable.


Marcin Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

reply via email to

[Prev in Thread] Current Thread [Next in Thread]