[Top][All Lists]

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

Re: [AUCTeX] Listing and not listing regions inverted if `\begin{lstlist

From: Denis Bitouzé
Subject: Re: [AUCTeX] Listing and not listing regions inverted if `\begin{lstlisting}' not followed by what is expected
Date: Thu, 09 Apr 2015 17:59:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Hi Tassilo,

sorry for the delay...

Le 23/03/15 à 13h53, Tassilo Horn <address@hidden> a écrit :

> Denis Bitouzé <address@hidden> writes:
>> Wouldn't it be possible for `\end{...}' to never be considered as the
>> /beginning/ of `...' environment?
> No, actually syntactic font-lock has no notion of beginning or end.

Bad news! But good news: I'm smarter than AUCTeX! ;)

> Basically, what AUCTeX' font-latex does is telling emacs that the
> contents of verbatim environments are a kind of string which should be
> highlighted using the verbatim face.  For that purpose, it has to tell
> emacs where the "quotes" (delimiters) of that string are.  For that,
> there's the "generic string fence" syntax class (|).  As an example,
> in
> \begin{lstlisting}
> foo bar
> \end{lstlisting}
> the newline character after \begin{lstlisting} and the \ of
> \end{lstlisting} have that |-syntax.  When the emacs encounters a char
> with that syntax, it *toggles* string highlighting.

If I understand well, emacs knows:

- \begin{lstlisting} is the opening,
- \ of \end{lstlisting} is the closing,

"quote". Isn't it a kind of beginning or end notion?

> But that's just the simple case.  Many verbatim environments support
> arguments which must start on the same line as the \begin{env} but
> which may span many lines, e.g.,
> \begin{lstlisting}[o1=x,
>                    o2=y]
> foo bar
> \end{lstlisting}
> \begin{minted}[o1=x,
>                o2=y]{language}
> foo bar
> \end{minted}
> Of course, in these cases, the arguments shouldn't be fontified in the
> verbatim face.  Therefore, the corresponding regular expression matches
> \begin{<verbenv>} followed by optional and mandatory arguments, and the
> char after the arguments gets the |-syntax.  But since it only skips
> over arguments which are either enclosed in [] or {}, your example line
>   \begin{lstlisting}+\only<2->{+[+\emph{options}+]+}+
> is not recognized as something toggeling verbatim.  I think, that's
> actually correct because
> \begin{lstlisting}foobar
> \end{lstlisting}
> is invalid, i.e., prints nothing.

I see.

> So long story short: I think we can get either argument highlighting
> right or we can get nested verbatim environments right but not both.
> And since your use-case, i.e., documenting how to use verbatim
> environments, is the only one which requires nested verbatim
> environments, I think the current implementation which fontifies
> arguments correctly, is more useful for the majority of users.


>> Meanwhile, is it possible to stop a listing region highlight with some
>> (magic) comments?
> Yes, but not so easily.  You have to remove "lstlisting" from the
> verbatim environments and then re-initiate font-locking.  You can do so
> by writing a custom listings style and placing that in style/listings.el
> (that path is relative to your master file; don't replace the existing
> listings.el that ships with AUCTeX).
> (TeX-add-style-hook
>  "listings"
>  (lambda ()
>    (setq LaTeX-verbatim-environments-local
>          (remove "lstlisting" LaTeX-verbatim-environments-local))
>    (font-latex-set-syntactic-keywords)
>    (setq font-lock-set-defaults nil)
>    (font-lock-set-defaults)))
> However, you need the current Git master for that to work.  Until the
> last commit, AUCTeX would have called your custom style hook before the
> style hook that ships with AUCTeX.  Now I do that in reversed order, so
> a local (or private) listings.el style runs after the global listings.el
> style and may undo what the former did like we do.

OK, thanks. Unfortunately, I've no time for such test right now. But,
when a new AUCTeX release will be available, I'll give feedback.

Many thanks!

reply via email to

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