Non modal errors in "Watch Document" mode

[taiya]

When you are watching a latex document and an error is produced you get a "modal" error window like the one below. This steals the focus, preventing you from correcting the error you made.

It would be much better if the HTML output pane was opened and the error log displayed there, similarly to what happens when you typeset the document:

[nemesit]

Yeah this would really be nice

[sorbits]

Perhaps it would be sufficient to indicate the errors in the gutter
using the new gutter mark support?

Downside is that the user may overlook it and it does not allow for
aborting watching or showing the log, though for the latter, an error
message can be associated with the mark.

On 15 Nov 2014, at 11:44, nemesit wrote:

Yeah this would really be nice

---

Reply to this email directly or view it on GitHub:
#73 (comment)

[taiya]

If you just show the error, then I'd still have no idea what the error is about (you'd have to do another action to see it). Conversely, if you open up the HTML pane with the error content on the other hand, it's already there!

[nemesit]

why not both ;-p

[taiya]

In about a month I am going to enter in writing season (research paper deadline).
If this feature will be in, I promise I will make a small donation to TextMate :)

And yah, both sounds like a good idea.

[sorbits]

Generally when I get a build error, I first go to the line that the
compiler tells me has an error, and only if I can’t spot the error
then I read the message from the compiler.

So I’m not sure having to click the gutter image to read the error
message will be a problem in practice, but it’s been a while since I
was doing a lot of LaTeX work, so I don’t recall how much I relied on
the error messages there.

Though it’s worth mentioning that while currently one has to click the
gutter image to see the error, we could later show them inline.

Also, opening a HTML window from the background command is not currently
possible, but it could open another notification window (the Subversion
bundle uses such light-weight (non-modal) panel to report status after
commit etc.).

On 15 Nov 2014, at 11:58, Andrea wrote:

If you just show the error, then I'd still have no idea what the error
is about (you'd have to do another action to see it). Conversely, if
you open up the HTML pane with the error content on the other hand,
it's already there!

---

Reply to this email directly or view it on GitHub:
#73 (comment)

[sorbits]

Donations (from LaTeX users) should go to @sanssecours.

https://github.com/textmate/latex.tmbundle/commits/master?author=sanssecours

On 15 Nov 2014, at 12:05, Andrea wrote:

In about a month I am going to enter in writing season (research paper
deadline).
If this feature will be in, I promise I will make a small donation to
TextMate :)

---

Reply to this email directly or view it on GitHub:
#73 (comment)

[nemesit]

LaTeX error messages are something i rely on quite a bit as it becomes difficult to find certain compilation problems just from the failure itself^^, and searching the log manually takes some time that could be used more productively

[nemesit]

i think the gutter thing would probably be best especially if they could later be shown inline

[taiya]

In a perfect world that would be amazing (where latex errors would be readable). But honestly a large part of latex error come without much information about its cause (math mostly causes this issue). Therefore, the reason for which the "watch document" feature is amazing is that while I edit I can keep a continuous check on the correctness of the latex syntax.

I always use the watch document mode. Sometimes I can guess what I did wrong by pressing "ignore" on the modal window and just look at the last tweaks I did. But very, very very often I am forced to "show the log" to understand it. When I quickly notice what I did wrong (usecase #1 above) I still have to use the mouse to "ignore" the error prompt window. Clearly not optimal, as you might imagine.

About the gutter, I guess I am not sure I have actually seen it before :) :)
Can you show me where it's hiding?

[sanssecours]

Hi,

I think I need to get faster at typing :). Allan already answered one of the questions I would have had: It is not possible to open an HMTL output window outside of TextMate :(. This functionality would make fixing this issue certainly much easier.

As Andrea (drtaglia) already pointed out: LaTeX error log are not that great to parse. Some problems include:

• Most of the time log output lines will be wrapped at 80 characters even between w
  or
  ds
• Sometimes lines you expect to get wrapped still continue and you get very long lines containing multiple error messages.
• Some of the errors messages do not contain line information at all.

Especially the last point makes showing all error messages in the gutter hard. Where should we put an error message if we do not know where the error occurred…

I guess I will — when I have free time — implement showing error messages in the gutter. After that I might look into some other ways to fix this issue.

Kind regards,
René

[sorbits]

As for the “simple notification” used by the Subversion bundle, here is a quick crash course:

Open a notification window using the following shell command (can test with ⌃R in TextMate):

"$DIALOG" nib --load "$TM_SUPPORT_PATH/nibs/SimpleNotificationWindow.nib" --model '{ title = "LaTeX Watch"; summary = "Error while calling pdflatex"; log = "Lorem ipsum dolor sit amet."; }'

The command returns a «token» which we can later use to update the window, e.g.:

"$DIALOG" nib --update «token» --model '{ summary = "No errors."; log = ""; }'

And once we stop watching the tex file we close the window:

"$DIALOG" nib --dispose «token»

For some reason the list and wait dialog commands do not work with this nib and there is currently no way to open the notification window without making it key (but later updating it will not make it key).

I can look into these things if someone wants to update the LaTeX bundle to use the notification window instead of the modal dialog. Also, right now calling "$DIALOG" nib --update «token» for a non-existing token just silently succeeds, I think here the dialog command should return an error, that way, LaTeX Watch can open the dialog on first error and re-use that on subsequent errors, but if updating fails (the user closed the window), then it should open a new dialog window.

[taiya]

LoL my subversion shortcut look very interesting:

[sorbits]

We bind all SCM actions to ⌘Y so presing that key will open a menu of
available SCM actions for your current file (be it controlled by
Subversion, Git, or Mercurial).

On 15 Nov 2014, at 14:41, Andrea wrote:

LoL my subversion shortcut look very interesting:

---

Reply to this email directly or view it on GitHub:
#73 (comment)

[sanssecours]

Hi everyone,

I just pushed some changes that should address the issues reported here. “LaTeX Watch” now uses the “notification window” that Allan mentioned. The window will appear if there are errors and should disappear after the errors are fixed.

One problem with the current implementation is, that if we close the notification window manually it will never come back. The reason behind this behaviour is that currently dialog will not report an error if the window for a specific token was closed. My favorite way for fixing this would be for dialog to just open a new notification window and return the token for this window. The simple reason for that being my favorite option is, that the current code should just work if dialog would act this way :o). dialog just printing an error message if the window for a specific token was closed would be fine with me too, of course. As long as I do not have to make the changes to dialog I am happy :o).

You can test the current changes for “LaTeX Watch” by following these steps:

1. Uninstall the LaTeX bundle inside Preferences
2. Issue the following commands inside Terminal:

cd ~/Library/Application\ Support/TextMate/Managed/Bundles/
git clone -b latex_watch_notification https://github.com/textmate/latex.tmbundle.git

If you have questions, comments or improvement suggestions please feel free to post them here.

Kind regards,

René

[sorbits]

Great work!

An update to my comment above:

1. The list command has since been fixed (thanks to @rdwampler):
   283c0373f6259f411b0695357b162ff52298e412.
2. The update command (now) does write something to stderr when the
   window does not exist (6b8a9acf87c5c462492429261d44e67259e351fa). Though
   this isn’t ideal, better would be to return a non-zero return code,
   but that is not entirely trivial, discussion at
   Write to stderr if «token» does not exist when calling nib update dialog#17.
3. The wait command does work, despite what I wrote above. This would
   have to be used in a thread to wait for the window being closed, which
   could then set a flag to indicate that the window needs to be recreated.

Any of the above should be usable to figure out if the window needs to
be re-opened, I think the simplest is to use number 2 and just check if
output to stderr is non-empty, and treat that as “window was not
already open”.

As for dialog itself re-opening the window on update: I don’t think
that is a workable solution because right now, if the user close the
window, we dispose all resources related to that window. If we had to
support re-opening, then we would have to keep the resources aroud,
which would affectively mean that windows opened via the dialog command
would leak.

On 15 Dec 2014, at 4:08, René Schwaiger wrote:

Hi everyone,

I just pushed some changes that should address the issues reported
here. “LaTeX Watch” now uses the “notification window” that
Allan mentioned. The window will appear if there are errors and should
disappear after the errors are fixed.

One problem with the current implementation is, that if we close the
notification window manually it will never come back. The reason
behind this behaviour is that currently dialog will not report an
error if the window for a specific token was closed. My favorite way
for fixing this would be for dialog to just open a new notification
window and return the token for this window. The simple reason for
that being my favorite option is, that the current code should just
work if dialog would act this way :o). dialog just printing an
error message if the window for a specific token was closed would be
fine with me too, of course. As long as I do not have to make the
changes to dialog I am happy :o).

You can test the current changes for “LaTeX Watch” by following
these steps:

1. Uninstall the LaTeX bundle inside Preferences
2. Issue the following commands inside Terminal:

cd ~/Library/Application\ Support/TextMate/Managed/Bundles/
git clone -b latex_watch_notification 
https://github.com/textmate/latex.tmbundle.git

If you have questions, comments or improvement suggestions please
feel free to post them here.

Kind regards,

René

---

Reply to this email directly or view it on GitHub:
#73 (comment)

[sanssecours]

Hi Allan,

thanks for the quick and elaborate reply.

1. The update command (now) does write something to stderr when the window does not exist.

Unfortunately this only works for me if the window identified by token was never opened. For example: If I run the command

"$DIALOG" nib --load "$TM_SUPPORT_PATH/nibs/SimpleNotificationWindow.nib"

inside TextMate via ^R I get a token. Lets say this token is 7. I can then update this window by running

"$DIALOG" nib --update 7 --model '{ summary = "Hi"; log = ""; }'

This will update the window and print nothing at all. If I now close the window — via the close button — and issue the last command again then the window will not be updated since it was already closed. The output however does not indicate an error and will just be empty.

If I try to open a window that was never open e.g. by issuing the command

"$DIALOG" nib --update 1000 --model '{ summary = "Hi"; log = ""; }'

the command will fail correctly with the error message There is no nib with that token.

1. The list command has since been fixed (thanks to @rdwampler)

Issuing the command "$DIALOG" nib --list prints out a list containing all windows that were opened for me. This list includes already closed windows. If I close a window via "$DIALOG" nib --dispose «token» the window is correctly removed from this list. I guess dialog should call the same code that "$DIALOG" nib --dispose «token» runs when the close button of a window is pressed or am I missing something?

Kind regards,
René

[sorbits]

It would seem we intended for the client to always call --dispose.

I think this only makes sense when using --wait so I have improved it so
we now auto-dispose when the client is not using --wait (and window is
closed by user), so starting with 2.0-beta.6.6 you should be able to
rely on --update outputting an error if the user has closed the window
(I’ll push that as a nightly build later today).

On 15 Dec 2014, at 16:37, René Schwaiger wrote:

Hi Allan,

thanks for the quick and elaborate reply.

1. The update command (now) does write something to stderr when the
   window does not exist.

Unfortunately this only works for me if the window identified by
token was never opened. For example: If I run the command

"$DIALOG" nib --load 
"$TM_SUPPORT_PATH/nibs/SimpleNotificationWindow.nib"

inside TextMate via ^R I get a token. Lets say this token
is 7. I can then update this window by running

"$DIALOG" nib --update 7 --model '{ summary = "Hi"; log = ""; }'

This will update the window and print nothing at all. If I now close
the window — via the close button — and issue the last command
again then the window will not be updated since it was already closed.
The output however does not indicate an error and will just be empty.

If I try to open a window that was never open e.g. by issuing the
command

"$DIALOG" nib --update 1000 --model '{ summary = "Hi"; log = ""; }'

the command will fail correctly with the error message There is no nib with that token.

1. The list command has since been fixed (thanks to @rdwampler)

Issuing the command "$DIALOG" nib --list prints out a list
containing all windows that were opened for me. This list includes
already closed windows. If I close a window via "$DIALOG" nib --dispose «token» the window is correctly removed from this list. I
guess dialog should call the same code that "$DIALOG" nib --dispose «token» runs when the close button of a window is pressed or am I
missing something?

Kind regards,
René

---

Reply to this email directly or view it on GitHub:
#73 (comment)

[sanssecours]

Hi Allan,

It would seem we intended for the client to always call --dispose. I think this only makes sense when using --wait so I have improved it so we now auto-dispose when the client is not using --wait (and window is closed by user), so starting with 2.0-beta.6.6 you should be able to rely on --update outputting an error if the user has closed the window (I’ll push that as a nightly build later today).

thanks a lot. This change certainly makes things easier for me.

Kind regards,
René

[sanssecours]

Hi,

commit a59c77a should fix the issue that a manually closed notification window would never reappear. I am still interested in feedback. Andrea, nemesit: Does the code work for you? Do you have any improvement suggestions?

Here are some screenshots from the current implementation for anybody that is interested:

Kind regards,
René

[taiya]

sorry, right now I am in the middle of a huge deadline.
I can get back to this in February.

On Wed, Dec 17, 2014 at 4:45 PM, René Schwaiger notifications@github.com
wrote:

Hi,

commit a59c77a
a59c77a
should fix the issue that a manually closed notification window would never
reappear. I am still interested in feedback. Andrea, nemesit: Does the code
work for you? Do you have any improvement suggestions?

Here are some screenshots from the current implementation for anybody that
is interested:

[image: Notification Window]
https://cloud.githubusercontent.com/assets/691989/5473655/605a06a4-860b-11e4-8d65-09a2e1fed1f5.png
[image: Gutter Marks]
https://cloud.githubusercontent.com/assets/691989/5473656/60c0e59a-860b-11e4-8e23-3a0f78c65149.png
[image: Gutter Mark Activated]
https://cloud.githubusercontent.com/assets/691989/5473657/610690ae-860b-11e4-9e4f-b7ae02380257.png

Kind regards,
René

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

[nemesit]

Doesn't work here, at first it looked promising e.g. it showed to warnings related to labels.
But it does not seem to show errors or anything. It just "compiles" and shows whatever pdf worked last.
undefined control sequences simply get ignored

[nemesit]

The window closing and opening works I think, but error/warning reporting only on the initial compile step and not on updates during the watching

[sanssecours]

Hi nemesit,

The window closing and opening works I think, but error/warning reporting only on the initial compile step and not on updates during the watching

strange. Updating — after save — works for me. Could you please provide a minimal example together with expected/actual result?

Kind regards,
René

[nemesit]

This document for example does not work https://gist.github.com/nemesit/c95b6398683488b8a55a
But it should throw errors for line 92,93

[sanssecours]

Hi nemesit,

This document for example does not work https://gist.github.com/nemesit/c95b6398683488b8a55a
But it should throw errors for line 92,93

thanks a lot for the example file. Commit 58a26e should make things better. The error output:

could however be prettier. Currently I plan to make the following changes in the future:

• Remove duplicate error messages
• Add error and warning messages that contain no line information

Does the new code work for you, nemesit?

Kind regards,
René

[nemesit]

Nope for some reason the log messages still disappear after the first update

[sanssecours]

Hi nemesit,

thanks for the quick reply. Could you please check the command output for me? For this please follow these steps:

1. Checkout the debug branch

   cd ~/Library/Application\ Support/TextMate/Managed/Bundles/
   git fetch
   git checkout debug

2. Install the Make bundle inside TextMate preferences

3. Open the Makefile for the LaTeX bundle

   mate Makefile

4. Run the default target run by using ⌘B

5. Open makeindex.tex:

   mate Tests/TeX/makeindex.tex

   Insert two errors like undefined commands e.g. \hello, bla. Please save the document after each error insertion.

6. Remove the first error and save the document. Do the same for the second error.

7. Stop the make task: Bring the HTML output to the front and press ^C (CTRL-C).

8. Copy the output and share it

It would be really helpful if you could do that. Thanks again for your feedback.

Kind regards,
René

[nemesit]

Here is the output https://gist.github.com/nemesit/857362b8ad22810c1a0d

[sanssecours]

Hi nemesit,

it seems that only one error is detected. The rest seems mostly fine to me.

I made a screen recording that shows how I insert two errors and then remove them. If you follow the steps made in the video do you get the same output?

If not:

• How is the output different?
• Could you please post the log file that you get when you follow the steps?

Thank you,
René

[nemesit]

If I do that I get the same output https://gist.github.com/nemesit/768854f66b9b87ceb61c I think
It seems to only not work with the example tex file I posted earlier and other files with roughly similar preamble content

[sanssecours]

Hi nemesit,

if I comment line 22 — I do not have “Garamond Premier Pro” installed — in the example tex file, then the notification window shows the following output:

WARNING tmp.tex:356 — LaTeX Font Warning: Font shape `EU2/lmr/mb/n' undefined (Font)              using `EU2/lmr/m/n' instead on input line 356.
ERROR   tmp.tex:92 — Undefined control sequence.
ERROR   tmp.tex:93 — Undefined control sequence.

While I think the first warning messages is rather strange, the rest seems to be fine. Updating works for me too. So if I for example remove \frr from line 93 I get the following output:

WARNING tmp.tex:356 — LaTeX Font Warning: Font shape `EU2/lmr/mb/n' undefined (Font)              using `EU2/lmr/m/n' instead on input line 356.
ERROR   tmp.tex:92 — Undefined control sequence.

After I remove \fraac the notification window closes. If I re-add \fraac the notification window displays

WARNING tmp.tex:356 — LaTeX Font Warning: Font shape `EU2/lmr/mb/n' undefined (Font)              using `EU2/lmr/m/n' instead on input line 356.
ERROR   tmp.tex:92 — Undefined control sequence.

again.

Doe this work for you? If not, could you please post the corresponding log?

Thanks again for your feedback,
René

[nemesit]

\usepackage[urw-garamond]{mathdesign} is the reason that WARNING tmp.tex:356 — LaTeX Font Warning: Font shapeEU2/lmr/mb/n' undefined (Font)` shows up. You're right the example works now for whatever reason, in my main document though I still get the previous behaviour e.g. first time errors and no errors (empty error window) on updates

[nemesit]

example too only works sometimes it seems now it does the same again ...weird
example.latexmk.log: https://gist.github.com/nemesit/49fb1fd2887cfdf46bd5

[sanssecours]

Hi nemesit,

I think I discovered the problem. If we add problematic input to an tex file latexmk will produce error messages. The notification window will then print out some of those. If we now save the file again without changing anything then latexmk will just output something like All targets are up-to-date. texparser will then parse the new output of latexmk and find no errors at all, since the new log only contains the message mentioned before. texparser will then close the notification window. Only after we enter some additional input to the tex file and then save again, then the notification window will reappear. This happens because latexmk detects the changes to the file, typesets it again and then outputs the (old) error messages. Does the description match the issues that you found?

Kind regards,
René

[nemesit]

Nope the error window stays empty after altering and saving

[sanssecours]

Hi nemesit,

the newest commits to latex_watch_notification should hopefully fix some of the issues reported by you. Could you please test the code and post “steps to reproduce” if you find any problems?

Thank you,
René

[szymtor]

Hi everyone,

I have a very simple solution which gives effects similar to what drtaglia asked in the first post in this thread – the errors are displayed in the standard typesetting window (with html markup), and typesetting is done continuously, similarly to as in Watch Document.

The idea is to run the typesetting command (Cmd+R) with latexmk in pvc mode (preview continuously).
For this to work I modified a few lines in texmate.py and texparser.py
(this is submitted in my forked tmbundle: https://github.com/szymtor/latex.tmbundle).

The basic idea can be implemented by modifying just two lines:
A. In LaTeX.tmbundle/Support/bin/texMate.py
in line 1296 add the option -pvc before -f:
command = "latexmk -pdf{} -pvc -f -r /tmp/latexmkrc -r {} {}".format(
B. In LaTeX.tmbundle/Support/bin/texparser.py comment out line 885:
# self.done = True

To use:

1. In Bundles→Latex→Preferences set:
   Default engine: pdflatex,
   Use Latexmk: Yes,
   Show pdf automatically: Yes.
2. Make sure that the pdf previewer checks the file for changes
   (in Skim→Preferences→Sync mark Check for file changes).
3. To continuously compile a latex file, use Cmd+R and let the typesetting window run forever. Each time a save is performed, the pdf previewer should update.

The above gives a very crude solution which doesn't work perfectly, but works most of the times.
To further enhance this solution, in my fork I modified further texparser.py so that LaTexMkParser.finish_run():
– is executed each time latexmk outputs "Latexmk: Log file says output ..."
– updates the pdf previewer. The 2nd item above then becomes obsolete, and even harmful.
– prints some additional html stuff (closes a <div> tag, links to the texlib.js script and displays Show Latexmk messages tickbox) which normally is output at the very end.

I'm curious of what you guys think of this idea (surely the solution needs many improvements), and of its advantages and disadvantages comparing to the Watch Document and the new notification window by René.

Cheers,
Szymon

[sanssecours]

Hi Szymon,

obviously I am quite biased :), but here is my take:

Advantages “PVC”:

• Clickable error messages
• Also displays error messages without line information

Advantages “Notification Window”:

• It automatically opens and closes itself if there are errors and therefore only uses space if it needs to.
• The window containing error messages is automatically in the front if it needs to be. Theoretically we are therefore instantly informed if there are any serious errors in the document.
• Nicer looking error messages — error messages in the HTML output can become quite messy
• It's in the current form — in my opinion — more or less ready for deployment

Could you maybe test the changes in latex_watch_notification and report if it works for you? That would be super nice of you.

Kind regards,
René

[szymtor]

Hi René

I agree with your evaluation. To your list, I would add the following.

Advantages "PVC":

• gives full power of latexmk (e.g. automatically performs bibtex)
• allows to use javascript for adding more control options in the output window (such as the "show/hide latexmk messages", "show/hide hbox,vbox warnings")
• allows to use the already existing html output formatters, and the existing infrastructure (e.g. the gutter icons are for free)

Advantages "Notification Window":

• faster (seems to be)
• less bulky window

As to your remark about nicer looking error messages, I think that html error messages might be easier to read, if they are well formatted. Since "PVC" uses the standard parsers, it is enough to focus on enhancing their output (e.g. by modifying the css). Also, I have a question regarding your other remark – is there no way of bringing the html output window into focus when needed?

The two approaches, even though they yield a similar outcome, have completely different origins
and both are fixing shortcomings of the current latex bundle – on the one hand, the annoying dialog windows of the Watch Document informing about the errors which it is unable to display, and on the other hand, the inability to run latexmk with its very valuable pvc option.
Perhaps it would be a good idea to incorporate both features?
(btw: I commited a new version of the PVC approach
szymtor@2d687f6 with many improvements).

Best regards,
Szymon

P.S. I tested briefly your latex_watch_notification. All worked pretty well, there were only minor problems e.g. the error notifying an unclosed "itemize" environment displayed as follows:

ERROR main.tex:191 — LaTeX Error: �egin{itemize} on input line 170 ended by end{document}.

Another problem – which is also apparent in the PVC approach – is in the following scenario:
watch a document with some error, then stop the watch and run another watch; the new watch does not inform about the error in the first run.

P.P.S. If you would be so nice to have a look at my newest commit, I'd be very grateful for any comments. Currently, the pvc mode is enabled in the latex preference pane.

[sanssecours]

Hi Szymon,

gives full power of latexmk (e.g. automatically performs bibtex)

“Watch Document” always uses latexmk to translate a file (see pull request #88).

allows to use the already existing html output formatters, and the existing infrastructure (e.g. the gutter icons are for free)

Since latex_watch internally uses texparser, updating of the gutter icons is for “free” in latex_watch_notification too.

As to your remark about nicer looking error messages, I think that html error messages might be easier to read, if they are well formatted. Since "PVC" uses the standard parsers, it is enough to focus on enhancing their output (e.g. by modifying the css).

The error messages should in theory all be well formatted. They do not use consistent formatting tough :). The problem that I see with the HTML output is the asynchronous update in texlib.js, which sometimes produces broken HTML.

Also, I have a question regarding your other remark – is there no way of bringing the html output window into focus when needed?

None that I know of.

The two approaches, even though they yield a similar outcome, have completely different origins and both are fixing shortcomings of the current latex bundle – on the one hand, the annoying dialog windows of the Watch Document informing about the errors which it is unable to display, and on the other hand, the inability to run latexmk with its very valuable pvc option.

I looked at the pvc option myself when I initially updated “latex_watch”. As far as I know it basically does the same as latex_watch: It continuously updates the PDF generated from a tex file, with the difference that latex_watch also tells the PDF viewer to update the view when it is done translating a file. latex_watch should also be a little faster since it knows exactly when the tex file was changed. Could you think of an advantage of latexmk -pvc over using latex_watch?

Perhaps it would be a good idea to incorporate both features?

I think merging both branches would mean additional complexity without much improvement overall, since the features are so similar.

I tested briefly your latex_watch_notification. All worked pretty well, there were only minor problems e.g. the error notifying an unclosed "itemize" environment displayed as follows:
ERROR main.tex:191 — LaTeX Error: egin{itemize} on input line 170 ended by end{document}.

Thanks a lot. I fixed the issue in commit 83597cd.

Another problem – which is also apparent in the PVC approach – is in the following scenario: watch a document with some error, then stop the watch and run another watch; the new watch does not inform about the error in the first run.

Yeah, I was to lazy to implement this until now. Maybe I will add the code for this feature sometimes in the future. For now you can just close the viewer window which will close latex_watch and remove all auxiliary files. This means in the next run latexmk will generate the PDF and the corresponding error messages anew.

P.P.S. If you would be so nice to have a look at my newest commit, I'd be very grateful for any comments. Currently, the pvc mode is enabled in the latex preference pane.

In my short test everything seemed to work fine. Good work. Here are some of my personal nitpicks, that most people do not care about at all :):

• The current changes break some of the unit tests (to run the test invoke make via ⌘B)
• I am a big fan of following coding styles. flake8 outputs multiple messages that code is not formatted according to the rules specified in the various PEPs. You can check a file in TextMate by using the shortcut ^⇧V. You might have to set TM_PYCHECKER to flake8 for this to work.
• Please use rebase instead of merge. It is much easier to follow changes in a linear history.

Kind regards,
René

[szymtor]

Hi René,

“Watch Document” always uses latexmk to translate a file (see pull request #88).

I wasn't aware of that. Is it possible to have Watch Document run bibtex automatically?

I looked at the pvc option myself when I initially updated “latex_watch”. As far as I know it basically
does the same as latex_watch: It continuously updates the PDF generated from a tex file, with the
difference that latex_watch also tells the PDF viewer to update the view when it is done translating a
file. latex_watch should also be a little faster since it knows exactly when the tex file was changed.
Could you think of an advantage of latexmk -pvc over using latex_watch?

Since latex_watch now also uses latexmk, I cannot come up with any real advantages. One thing I can think of is for consistency – since latexmk is such a nice tool, it would be nice to be able to choose its options in the Latex Preferences dialog, one of them being -pvc.

I think merging both branches would mean additional complexity without much improvement overall, since the features are so similar.

It's true, they are very similar. I must say though that I like the html output.

In my short test everything seemed to work fine. Good work.

Thanks a lot!

Here are some of my personal nitpicks, that most people do not care about at all :):

Thanks for the tips, I am new both to Python and to Git. I will keep them in mind.

All the best,
Szymon

[sanssecours]

Hi Szymon,

Is it possible to have Watch Document run bibtex automatically?

it should do so without the need to configure anything. Running latex_watch — at least in theory — results in the same output as “Typeset & View (PDF)” with the option “Use Latexmk” enabled. You can test this yourself by running “Watch Document” on external_bibliography_biber.tex.

One thing I can think of is for consistency – since latexmk is such a nice tool, it would be nice to be able to choose its options in the Latex Preferences dialog, one of them being -pvc.

One option for advanced user is to configure latexmk via a settings file. To always use the option pvc you can for example create the file ~/.latexmkrc with the following content:

$preview_continuous_mode = 1;
$force_mode              = 0;
$preview_mode            = 0;
$printout_mode           = 0;

Since texmate and latex_watch just call latexmk they will pick up these settings too. Both tools might however not react the way we want them to, to larger changes like the one described above.

Kind regards,
René

P.S.: I merged the changes from latex_watch_notification into master and will close the issue for now. If anyone has problems with the new code: Please feel free to reopen this issue, open a new one or just comment below this one.