On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote: > > > Am 18.02.2020 um 19:55 schrieb Enrico Forestieri <for...@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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
