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  and ). Scott  https://email@example.com/msg152090.html  http://www.lyx.org/trac/query?status=!closed&reporter=gma...@gmail.com
Description: PGP signature