After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781538 - LaTeX: \includegraphics not correctly highlighted
LaTeX: \includegraphics not correctly highlighted
Status: RESOLVED FIXED
Product: gtksourceview
Classification: Platform
Component: Syntax files
3.24.x
Other Linux
: Normal normal
: ---
Assigned To: GTK Sourceview maintainers
GTK Sourceview maintainers
Depends on:
Blocks:
 
 
Reported: 2017-04-20 14:14 UTC by Sébastien Wilmet
Modified: 2017-04-23 10:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sébastien Wilmet 2017-04-20 14:14:38 UTC
For example in this LaTeX text:

=====
\begin{figure}
  \begin{center}
    \includegraphics[scale=0.75]{images/weak-ref.pdf}
    \caption{Using a weak reference to break the reference cycle between A and B.}
    \label{oop-gobject-weak-ref-schema}
  \end{center}
\end{figure}
=====

\includegraphics is not correctly highlighted, only "\include" is highlighted (which is another LaTeX command). \includegraphics must have a higher priority than \include.
Comment 1 Carnë Draug 2017-04-22 18:27:25 UTC
The problem is not the priority of the commands, the problem is in the regexs. Even though \include matches before \includegraphics, it shouldn't have matched in the first place because \include command cannot be followed by a 'g' (for graphics).

The problem was that the include type of commands, like include and input, did not check for word boundary and add optional followed by brackets.  Fixed with https://git.gnome.org/browse/gtksourceview/commit/data/language-specs/latex.lang?id=0b165ce682ae30d217973eef3fe206c63586d2b6

Seems like the optional brackets were added to avoid spell check of filepaths https://git.gnome.org/browse/gtksourceview/commit/data/language-specs/latex.lang?id=db21302a7281c9eef72da8172c9262c44bb829c6 but isn't there a better way of doing that?
Comment 2 Sébastien Wilmet 2017-04-23 10:25:48 UTC
I confirm that this bug is fixed, thanks for the commit!

I haven't really thought on how to handle better the no-spell-check. There are lots of commands where what is inside the [] or {} should not be spell-checked.