On Tue, Jun 02, 2015 at 02:19:56AM +0100, Guillaume M-M wrote: > Le 01/06/2015 23:04, Enrico Forestieri a écrit : > >>You may be right that microtype may have been the reason why I had the > >>impression that latex is slower than pdflatex, but this does not account for > >>the 55s (on a good computer) during which LyX is frozen while generating the > >>16MB tex file. I will run tests again to confirm (and also test the new > >>patch) and will reply to the previous message in a short while. (BTW yes I > >>have epstopdf and pdfcairo.) > > > >Here we are not going anywhere. I say it works well for me, while you say it > >doesn't work. Please, provide an example that generates a 16MB tex file for > >a ~20 page document. > > > > Read again: I am saying that I am running further tests and come back later > with a reply :)
Ok ;) > In fact I am currently having an assertion violation when activating full > instant preview (attached), which prevents me from completing the test. Can > anyone tell me how I get more meaningful symbols? I can try to send a > reproducer but I am a bit short on time to make one right now. (And time is > not pressing, it does not affect stable.) Try using gdb for getting a backtrace after setting a breakpoint at lassert.cpp:53. If this is due to some recent change, you could try bisetting for finding the relevant commit. > >>I am aware that it is less simple than it sounds given that often the user > >>wants to switch to a document class that already has more sensible defaults. > >>I will open an enhancement request if I figure out a solution, but I'd be > >>happy to know whether something like this was already discussed on the list. > > > >Many times... > > In that case, I will NOT open an enhancement request if there is already a > consensus :) (but I did not find any relevant entry in the bug tracker) I don't know whether there is an entry in the bug tracker, but this issue surfaces regularly either here or on the users list. > >>In fact it does not work entirely in master. There is a regression (after > >>bc47054b I believe) because compilation can now fail due to \renewcommandx > >>being used without the command being defined prior to that (try the attached > >>lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit > >>9285f338, it seems.) <http://www.lyx.org/trac/ticket/6369> > >> > >>One quick solution would be to prepend all \renewcommandx\a{b} with > >>\providecommand\a{}. > > > >I think this was already addressed by Jürgen at 83a9ed4e. > > > > For me the bug is still here at cb201027. Try again my file > lyx-bug-renewcommandx.lyx attached to my first message. Strange, I don't see it anymore after 83a9ed4e. -- Enrico
