[texworks] TeXworks 0.6.6 released

[Stefan Löffler]

Dear Philip,

On 23.03.21 13:39, Philip Taylor wrote:
> A buglet report, Stefan.  Let 0.6.6 be freshly installed, and
> launched.  Let the following content be pasted into the source window :
>
>> [...]
>
> Let TeXworks be asked to find all occurrences of DOLLAR.  It does so,
> but when one clicks on either the first or second instance found, one
> is told :
>
>> Cannot read file "C:/TeX/Works/untitled-1.tex";
>> The system cannot read from the file specified.
>
> I very much doubt that this is a new buglet, but it may well be a
> previously unreported one.

Indeed, this buglet must have been around for (probably) years. Thanks
for reporting! It should hopefully be fixed as of today.

Background: the search results were identified by the filename (as
listed in the search results table). For unsaved files, this of course
is a dummy name (I think the one suggested automatically when you first
click on "Save"). Trying to access such a file naturally fails.
In the newest development version (as of today), the code keeps an
additional reference to the window displaying the document the search
result was found in and uses that if at all possible (i.e., the window
has not been closed since the search). This should fix the problem with
unsaved files, but also the problem with saving the file under a
different name (or any name for the first time) after performing the search.

To highlight the "unsaved" nature, the filename will be displayed in
italic with an appended "*" in applicable search results.

On 23.03.21 13:46, Philip Taylor wrote:
>> However, the following bug (as opposed to buglet) may well be new. 
>> Let the same file then be saved as D:\untitled-1.tex.  When one now
>> clicks on the first or the second found occurrence, one is again told :
>
>> Cannot read file "C:/TeX/Works/untitled-1.tex";
>> The system cannot read from the file specified.
>
> Why does TeXworks not know that the file has been saved as
> D:\untitled-1.tex ?  IThe title bar no longer ends in an asterisk
> (indicating 'unsaved'), but its search code is still searching the
> earlier, never-existed, copy.  Only by clearing the search and
> searching again does one experience the expected behaviour.

The search results are static, meaning they are not updated once the
search is completed (this applies not only to the filename, but also to
the line number, text, etc.). As such, if you perform any changes to the
files (be it edits to the text, changing the filename, or whatever), the
search results will likely become more and more out of sync. AFAIK, the
same behavior can be found in most other text editors. Changing that
(i.e., making the search results dynamic/smart) would probably require
quite a lot of code changes, and would potentially impact the speed of
editing (imagine having several large documents open, a lot of search
results, and each edit in each document would somehow have to update all
search results).

HTH,
Stefan