[texworks] Early thoughts

[Jérome Laurens]

Le 18 sept. 08 à 15:26, Jonathan Kew a écrit :

> Hi Will, nice to have you here!
>
> On 18 Sep 2008, at 1:17 PM, Will Robertson wrote:
>
>> Hello,
>>
>> Now there's a mailing list for TeXworks (which nobody told me about!)
>
> Sorry! (It's mentioned on the texworks pages both at TUG and Google,  
> though.)
>
>> I don't feel so bad about posting suggestions for the program :) What
>> follows is a serious "wish" list in that while I wish it was there,
>> I'm still going to use the program without these features.
>>
>> I'm trying hard not to suggest ideas that would complexify the  
>> program.
>>
>> I'll omit bugs and behaviour that could be improved in favour of the
>> bug tracker…whenever I get around to doing that.
>
> Thanks for your comments -- as always, plenty of good thoughts here.
>
>> (1) The UI can be simplified! The following items should be dropped
>> from the "Format" menu since they're already (rightly) included in  
>> the
>> preferences:
>>  - "Font…"
>>  - "Wrap lines"
>>  - "Syntax Coloring"
>
> Well, they're not the same thing. The Preferences dialog sets the  
> defaults for newly-opened editor windows; the Format menu items  
> affect the current window only.
>
> Now maybe that's not necessary or helpful; maybe these settings  
> should be "global", not set for individual windows at all. Anyone  
> have thoughts on this?

I am talking about Mac but I am sure Windows and Linux users will  
understand.

On each OS, the user interface already has some conventions that one  
should avoid to break.
For example on Mac OS X, the Font... menu item will pop up a panel  
from which you can apply a new font to the text.
Just like other "Format" menu items like "bold" or "underline", these  
changes apply to the output document.
It seems to me that it beaks the natural way of thinking if the  
Font... panel is just used to change the font of the text input window.

For example, in iTeXMac2, you choose between different syntax coloring  
styles (I prefer syntax highlighting)
You can edit each individual syntax highlighting style in a separate  
panel where you can change the font and the color for various  
attributes.
That way, the standard menu item named "Font..." is not used because  
it would lead to misunderstanding for newbies.

For the moment, you stick to a very classical syntax highlighting  
scheme.
This makes sense if all the documents have the same type.
In general, the type of the document is driven by the extension in its  
name,
except for latex files.
For example, a beamer presentation, an article, a commercial letter  
may all have a different syntax highlighting scheme
(and text editor view). For them, choosing the syntax highlighting on  
a per document basis will help.

BTW, window size and position should be remembered on a document per  
document basis.
You won't use the same pdf window size whether you are editing an  
article or a beamer presentation.


>
>
>> (2) I'd really like the Find/Replace panels to be merged :)
>
> Could do, though some apps that do this end up with rather a lot of  
> options and buttons in the resulting dialog.
>
> Care to come up with a proposed design? :)
>
>> (3) Filtering the list of "Processing tools" (pdfLaTeX, etc.) could  
>> be
>> done quite reliably to omit options that don't make sense. E.g.,
>>
>> Matches ^\\usepackage([.*])?{fontspec} (etc.) -> XeLaTeX
>> Matches ^\\usepackage([.*])?{microtype} (etc.) -> pdfLaTeX
>> None of the above & matches ^\\bye -> Plain
>> Matches ^\\bibliography\{ -> BibTeX
>>
>> You'd only need a very small number of regexps, I think, to match the
>> majority of cases most of the time. And this would simply things in
>> the UI very nicely.
>
> I considered doing something along these lines; I was thinking more  
> in terms of auto-detecting a default engine even without a TeXShop- 
> style comment at the start, rather than filtering the list, but it'd  
> be a similar idea. This would have problems, though, with a doc that  
> does something like
>
> \usepackage{ifxetex}
> \ifxetex
> \usepackage[no-math]{fontspec}
> \setmainfont{Times-Roman}
> \else
> \usepackage[utf8]{inputenc}
> \usepackage{times}
> \usepackage{microtype}
> \fi
> % ....etc
>
> But it's probably worth trying to do something, anyhow. (Might also  
> want to detect \usepackage{pst*} and default to using simpdftex.)

If you have a mean to store this information on a per document basis,
this problem does not occur for documents created by TeXWorks.
In that case, the newbie will use document models and will never  
choose the engine.
More advanced users will choose the engine. They will do so on a per  
document basis,
and will do that only once because TeXWorks will remember their last  
setting (this is continuity).
You will have to automagically detect the processing tool for  
documents created by 3rd parties, for which you will have to do it  
only the first time.
If the document includes another document, this test will fail on the  
subdocument.
If the subdocument does not contain some kind of root document  
information, it is a problem.
The user should be informed that TeXWorks automagically detected the  
engine,
and if anything goes wrong, it is most probably caused by TeXWorks,  
not the user...

AFAIR, texnicenter parses the latex content to recover the  
subdocuments hierarchy.
Magics do have a cost.

>
>
>> For the people that will complain that it doesn't work in their tiny,
>> specific, edge case, just offer an option to turn off the filtering.
>> (Or a secret preference to edit the filtering regexps.)
>
> I'm intending to put several things like this -- e.g., the regexps  
> for syntax coloring and for tag detection -- into simple text files  
> in the "resources" folder, so they can easily be customized.

This is good practice, no regex, string, and alike should be hard  
coded, whether customizable or not.
You will have to design the proper customization scheme and overriding  
mechanism,
and you must take localization into account.
On Mac OS X, here is what you can do based on the cocoa way of doing  
things,
where the first file found in the following list is the good one

~/Library/Application\ Support/TeXWorks/my_directory/ 
my_file                   --> user
/Library/Application\ Support/TeXWorks/my_directory/ 
my_file                    --> machine
/Network/Library/Application\ Support/TeXWorks/my_directory/ 
my_file                    --> network
TeXWorks.app/Content/Ressources/my_language.lproj/my_directory/ 
my_file                    -> default value in user language
TeXWorks.app/Content/Ressources/the_default_language.lproj/ 
my_directory/my_file                    --> default value in default  
language
TeXWorks.app/Content/Ressources/my_directory/ 
my_file                    --> default value

>>>
>> (5) As well as command completion, I'd like automatic trigger stuff.
>> E.g., typing \begin{ on an otherwise empty line would immediately
>> insert an \end{ on the next line and then fill in both environment
>> delimiters at the same time as you typed the name of the environment.
>> Editing one of them would edit the other, simultaneously.
>
> Yes, that'd be slick.

possible and sexy but rather hard to implement.
Instead, "\begin{" can popup a tiny panel with nothing but a text  
field where the user enters the name of the environment.
Pressing enter will close this window and complete the \begin command  
with the proper template.
To have a better idea, go to address book, select one card and edit  
one field, you'll get the idea.

I think this is related to Herb's suggestion about command completion.

Basically, here is the problem.
The user enters a combination of keystrokes and the text editors  
answers by editing the text.
What Will and Herb are refering to is automated editing tasks.
In general, the editor inserts templates with placeholders, and the  
user has to navigate from one placeholder to the next to fill in the  
proper values.
Xcode does this rather efficiently.
There is another way of doing those things: we can popup a small form  
with a very small number of controls where the user will fill in  
fields, check boxes and whatever.
In such a form there can be explanations. From the developer point of  
view, this is very interesting because it separates the different  
editing tasks.
 From the user POV, this is very interesting because it clearly  
identifies an editing unit.

In some situations, the standard way of doing things is good, but in  
others, using a form is definitely the way to go.
If we come back to the "\begin{" problem, the ultimate UI is a form  
where the user can see a list of available environments in a combo box,
and once he has chosen the environment, he can choose the appropriate  
options related to this environment, if any.

By the way, the user should have a menu of the most frequently used  
actions where he could find an item that reads "Insert environment" and
acts the same way as "\begin{" by calling the same code of course.
That is called UI mutability, in order to adapt the app to the user  
needs.

>
>
>> (6) Smart <return> behaviour.
>> - Match the indentation of the previous line
>> - To generalise this idea, match the "prefix" of the previous line,
>> such as "[%]*[ ]*" or even "%<[a-zA-Z]*>[ ]*" (for .dtx files)
>> - Increase the indentation when the previous line contains
>> \begin{([a-zA-Z]*)} but doesn't contain \end{\1}
>> - Increase the indentation when the previous line ends with {
>> - Hitting delete after a smart indentation or a smart line prefix
>> insertion would undo the "smart whatever" rather than just  
>> backspacing
>> a key.
>
> Ditto.

alt+return

This is highly related to syntax coloring,
automagic indentation is more complicated than that because the regex  
must be much stronger than that.
IIRC, it is not possible to manage 100% of the situation with a  
reasonable amount of code but say 99% is certainly possible.

>
>
> Thanks,
>
> JK
>