[RFC][PATCH] Change to buffer lookup for given temporary files
Stephan Witt
st.witt at gmx.net
Wed Feb 19 21:33:45 UTC 2020
> Am 18.02.2020 um 19:55 schrieb Enrico Forestieri <forenr at lyx.org>:
>
> On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
>> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
>>>
>>> Because I’m unable to test it with other PDF viewers with SyncTeX
>>> support and/or to test it on Linux and Windows I post the patch
>>> and it would be nice if you can test if it breaks something used
>>> to work.
>>
>> It works for me on linux and cygwin, but does not on native windows.
>> Inserting some debug statements just before file_name and realtmp are
>> compared produces the following (I use C:/cygwin/tmp as the tempdir):
>>
>> file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX
>> realtmp: C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun
>>
>> Seemingly, the real path of file_name is returned in the short form, while
>> that of realtmp is not. I don't know why.
>
> Replacing the following two lines:
>
> file_name = os::internal_path(trim(argument.substr(0, i)));
> file_name = FileName(file_name).realPath();
>
> with
> file_name = os::internal_path(FileName(trim(argument.substr(0, i))).realPath());
>
> it works also on native windows.
So, with this modification the patch would be acceptable?
I’ve attached it with your modification.
> Apparently, the only purpose of
> internal_path() on windows is returning the long form of the path
> (other than converting backslashes into slashes).
Yes, indeed. The implementation of internal_path() on windows uses the
GetLongPathNameW() function.
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getlongpathnamew
> Still, why realPath() returns a short path name in one case and not in the
> other case remains a mystery.
A lookup of the implementation of it in os_win32.cpp shows the beauty
of the Windows APIs. =8(
What I wonder: there are the Qt elements used. Why don’t we rely
on the services of QFileInfo class? E.g. canonicalFilePath() and
friends? Are there historical reasons only?
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: goToFileRow-6.patch
Type: application/octet-stream
Size: 3843 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200219/98f251af/attachment-0001.obj>
More information about the lyx-devel
mailing list