TeXworks developments

Over recent weeks, Stefan Löffler has provided new builds for TeXworks
featuring a re-implementation of the PDF view. This offers
new modes for previewing the output, most notably continuous scrolling.
It’s also intended to be much faster than the older viewer.

Stefan’s also been setting up Travis-CI testing for TeXworks, and this
has the added benefit that he’s now able to provide Mac binaries in addition
to Windows and Linux ones. Stefan himself doesn’t have a Mac for testing
them, but Travis-CI can run automated tests. Moreover, individual users
can grab the burning edge code and use it themselves.

Customising TeXworks auto-completion

TeXworks is a very flexible editor, and one of the things you can customise, if you want, is the set of auto-completion values it knows. For those of you who are not familiar with it, TeXworks uses a simple list of simple completion options, so when I type

\doc

I can press the Tab key and be offered

\documentclass{}

and if I press Tab again,

\documentclass[]{}

That’s very useful, but some of the auto-complete options are not ones I use a lot. There are also a few inconsistencies in how the results are formatted: while TeXworks inherited a basic set from TeXShop, it also comes with some additions and they don’t always quite agree on how things should work! So I’ve been looking a bit at sorting out my own custom set, adding things I use, removing ones I don’t and so on.

The basic format for the auto-complete files is to have a first line for the encoding

%% !TEX encoding = UTF-8 Unicode

then one or more lines for each completion. Each line can either just have a completion vale

\alpha

or have a ‘shortcut’ text version

xa:=\alpha

There are then a few bits of ‘helper’ syntax. You can use #INS# to show where the cursor should end up, #RET for a return and as a marker you can jump to using Ctrl-Tab (Option-Tab on the Mac). So for example the \documentclass lines read

\documentclass{#INS#}#RET#
\documentclass[#INS#]{•}#RET#

I’m told that TeXShop has extended the syntax a bit, but at least at the moment in TeXworks that all there is to know.

So what have I done to customise the files? TeXworks comes with four auto-complete files, but the values offered simply come from them all together (you can’t currently select only some files). (You might wonder where these files live: they are ‘hidden away’: TeXworks will tell you how to find them from Help -> Settings and resources.) So my first move was to create one new file, after first backing up the originals of course! I then did a few experiments, thinking about what I use a lot, what I’m used to, etc. I did wonder about some of the choices in the standard files, but a bit of experimentation suggests they are not so bad! So I’ve currently ended up mainly just adding a few things, for example

{tikzpicture}[#INS#]#RET#•#RET#\end{tikzpicture}•

for TikZ pictures and

cs:=\cs{#INS#}
pkg:=\pkg{#INS#}
\cs{#INS#}
\pkg{#INS#}

for package development work. I’m also not too keen on having too many of the ‘shortcut’ values, which don’t start \, so I’ve removed most of them and have just a core set (things like bf and em). If you want to see my current full set, you can of course download it.

So is there anything I’d like to see added to the way auto-complete works? I have a few ideas! From my questions on the TeXworks mailing list, I’ve picked up that TeXShop maintains indentation when doing auto-complete: TeXworks doesn’t, and I think it would be a good addition. TeXShop also allows an extended syntax

\documentclass[#INS#•#INS#]{•}#RET#
\rule[#INS#•‹lift›#INS#]{•‹width›}{•‹height›}

where you can always have a for ‘fill in’ and have ‘reminders’ about what the values are. That looks useful too.

TeXworks roadmap

There has been some discussion over the past couple of weeks on the TeXworks mailing list about the future direction of the project. As regular readers will know, I like TeXworks, and use it as my day-to-day editor, so I’m very interested in what the developers are up to.

Two very useful things have now been added to the project website. First, there is a roadmap highlighting the key areas for development for v0.6 and v0.8. It looks like v0.6 is mainly about improving the PDF viewer, with editor improvements as the main target for v0.8.  For C++ coders, there is also a list of ideas to work on. That should let people with the right skills dip in to coding TeXworks in a self-contained way.

TeXworks is a great project, and I do hope that interested C++ programmers in particular see these new pieces of information as an opportunity to get involved. For those of us who don’t code C++, direct contribution is a bit more difficult, but spreading the word is something we can all do.

New Mac OS X TeXworks builds

As many readers will know, the TeXworks project aims to provide a cross-platform TeX editor. A key requirement for that is that end-users can get a working version of the code. On Windows, that’s not too bad as the main developers provide pre-build binaries with reasonable frequency. On Linux, there are a number of pre-built versions available for different distros, and building from the source tends to be a case of following a recipe. That leaves Mac OS X, where life has been awkward for a while. Luckily, after a period where not much happened there are now some experienced people looking at this. Charlie Sharpsteen seems to be getting on well with sorting out the issues, and has just posted builds for Snow Leopard and for Leopard for the current development code. For me, these look good, so we’re hopefully in a position where TeXworks on the Mac continues to grow.

TeXworks ‘magic comments’

The new TeXworks release adds a new ‘magic comment’ to the set that the program knows. So I thought it might be useful to have a list of those that currently work, and a typical setting for each one.

% !TeX program = LuaLaTeX

The name of the typesetting engine to use for the current file, which should be one of the engines that is set up for use with TeXworks. This is useful if you normally use one engine (for example pdfLaTeX), but have a few files that need an alternative engine. In my example, the file would automatically use LuaLaTeX as the engine.

% !TeX encoding = UTF-8

Sets the file encoding for the current file. The usual default is UTF-8, but this setting is handy if you need to collaborate with other people using non-UTF-8 editors.

% !TeX root = somefile.tex

Indicates that the current file is not the main file for typesetting: when you choose to typeset, TeXworks will save the current file then typeset the master file. Using this setting, you need the full name of the master file including the extension. This is clearly a handy setting for larger projects, where you might have a lot of files which are to be included in one master document.

% !TeX spellcheck = de_DE

Specify the spell check language for the current file. This is a new setting in v0.4.0 (it was not present in the 0.2 stable release). The language of course needs to be one you have installed! One point to notice with the

root setting is how it interacts with program. Let’s imagine that the master file needs to be typeset using LuaLaTeX, and that your default engine is pdfLaTeX. You then need to include the program in each subsidiary file to get everything to work properly:

% !TeX root    = master.tex
% !TeX program = LuaLaTeX

If you don’t do that, when you try to typeset from one of the subfiles then TeXworks will use the currently-selected engine (probably pdfLaTeX) and

not LuaLaTeX for the typesetting. Once you know, this is not so surprising, but at first it caught me out!

New TeXworks build for Mac OS X (64-bit Intel)

I posted yesterday that v0.4.0 of TeXworks has been released: this marks a new stable branch in the code. I also pointed out that there are official Windows and Ubuntu builds. I’m now pleased to see that there is also an unofficial build for the Mac, at least for 64-bit Intel systems (like mine!). Thanks to Jjgod Jiang for doing this: I’ve posted before about the issues building TeXworks on the Mac. So I’m now happily using the first new Mac build for over a year.
TeXworks v0.4.0 on MacOS

TeXworks v0.4.0

Stefan Löffler has posted to the TeXworks mailing list the following:

Windows binaries and a source code bundle have been uploaded to GC, and Ubuntu packages are currently building (see https://launchpad.net/~texworks/+archive/stable/+packages). The web page (http://www.tug.org/texworks/) will be updated soon (just waiting for a routine pull from the GC repository). For a quick overview over the most important changes, please have a look at http://code.google.com/p/texworks/source/browse/tags/release-0.4.0/NEWS

This is very much evolution in TeXworks development: I’ve been using the unstable builds for some time with no serious issues, and doubt that will change much with the release of v0.4.0. I’ve quickly tested the Windows builds, and have also done a quick build on Ubuntu (see the screenshots). You will see that Mac OS X builds are currently missing: getting them working is currently proving to be something of a difficult task. So for the moment, on the Mac you have to stay with older (but quite usable) builds.

 

TeXworks: building on a Mac

Development of TeXworks has picked up over the last couple of months, with a drive to get to version 0.4. Several builds for Windows have been posted on the TeXworks downloads page, so testing there has been pretty easy. For Linux users, the instructions for building from source are not too bad, so anyone wanting to test on Linux has also been okay. However, Mac users face more a more difficult time. The last official binaries were posted in February 2010, and most Mac users don’t build software from the sources.

There was a post to the TeXworks mailing list yesterday asking for volunteers to get Mac binaries sorted out. This will not be a trivial process: Mac OS X is used on PowerPC and Intel chips, and the later covers both 32- and 64-bit cases. However, the aim has to be first to solve the more basic problem of getting the software to build at all! Bruno Voisin has managed that, but this is a test case and not really suitable for distribution.

As I’ve got a Mac, I’m having a go at solving some of the problems, but my experience with serious programming is pretty much non-existent, so whether I’ll be much help I’m not sure. So any keen TeX-using Mac programmers reading might want to take a look at the discussion and make suggestions (or of course provide some binaries and build instructions!).