Hi Arash,
>>>>> Arash Esbati <ar...@gnu.org> writes:
> I had a brief look at the patch. I think the change will not work in a
> .tex file when used like this:
> \graphicspath{{eps/}{tiff/}}
Hmm, is that so? The proposed function `LaTeX-parse-graphicspath'
returns expected result such as
(#("eps/" 0 4 (face (font-lock-function-name-face) fontified t)) #("tiff/" 0 5
(face (font-lock-function-name-face) fontified t)))
for a sample buffer
----------------------------------------------------------------------
\documentclass{article}
\usepackage{graphicx}
\graphicspath{{eps/}{tiff/}}
----------------------------------------------------------------------
.
> From grfguide.pdf:
> A list of directories, each in a {} group (even if there is only one
> in the list). For example:
> \graphicspath{{eps/}{tiff/}}
> would cause the system to look in the subdirectories eps and tiff of
> the current directory.
Yes, and I think the regexps proposed by Leo is constructed in a right
way to parse such a string.
> So the regexp for matching the argument should look like this (or
> something more appropriate):
> "\\\\graphicspath{\\([^}{]*\\(?:{[^}{]*}[^}{]*\\)*\\)}"
It seems that this regexp assumes the form like
\graphicspath{abc{def}ghi{jkl}mno}
. For \graphicspath, we can ignore the elements abc, ghi and mno, can't
we?
> and then the match must be splitted before passing the results to other
> functions.
That's carried out in the second loop
(while (re-search-forward single-path-regex end-pos t)
, isn't it?
> And I would assume that this declaration is usually somewhere in the
> master file, and not used repeatedly.
Thanks.
Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW
