Re: Parse graphicspath for searching [

[Ikumi Keita]

Hi Arash,

>>>>> Arash Esbati <arash@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