[OS X TeX] your wiki needs you?
Alain Schremmer
schremmer.alain at gmail.com
Wed Sep 17 23:01:14 CEST 2008
On Sep 17, 2008, at 4:25 PM, Dr. Clea F. Rees wrote:
> On Wed 17th Sep, 2008 at 12:43, Maarten Sneep seems to have written:
>
>> On 17 sep 2008, at 01:24, cfrees at imapmail.org wrote:
>>
>>> On Wed 17th Sep, 2008 at 00:09, Mark Eli Kalderon seems to have
>>> written:
>>>> The page about editors <http://mactex-wiki.tug.org/wiki/
>>>> index.php?title=Editors> has no mention of TextMate. That's a
>>>> serious omission, I think. Just my two cents. Best, Mark
>>> It is a front end, isn't it? If not, I can move it onto the editors
>>> page. The question is: does it include a viewer? It was listed on
>>> the
>>> front ends page so I assume it does but I don't use it so don't
>>> know.
>>
>> It most certainly is an editor, although I think the distinction
>> is somewhat artificial. If I script BBEdit to be able to compile
>> and preview a tex file in Skim, and make that sufficiently smooth,
>> does that make the combination a front end?
>>
>> If I recall correctly, TextMate uses webkit to preview html files,
>> and uses the same mechanism to preview pdf files. As far as I know
>> there is no synctex/pdfsync provision in that previewer. Of
>> course, a TextMate user should then be editing that page anyway.
>
> Yes, the distinction is somewhat artificial. Nonetheless, think of it
> like this. Suppose somebody is starting out with TeX. She installs TeX
> Live. Now she wants an application(s) to create documents, process
> them
> and view the DVI/PS/PDF/etc. result.
>
> If an application will do all of that without her having to download a
> second application and without her needing to use an existing
> application on her machine such as Preview, call it a "front end" and
> stick it on the Front Ends page.
>
> If an application will do creation/processing but needs something more
> to do viewing (e.g. Skim, Preview etc.), call it an "editor" and stick
> it on the Editors page.
>
> If an application will do viewing but needs something more to do
> creation/processing (vim, BBEdit etc.), call it a "viewer" and
> stick it
> on the Viewers page.
>
> This is really just a way to break up what would otherwise be a very
> long page and to help somebody decide whether she needs to download/
> use
> 2 applications or 1. So the BBEdit/Skim combination isn't a "front
> end"
> however smooth it is.
>
> TextMate has a viewer. Therefore it goes on the Front Ends page. That
> it uses WebKit doesn't change that really - that isn't an application.
> The user need know nothing of WebKit (or Cocoa or...).
>
> I agree it is artificial. There are grey areas. Distinctions are often
> like that. But I think it is still useful - especially to somebody
> trying to figure out what's needed to start out.
>
> Both the Editors page and the Viewers page contain explanatory notes
> and links at the top. They both have additional links at the bottom.
>
> Not everything on the viewers page has synctex/pdfsync integration,
> either. (Preview? Adobe Reader?)
>
> At least, this is how I've been interpreting the distinction. I think
> the only other way to do it would be to put everything on one page -
> front ends, editors and viewers. But that would make for a rather
> unmanageable page, I think.
Considering that, once upon a not too distant time, I was in the
category "starting out with TeX", I absolutely agree with the above
even though I am pretty sure I had no idea what a "front end" was.
Perhaps something like "integrated systems", in which the editor and
the viewer work with each other out of the box, e.g. TeXShop +
Preview, might be useful and you could even have a sub page entitled
"synchronized systems".
On the other hand, I think that a page, called something like
"component systems", in which the editor and the viewer require some
but not too much work to adjust to each other, might also be useful.
Obviously, though, I am being influenced by the Hi-Fi set ups of the
near end of the twentieth century.
Regards
--schremmer
More information about the macostex-archives
mailing list