On Wed, Apr 04, 2018 at 10:33:47AM +0000, Jean-Marc Lasgouttes wrote:
> Le 04/04/2018 à 04:17, Scott Kostyshak a écrit :
> > On Fri, Feb 23, 2018 at 09:42:07AM +0000, Jean-Marc Lasgouttes wrote:
> > 
> > > What refusing to do something if the selection is longer than, say, 50
> > > paragraphs? We could count characters too, of course, but do we want to
> > > transform a full document to a docstring just to be able to decide that it
> > > is too long?
> > 
> > Based on one of your emails in this thread, isn't converting to plain
> > text part of the process of converting to math? In which case, it is not
> > an extra step.
> My idea was to apply an arbitrary limit before converting to string.

Ah I see. So conversion to string can be slow. I was focused on the
conversion of string to math so did not think about that. Makes sense.

> Converting the full User Guide to a string is not a good idea memory-wise.

If I copy the full User Guide and paste into a text editor, it is very
fast. Why would converting to a string be slower?

> My proposal is : only accept to convert up to 10 (or 20, whatever)
> paragraphs.

Sounds like the best proposal. Now we have to think whether this is
worth the work and better than doing nothing. As far as I know, I'm the
only one that came across this issue and I was actually trying to break
LyX if I remember correctly. Nonetheless, I suppose we do not want LyX
to freeze, even in weird situations.

I still wonder if we should also refuse to convert to math if the
selection contains a certain type of inset. e.g. even if just one
paragraph, I don't know if we want to convert a float to math. But I
have no idea what the list of insets would be, so maybe this is actually
not a good idea.

By the way, I wonder why we stopped receiving reports from the author of
that program that would send random keys to LyX (see [1] and [2]).




Attachment: signature.asc
Description: PGP signature

Reply via email to