[OS X TeX] your wiki needs you?

Dr. Clea F. Rees cfrees at imapmail.org
Wed Sep 17 23:16:17 CEST 2008


On Wed 17th Sep, 2008 at 17:01, Alain Schremmer seems to have written:

>
> 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.

I hope that the explanations at the top of the TeX Editors, TeX Front
Ends and Viewers pages would have proved useful to you in that case.

>
> 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.

Why don't you create pages with the names that would make sense to you
as redirects to the appropriate pages of the wiki? That way, somebody
using that terminology will still find the right page - as will
somebody looking for a "front end" which would certainly be a much more
familiar term to me, personally, for example.

Several entries already mention synchronisation possibilities. This
seems to be changing a lot, too, so no doubt more of the entries will
list this as a feature in the future - at least if the users who know
the applications edit the summaries to highlight it.

There are at least two kinds of synchronisation, actually - the
automatically-update-preview-when-source-modified kind and the
synctex/pdfsync/text search kind.

You could always have a go at
http://mactex-wiki.tug.org/wiki/index.php?title=Synchronization.

- cfr


> Regards
> --schremmer
>
>
>
>
>
>

-- 

Dr. Clea F. Rees

ReesC17 at cardiff.ac.uk
cfrees at imapmail.org

-------------- next part --------------
----------- Please Consult the Following Before Posting -----------
TeX FAQ: http://www.tex.ac.uk/faq
List Reminders and Etiquette: http://www.esm.psu.edu/mac-tex/list/
List Archive: http://tug.org/pipermail/macostex-archives/
TeX on Mac OS X Website: http://mactex-wiki.tug.org/
List Info: http://email.esm.psu.edu/mailman/listinfo/macosx-tex



More information about the macostex-archives mailing list