From: Tim H. <hof...@hi...> - 2012-05-03 22:50:13
|
> Von: Benito van der Zander [mailto:be...@be...] > Gesendet: Donnerstag, 3. Mai 2012 23:13 > > It may even become insignificant in the future, when all viewers > detect the file changes > > automatically. > > You probably still need to call "view" to bring the viewer in the foreground Not, if your screen is large enough. If the viewer auto-updates, the advantage of not calling view is that TXS does not lose focus. So I think there are use-cases for both options with and without view. > >I'd suggest that plain compile calls like txs:///compile > >or txs:///pdflatex or ... should just run once. They are "low level". Only > >the build commands should (optionally) yield this "all-inclusive" stuff. > > I don't think so. > > If someone explicitely calls the compile command, he does so, because he > wants to compile a document that needs a specific latex compiler and he > doesn't want to switch the default compiler for it. > Then he still wants to repeat latex, until he has a complete document, > without missing things. No. Maybe I just want to see, if the file compiles without errors. Then I'm not interested in correct labels, but it should go fast. Therefore I strongly suggest, that it should be possible to execute single compiler calls without the need to switch off something in the build options. When one wants to make a full build with another compiler, one should use another build chain. If you think it's to cumbersome to go to the options to change it. We should add a way of selection of the chain to the menu. Anyway using two different compilers is already a bit more advanced. As a standard solution I'd suggest that the user should set up an own build/quick via user commands, for this case. > And if beginners just use F6/7 to explicitely run pdflatex, they will > just wonder, why the labels have been replaced by [?]. That's exactly what an more experienced latex user would expect (see the recent questions on multiple compiler runs). Probably sooner or later a beginner would have to learn it anyway. To reduce the danger of confusion let's put all the compilers in a "Compiler" submenu. Only the Build/Quick/Chain/whatever-we-call-the-intelligent-process should stay at the top level of the menu. > Although, txs should probably never rerun latexmk. True. > > ps-build = latex | dvips > > dvi-build = latex > > pdf-build = pdflatex > > dvi-pdf-build = latex | dvipdf > > dvi-ps-pdf-build = latex | dvips | pspdf > > asy-dvi-build = latex | asy | latex > > asy-pdf-build = pdflatex | asy |pdflatex > > > > Remove quick completely and replace its menu entry by "Build and View", > > which calls build + view > > (As pointed out by Matthias, it's not really quicker). It may even become > > insignificant in the future, when all viewers detect the file changes > > automatically. > > If the viewer is part of the command like in "quick", you can switch between > working on a dvi or a pdf, by changing just one option. Only partly. You can change the quick-build and use that. But the default viewer is not changed, so you end up with an inconsistent setting there. As a result then just calling "View" may fail (or you would also need to change the viewer. > With build you would need to change the build and the viewer option... You could introduce txs:///view-auto which selects the viewer depending on the file output format of the build process (check which compiler or converter would be called last). > >automatically use a precompiled preamble, > > This already done for the inline preview. > (although the preview is not fully integrated in the new build system) Ah, interesting. > I think we could remove that menu completely and put the user tags > somewhere else (LaTeX/Edit or Idefix). > However, that might break the backward compatibility and shortcuts. If that is the only problem, we can just map the old "menu path" to the new one when loading the configuration. |