[texworks] some suggestions

[ludolf at email.cz]

Thanks you very much for the response.

1. "$basename" is what I was looking for (I tried $jobname inspired by configurations files).

3. Sorry, I do not like to create an account there.

4. I tried to create a shortcut by the line
  actionRemove_Aux_Files = Ctrl+R
at .\texlive2012\texmf-config\texworks\configuration\shortcuts.ini in my home directory (according to built-in "A short Manual for TeXworks", Windows 7). The text "Ctrl+R" appeared next to the menu item, however "Ctrl+R" does nothing. I am not familiar with scripts, I wrote a batch file for deleting (in fact two such files because it is sometimes useful to delete the outputs, too) and I call them from the typeset menu. But more direct access would be better.

ludolf

----------  Stefan Löffler 2012-12-08

Hi,

On 2012-11-05 21:34, ludolf at email.cz wrote:
> I installed TeXworks (0.4.4.r.1003 from teX Live 2012 DVD, Windows 7) and I like it. I am not using all its features (yet) -- I was esentially looking for a simple front-end that enables TeXing and viewing and I am very satisfied with it.

I'm happy to hear that.

> I have a few suggestions to enhance its possibilities.

Thanks, I'm always open for suggestions!

>
> 1. A parameter (an analogue to $fullname) for batches giving a filename without an extension. Sometimes I need a PostScript output. I made a batch pslatex for this purpose calling latex and dvips. However, it seems that dvips needs a filename without an extension. I am using my external program for eliminating the extension, however, a direct solution would be better.

There already is support for "$basename" (=filename without extension),
"$suffix" (=the extension), and "$directory".

> 2. A possibility to ignore the internal editor. I often use my editor or generate the TeX file by some programs. It is a bit annoying to confirm that it is OK that the source file was modified. (In fact the reaction is a bit strange - usually I get the warning that the file was changed first, then the warnings that the file cannot be loaded, and sometimes after a couple of warnings there are no warnings at all.) It is especially useful with the "green triangle" beeing a part of the viewer menu (good idea!) -- the window with the editor might be hidden.

Hm, curious. What other editor are you using? One warning is "by design"
as we don't want to reload a file (thereby possibly changing the
document, which might result in data loss) without the user's consent.

In principle, an overhaul of this part of the program is planned that
might also include the possibility to typeset with the "green triangle"
without opening the source. Right now, this is necessary, however, as
the typesetting is controlled by the source window only. Besides,
otherwise, there would be no way to check for errors, etc.

> 3. Autodetection of the input encoding of LaTeX files by the editor if a string "[]{inputenc}" (or with "\usepackage" with possible white spaces before) is found.

Autodetection of input encoding (in a more general sense without relying
on packages) is planned as well. But using the options to {inputenc} is
a good idea. Could you post this on
http://code.google.com/p/texworks/issues/list, please?

> 4. Quick deleting of auxilliary files. E.g. by an icon (red cross?) without a confirmation (since these files are auxiliary, this does not seem to be necessary). I tried to create a hot key, but without a success.

Deleting things without confirmation is always a bit dangerous, so I'm
not very fond of having an icon prominently in the toolbar.
A hotkey for directly deleting the files doesn't work right now (as the
dialog needs to be shown), but you should be able to assign a shortcut
to the "Remove Aux files..." menu item so you could quickly delete files
using, e.g., Ctrl+R,Return. See the manual for how to define custom
shortcuts.
Alternatively, you could write a script to delete the files, but that
seems like overkill.

> At the cleanup-patterns in texworks-config.txt file the ".aux" should be probably replaced by "$jobname.aux" and "$jobname.pdfsync" by "$jobname.synctex.gz".

For the .aux, this is probably not such a good idea. Suppose you have a
file main.tex that includes chap1.tex. Then you'll end up with main.aux
and chap1.aux, but $jobname.aux would only catch main.aux.

Regarding .pdfsync, I'm not sure. I tracked that suffix back to r207
where it was introduced. But at that time, the respective
synchronization file already had .synctex as suffix, so I guess that
pdfsync has some other origin.
In fact, I can imagine that keeping the .synctex file is beneficial in
many cases (although you are right of course in that it is an auxiliary
file) as it allows synchronization. Generally, I don't think we can
resolve this in the current approach without braking backwards
compatibility. However, there are plans for the support of larger
projects, and in the wake of that I plan to rework the file
classification scheme (what is auxiliary, what is important, etc.) as well.

Regards,
Stefan

PS: So many things planned, so little time...