[RFC][PATCH] Change to buffer lookup for given temporary files

Enrico Forestieri forenr at lyx.org
Thu Feb 20 07:24:41 UTC 2020


On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> 
> > 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?

Yes, I think so.

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

Yes, at the time it was not possible using Qt in src/support.

-- 
Enrico


More information about the lyx-devel mailing list