On 07/03/14 05:11, aparsloe wrote:
> This is belated but I find myself intrigued by your description of
> the underlying process involving latex export and searching the
> strings resulting from that. Did you consider exporting to LyX's own
> native format? That would remove one level of processing (translating
> LyX into LaTeX and back). And for tasks like replacing one
> mathematical symbol by another, I think it would align more closely
> with what a user wants. At present, a symbol can be replaced in all
> inline formulas, then as a separate task in all display formulas,
> then as a further find-&-replace in all numbered formulas, then as
> yet further tasks in all the separate AMS environments. Using LyX's
> native format means all these searches can be combined into just the
> one, finding-&-replacing what is between "\begin_inset Formula",
> "\end_inset" pairs.
>
> I hasten to add that I know no C++. This question is spurred by my
> efforts at writing a (find-&-)replace script for the pLyX system.
Hi Andrew,
thanks for the interesting thoughts. What probably you're missing, is the
fact that the internal representation of a LyX document in memory is not
much related to how it shows up in the .lyx text file. In memory, we have
basically an in-memory tree of items pointing to other items,
representing the various insets with all of their capabilities and options
available as integers, enumerate types, strings, and whatever else is needed.
So, exporting an in-memory lyx document to the lyx format (as needed simply
when saving) is barely equivalent, in terms of processing, to exporting it
into the latex format.
However, there's an interesting difference: there are things normally
exported in .lyx that don't get necessarily exported to latex, notably LyX
notes (and I can't remember right now whether Advanced F&R works within LyX
notes -- should check). In other words, being the .lyx format the only one
that is guaranteed to be 100% serializable and deserializable without any
content losses, I'd say it is well possible to base a search function on
the .lyx export of text segments -- the principle keeps being the same,
and it has more chances to catch every possible lyx construct/feature.
Thanks,
T.
