Am Sonntag, 7. April 2013 um 01:36:52, schrieb Tommaso Cucinotta 
<[email protected]>
> So,
> 
> I came up with this trivial patch for the kind of scenario you proposed. 
> Simply,
> export an regexp inset using the text, rather than math, "encoding" rules.
> AFAICS, one might usefully be willing to write text (and special chars) in a
> regexp context.

For normal text it is wonderful :).

> However, it's not conclusive, nor can it be.
> 
> Imagine I write the word you were mentioning (použiť) both as regular text in
> a document, AND within a math inset.

Writing as textrm inside math, this new algorithm finds the text. Previously it 
was not the case.

If I uncheck 'ignore format', then I cannot find any (regular or not) string 
now :(. (With or without non-ascii).
But the behaviour seems undefined. The next time I tried to search,
with a string (copy & paste), it could find the string (iff all ascci).
More test on this confused me even more.
I could not see any regularity when the string will be found and when not.

And not ignoring format is still slow. 

> Then, I search for it through Advanced Find.
> 
> If I enter the word as simple text in the Find box, then it finds only the 
> text
> counter-part in the document, but it cannot match the math one. If I enter the
> word in math mode, then it's the other way round. If I enter the word in 
> regexp
> mode, then I match one or the other depending on whether you applied my 
> attached
> patch :-).
> 
> Now, such a behaviour might have been OK for Ignore Format unchecked, but it
> happens when it's checked as well, and it shouldn't happen.
> 
> This is probably one of the many other Advanced Find scenarios that can be
> addressed by modifying the export/write/latex logic introducing a special
> export mode that carries along the matching options, and lets insets export
> what makes sense and is appropriate considering them, rather than trying to
> fix the situation through impossible regexp post-processing after the export
> (the current implementation is very fragile, if one tries to search for
> "{{{", or "\regexp", or a combination of them, or similar, I don't know what
> can happen). Such a focused export for advanced F&R should also speed up
> tremendously the operation.
> 
> comments ?
> 
>        T.

I think, own export format would be best. 

        Kornel

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to