Re: [TeXstudio-list] Organization of menus

[Benito v. d. Z. <be...@be...>]

> No. Maybe I just want to see, if the file compiles without errors.
The inline syntax check could do that
> Then I'm
> not interested in correct labels, but it should go fast.
If there are errors, it won't rerun latex, and if there are none,
it doesn't hurt if it compiles in the background
> 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.
I could make everything explicit, than you can disable it, if you don't 
want it.
I.e.
remove internal-pre-compile and only run the 
pre-compile/conditionally-recompile-bibliography,
if pre-compile is explicitely added at the beginning of the command.

And only rerun a latex command, if it is marked as rerunable.
Either with a list of rerunable commands, or in-place like 
txs:///rerunnable/latex.
> That's exactly what an more experienced latex user would expect
But does the user want it?

And the beginner wants his references... (I think before rerunning, 
there were
bug reports about missing citations)
> (see the recent questions on multiple compiler runs).
This is more a problem of an incorrectly detected rerun need.
> 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).
No, I think that would be backward, a setting should not
depend implicitly on another.


On 05/04/12 00:49, Tim Hoffmann wrote:
>> 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.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> TeXstudio-list mailing list
> TeX...@li...
> https://lists.sourceforge.net/lists/listinfo/texstudio-list
>