Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I have a list of dates for the LyX meeting in Paris. Jean-Marc Unfortunately it is a bit short, but we'll see if they suit Jean-Marc enough people to be useful. So it sound the dates are not too bad. Let's see who answered already: Jul 16Jul 23Jul 30 Aug 06 JMarc 5 5 5 5 Jose' 5 5 0 0 Lars 5 5 5 5 Michael5 0 0 0 Andre' 5 5 5 5 Alfredo0 0 0 0 Asger 0 0 3 5 Of course, I made up the numbers :) Feel free to correct me. Concerning other dates, it will be more difficult for me, especially since only school stops around Jul 12. And later in August, I will have difficulties to avoid family vacations... Who else is wanting to come? All answers are appreciated, even ``I can't tell you yet'' or ``I'd hate to be there''. I can't tell you yet for sure, but it looks like it happens to me to stay in Paris appr. from 8th of July til 20th of July. I'll have a trip for these days with my family and I'm interested in visiting the LyX meeting. And as always, everybody is welcome. If my appartment turns out to be too small, I have both a plan B and a plan C. So I would say you may add my name for Jul 16 ranked 4 and ranked 0 for the rest of time. Of course my name shouldn't weight to much on this list. I cannot contribute any hardware but I don't need a bed for the night. And I'm not a beer drinker :) Greetings, Stephan
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: Asger == Asger Ottar Alstrup [EMAIL PROTECTED] writes: Asger No good for me. We bought a house in Turkey, and we are going Asger there to see it, decorate it, and enjoy it for three weeks Asger starting from the second week of July. Is there internet access there? Just wondering... Not yet. In fact, the houst is being built, so when we get there, it will be completely empty. Next year, or maybe the year after that, we might have a LyX meeting there. Regards, Asger
Re: [PATCH] Can't test due to broken QDocumentDialog.h
Angus Leeming [EMAIL PROTECTED] writes: | Helge Hafting wrote: In file included from QDocumentDialog_moc.C:11: ../QDocumentDialog.h:90: error: parse error before `' token ../QDocumentDialog.h:99: error: parse error before `==' token ../QDocumentDialog.h:108: error: parse error before `' token This file wasn't touched by the patch, but it broke the compile. This did not happen earlier today, so I believe it has to be a recent patch. | There is a CVS conflict; CVS has updated the file and found that your | version of some lines in the file is different what it thinks those | lines should be. Try removing the file and running | cvs update src/frontends/qt2/QDocumentDialog.h The trick is: cvs up -C src/frontends/qt2/QDocumentDialog.h, without removing the file first. -- Lgb
Re: LyX meeting in Paris. When?
Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger Jean-Marc Lasgouttes wrote: Asger == Asger Ottar Alstrup [EMAIL PROTECTED] writes: Asger No good for me. We bought a house in Turkey, and we are going Asger there to see it, decorate it, and enjoy it for three weeks Asger starting from the second week of July. Is there internet access there? Just wondering... Asger Not yet. In fact, the houst is being built, so when we get Asger there, it will be completely empty. Next year, or maybe the Asger year after that, we might have a LyX meeting there. Where is it? JMarc
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: Where is it? It's in Yalkarvak on the Bodrum peninsula: http://www.mapquest.com/maps/map.adp?searchtype=addresscountry=TRformtype=addressaddtohistory=location=OByyLVuYfVoegQSvvFGo%2fWzHZknBIaN2HHB8D4nTDC%2bHL2sp1al0NOwvQrj%2fvi%2bhLY%2bt4CeuxqZO5qxTCTRMqXx3Y6o%2fa0E1 Regards, Asger
Re: LyX meeting in Paris. When?
Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger Jean-Marc Lasgouttes wrote: Where is it? Asger It's in Yalkarvak on the Bodrum peninsula: So now you get to use dotless in everyday life. I am sure this geekness factor was a good reason to pick the place. I do not know much this part of Turkey, but it is said to be very nice... JMarc PS: Google tends to think you meant Yalkavak instead.
Re: LyX meeting in Paris. When?
New updated list looks like: Jul 16Jul 23Jul 30 Aug 06 JMarc 5 5 5 5 Jose' 5 5 0 0 Lars 5 5 5 5 Michael5 0 0 0 Andre' 5 5 5 5 Alfredo0 0 0 2 Asger 0 0 3 5 Stephan4 0 0 0 Will not be able to come: Juergen S., John L. (I upped Alfredo to a 2 for Aug 06, the 0 was a mistake...). JMarc
Re: LyX meeting in Paris. When?
John == John Levon [EMAIL PROTECTED] writes: John On Mon, Apr 18, 2005 at 05:15:32PM +0200, Jean-Marc Lasgouttes John wrote: Who else is wanting to come? All answers are appreciated, even ``I can't tell you yet'' or ``I'd hate to be there''. John Yet again (sigh) it's extremely unlikely I can make it... sigh, indeed. JMarc
Re: LyX meeting in Paris. When?
Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan I can't tell you yet for sure, but it looks like it happens Stephan to me to stay in Paris appr. from 8th of July til 20th of Stephan July. I'll have a trip for these days with my family and Stephan I'm interested in visiting the LyX meeting. You will be very welcome. Stephan So I would say you may add my name for Jul 16 ranked 4 and Stephan ranked 0 for the rest of time. I did that. Stephan Of course my name shouldn't weight to much on this list. I Stephan cannot contribute any hardware but I don't need a bed for the Stephan night. And I'm not a beer drinker :) Everybody weights (even beer non-drinkers). JMarc
Re: LyX meeting in Paris. When?
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Jean-Marc Lasgouttes wrote: - who will not be able to come, whatever the date? Juergen Me. The agenda is again too overloaded this summer, I'm Juergen afraid :-( Too bad, really. Next time, maybe? JMarc
Re: configure test for GetLongPathNameA ?
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I give up! I would like to write a configure test for the Angus existence of GetLongPathNameA. Since existence of such things for various windows versions is well documented, I'd say that you should condition on windows version. Why do you need GetLongPathNameA instead of GetLongPathName? What windows versions do not know about it? JMarc
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: I do not know much this part of Turkey, but it is said to be very nice... Yes, I like it a lot. It is not as humid as the area around Alanya and Antalya. It is a bit expensive compared to other areas of Turkey, but still cheap compared to Denmark. PS: Google tends to think you meant Yalkavak instead. And Google is right. I notice right after I clicked send, but the undo stack is flushed when you click Send in my mail program, so there is nothing I could do about it. Regards, Asger
Re: [PATCH] patch worked as advertised
Lars Gullik Bjnnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Helge Hafting wrote: In file included from QDocumentDialog_moc.C:11: ../QDocumentDialog.h:90: error: parse error before `' token ../QDocumentDialog.h:99: error: parse error before `==' token ../QDocumentDialog.h:108: error: parse error before `' token This file wasn't touched by the patch, but it broke the compile. This did not happen earlier today, so I believe it has to be a recent patch. | There is a CVS conflict; CVS has updated the file and found that your | version of some lines in the file is different what it thinks those | lines should be. Try removing the file and running | cvs update src/frontends/qt2/QDocumentDialog.h The trick is: cvs up -C src/frontends/qt2/QDocumentDialog.h, without removing the file first. My cvs did not understand -C But removing the file and then doing cvs update filename worked. The patch worked, I can again turn emphasis on and off as I wish. Helge Hafting
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: Too bad, really. Next time, maybe? Yes, I hope to make it possible eventually. I'd really appreciate to have a beer with you guys. Jürgen
Re: configure test for GetLongPathNameA ?
Jean-Marc Lasgouttes wrote: Angus I give up! I would like to write a configure test for the Angus existence of GetLongPathNameA. Since existence of such things for various windows versions is well documented, I'd say that you should condition on windows version. Yes, but how? The function declaration is protected in /mingw/include/winbase.h by macros _WIN32_WINDOWS (not defined) and _WIN32_WINNT: #if (_WIN32_WINNT = 0x0500 || _WIN32_WINDOWS = 0x0410) WINBASEAPI DWORD WINAPI GetLongPathNameA(LPCSTR,LPSTR,DWORD); WINBASEAPI DWORD WINAPI GetLongPathNameW(LPCWSTR,LPWSTR,DWORD); #endif In turn, _WIN32_WINNT is defined in /mingw/include/windef.h: #ifndef WINVER #define WINVER 0x0400 /* * If you need Win32 API features newer the Win95 and WinNT then * you must define WINVER before including windows.h or any other * method of including the windef.h header. */ #endif #define _WIN32_WINNT WINVER So, really, truly, the header files aren't helping any. Hence the need for a configure test to see whether the function is present in the standard library. Why do you need GetLongPathNameA instead of GetLongPathName? GetLongPathName is just a #define for GetLongPathNameA in this case. #ifdef UNICODE #else #if (_WIN32_WINNT = 0x0500 || _WIN32_WINDOWS = 0x0410) #define GetLongPathName GetLongPathNameA #endif What windows versions do not know about it? Windows 95 and Windows NT and earlier. Angus
Re: [PATCH] patch worked as advertised
On Tue, 2005-04-19 at 12:31, Helge Hafting wrote: Lars Gullik Bjnnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Helge Hafting wrote: In file included from QDocumentDialog_moc.C:11: ../QDocumentDialog.h:90: error: parse error before `' token ../QDocumentDialog.h:99: error: parse error before `==' token ../QDocumentDialog.h:108: error: parse error before `' token This file wasn't touched by the patch, but it broke the compile. This did not happen earlier today, so I believe it has to be a recent patch. | There is a CVS conflict; CVS has updated the file and found that your | version of some lines in the file is different what it thinks those | lines should be. Try removing the file and running | cvs update src/frontends/qt2/QDocumentDialog.h The trick is: cvs up -C src/frontends/qt2/QDocumentDialog.h, without removing the file first. My cvs did not understand -C But removing the file and then doing cvs update filename worked. The patch worked, I can again turn emphasis on and off as I wish. Helge Hafting Did you notice anything else fishy? Esp. with languages. Maybe you noticed that you cannot now switch languages on the fly while writing: you have to select first and then apply. Not that you would often want to do that. - Martin PS. I still think that this is not the _right_ fix for the problem. That would be to assure that everytime a lyxtext is created, current_font and real_current_font are set to the buffer defaults. But I see no easy way to do that, and I did try. This fix is good enough for 1.4.0, I think. signature.asc Description: This is a digitally signed message part
Re: [PATCH] patch worked as advertised
Helge Hafting [EMAIL PROTECTED] writes: The trick is: cvs up -C src/frontends/qt2/QDocumentDialog.h, without removing the file first. | My cvs did not understand -C But removing the file and then Hmm then your cvs should be upgraded. | doing cvs update filename worked. The patch worked, | I can again turn emphasis on and off as I wish. good -- Lgb
Re: configure test for GetLongPathNameA ?
Angus Leeming wrote: So, really, truly, the header files aren't helping any. Hence the need for a configure test to see whether the function is present in the standard library. I asked on the autoconf list autoconf test for dllimport-ed function? http://news.gmane.org/gmane.comp.sysutils.autoconf.general The reply just back is that no test currently exists but I should consider submitting one :) quote | Any suggestions? You should be able to use AC_TRY_COMPILE or AC_COMPILE_IFELSE to create a macro, say AC_CHECK_WINDOWS_FUNCS, which does something like AC_CHECK_FUNCS for MSYS. Obviously, such a thing will not be very portable. But if it turns out to be useful, the autoconf archive might want to include it. /quote Looking at the autoconf macro archive, wouldn't this fit the bill? http://autoconf-archive.cryp.to/ac_check_func_in.html AC_CHECK_FUNC_IN(windows.h, GetLongPathName) However, when I come to run autogen.sh on it, I get: configure.ac:257: error: AC_LANG: unknown language: autoconf/lang.m4:123: _AC_LANG_SET is expanded from... autoconf/lang.m4:132: AC_LANG is expanded from... autoconf/general.m4:1799: AC_CACHE_VAL is expanded from... acinclude.m4:800: AC_CHECK_FUNC_IN is expanded from... configure.ac:257: the top level autom4te: /bin/m4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 Patch attached. Any clues? Wrapping it in AC_LANG_PUSH(C)... POP doesn't have any effect. Angus Index: config/configure.ac === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/Attic/configure.ac,v retrieving revision 1.24.2.31 diff -u -a -u -r1.24.2.31 configure.ac --- config/configure.ac 30 Mar 2005 14:50:53 - 1.24.2.31 +++ config/configure.ac 19 Apr 2005 09:11:58 - @@ -254,6 +254,7 @@ AC_TYPE_UID_T AC_CHECK_FUNCS(snprintf vsnprintf strerror) +AC_CHECK_FUNC_IN(windows.h, GetLongPathName) LYX_CHECK_DECL(snprintf, stdio.h) LYX_CHECK_DECL(vsnprintf, stdio.h) LYX_CHECK_DECL(istreambuf_iterator, iterator) Index: config/lyxinclude.m4 === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/lyxinclude.m4,v retrieving revision 1.81.2.7 diff -u -a -u -r1.81.2.7 lyxinclude.m4 --- config/lyxinclude.m44 Feb 2005 09:14:24 - 1.81.2.7 +++ config/lyxinclude.m419 Apr 2005 09:13:38 - @@ -750,3 +750,51 @@ [Define if mkdir takes only one argument.]) fi ]) + +dnl Checking for library functions in a given header file +dnl +dnl @category Misc +dnl @author Guido Draheim [EMAIL PROTECTED] +dnl @version 2001-05-03 +dnl @license GPLWithACException +dnl http://autoconf-archive.cryp.to/ac_check_func_in.html + +dnl AC_CHECK_FUNC_IN(HEADER, FUNCTION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]) +AC_DEFUN([AC_CHECK_FUNC_IN], +[AC_MSG_CHECKING([for $2 in $1]) +AC_CACHE_VAL(ac_cv_func_$2, +[AC_TRY_LINK( +dnl Don't include ctype.h because on OSF/1 3.0 it includes sys/types.h +dnl which includes sys/select.h which contains a prototype for +dnl select. Similarly for bzero. +[/* System header to define __stub macros and hopefully few prototypes, +which can conflict with char $2(); below. */ +#include assert.h +#include $1 +/* Override any gcc2 internal prototype to avoid an error. */ +]ifelse(AC_LANG, CPLUSPLUS, [#ifdef __cplusplus +extern C +#endif +])dnl +[/* We use char because int might match the return type of a gcc2 +builtin and then its argument prototype would still apply. */ +char $2(); +], [ +/* The GNU C library defines this for functions which it implements +to always fail with ENOSYS. Some functions are actually named +something starting with __ and the normal name is an alias. */ +#if defined (__stub_$2) || defined (__stub___$2) +choke me +#else +$2(); +#endif +], eval ac_cv_func_$2=yes, eval ac_cv_func_$2=no)]) +if eval test \`echo '$ac_cv_func_'$2`\ = yes; then + AC_MSG_RESULT(yes) + ifelse([$3], , :, [$3]) +else + AC_MSG_RESULT(no) +ifelse([$4], , , [$4 +])dnl +fi +])
Re: configure test for GetLongPathNameA ?
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Looking at the autoconf macro archive, wouldn't this fit the Angus bill? http://autoconf-archive.cryp.to/ac_check_func_in.html Angus AC_CHECK_FUNC_IN(windows.h, GetLongPathName) But it does not do anything special related to windows, does it? Angus However, when I come to run autogen.sh on it, I get: Angus configure.ac:257: error: AC_LANG: unknown language: It uses AC_LANG as a variable, whereas it is a macro with argument. I'd propose to drop this macro. Looking at functions.m4 in autoconf data directory, I see: # AC_CHECK_FUNC(FUNCTION, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # - AC_DEFUN([AC_CHECK_FUNC], [AS_VAR_PUSHDEF([ac_var], [ac_cv_func_$1])dnl AC_CACHE_CHECK([for $1], ac_var, [AC_LINK_IFELSE([AC_LANG_FUNC_LINK_TRY([$1])], [AS_VAR_SET(ac_var, yes)], [AS_VAR_SET(ac_var, no)])]) AS_IF([test AS_VAR_GET(ac_var) = yes], [$2], [$3])dnl AS_VAR_POPDEF([ac_var])dnl ])# AC_CHECK_FUNC # AC_CHECK_FUNCS(FUNCTION..., [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # - AC_DEFUN([AC_CHECK_FUNCS], [AC_FOREACH([AC_Func], [$1], [AH_TEMPLATE(AS_TR_CPP(HAVE_[]AC_Func), [Define to 1 if you have the `]AC_Func[' function.])])dnl for ac_func in $1 do AC_CHECK_FUNC($ac_func, [AC_DEFINE_UNQUOTED([AS_TR_CPP([HAVE_$ac_func])]) $2], [$3])dnl done ]) So, all you'd have to do would be to make a copy of these two macros and change AC_CHECK_WINDOWS_FUNC to invoke your own version of AC_LANG_FUNC_LINK_TRY(C), which is in c.m4. Of course, then you will need a different version for autoconf 2.13... JMarc
Re: configure test for GetLongPathNameA ?
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: I give up! I would like to write a Angus configure test for the existence of GetLongPathNameA. Since existence of such things for various windows versions is well documented, I'd say that you should condition on windows version. Angus Yes, but how? OK, did you see this? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp It seems that under windows they have some way to allow calling unimplemented functions. The only thing is that they will return an error. Isn't this the natural way of using GetLongPathName? I would say that just testing whether the return code is 0 would be enough. No need to lookup GetLastError. JMarc
Re: configure test for GetLongPathNameA ?
Jean-Marc Lasgouttes wrote: OK, did you see this? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp It seems that under windows they have some way to allow calling unimplemented functions. The only thing is that they will return an error. Isn't this the natural way of using GetLongPathName? I would say that just testing whether the return code is 0 would be enough. No need to lookup GetLastError. Jean-Marc, you are a wizard! Thank you. Angus
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: New updated list looks like: Jul 16Jul 23Jul 30 Aug 06 JMarc 5 5 5 5 Jose' 5 5 0 0 Lars 5 5 5 5 Michael5 0 0 0 Andre' 5 5 5 5 Alfredo0 0 0 2 Asger 0 0 3 5 Stephan4 0 0 0 Will not be able to come: Juergen S., John L. (I upped Alfredo to a 2 for Aug 06, the 0 was a mistake...). Thanks! Dates before Jul 16 are out of the question, right? Regards, Alfredo
Re: LyX meeting in Paris. When?
Alfredo == Alfredo Braunstein [EMAIL PROTECTED] writes: Alfredo Dates before Jul 16 are out of the question, right? The problem is that my wife works at 200km from Paris and our children will still have to attend school, so things will be very difficult for us. I can try again to find a solution, but don't hold your breath. JMarc
[PATCH 14x] fix support/pch.h on Windows
Trivial patch that prevents unix-specific headers from breaking compilation on Windows. Committing now. -- AngusIndex: src/support/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v retrieving revision 1.332 diff -u -p -r1.332 ChangeLog --- src/support/ChangeLog 18 Apr 2005 17:43:11 - 1.332 +++ src/support/ChangeLog 19 Apr 2005 12:04:16 - @@ -1,4 +1,9 @@ - 2005-04-17 Angus Leeming [EMAIL PROTECTED] +2005-04-19 Angus Leeming [EMAIL PROTECTED] + + * pch.h: protect unix-specific headers from breaking compilation + on Windows. + +2005-04-17 Angus Leeming [EMAIL PROTECTED] * filetools.C (MakeDisplayPath): invoke os::external_path before returning path. Index: src/support/pch.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/pch.h,v retrieving revision 1.5 diff -u -p -r1.5 pch.h --- src/support/pch.h 20 Jan 2005 15:38:14 - 1.5 +++ src/support/pch.h 19 Apr 2005 12:04:16 - @@ -15,13 +15,13 @@ #include boost/utility.hpp #include fcntl.h -#include sys/socket.h #include sys/stat.h #include sys/types.h -#include sys/un.h -#include sys/wait.h #include time.h -#ifdef HAVE_UNISTD_H +#ifndef _WIN32 +# include sys/socket.h +# include sys/un.h +# include sys/wait.h # include unistd.h #endif
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: Alfredo Dates before Jul 16 are out of the question, right? The problem is that my wife works at 200km from Paris and our children will still have to attend school, so things will be very difficult for us. I can try again to find a solution, but don't hold your breath. No, please don't bother, I was just curious. Alfredo
Re: LyX meeting in Paris. When?
On Fri, 2005-04-15 at 16:56, Jean-Marc Lasgouttes wrote: I have a list of dates for the LyX meeting in Paris. Unfortunately it is a bit short, but we'll see if they suit enough people to be useful. I just give the dates of the corresponding saturdays. The idea would be to meet for 4-5 days around that. The dates are: Jul 16 Jul 23 Jul 30 Aug 06 The questions are: - who would be able to come at one of these dates? - who would like to come, but not at these dates? - who will not be able to come, whatever the date? For now I propose to do this at my new home, where I could provide accommodation for 7-8 people. If more people want to come, I think I can come up with something else. JMarc I don't think that I can make it. All our money went to the summer cottage :-( - Martin signature.asc Description: This is a digitally signed message part
[PATCH 13x, 14x] GetLongPathName on Windows
I think that this one is now resolved, so I'll commit these now. -- AngusIndex: src/support/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v retrieving revision 1.149.2.40 diff -u -p -r1.149.2.40 ChangeLog --- src/support/ChangeLog 18 Apr 2005 17:44:05 - 1.149.2.40 +++ src/support/ChangeLog 19 Apr 2005 12:15:14 - @@ -1,3 +1,7 @@ +2005-04-19 Angus Leeming [EMAIL PROTECTED] + + * package.C (get_temp_dir): call GetLongPathName on Windows. + 2005-04-17 Angus Leeming [EMAIL PROTECTED] * filetools.C (MakeDisplayPath): invoke os::external_path before Index: src/support/package.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/Attic/package.C,v retrieving revision 1.1.2.3 diff -u -p -r1.1.2.3 package.C --- src/support/package.C 17 Jan 2005 11:50:16 - 1.1.2.3 +++ src/support/package.C 19 Apr 2005 12:15:15 - @@ -35,6 +35,24 @@ #if defined (USE_WINDOWS_PACKAGING) + +/* + * MinGW's version of winver.h contains this comment: + * + * If you need Win32 API features newer the Win95 and WinNT then you must + * define WINVER before including windows.h or any other method of including + * the windef.h header. + * + * GetLongPathNameA requires WINVER == 0x0500. + * + * It doesn't matter if the Windows version is older than this because the + * function will compile but will fail at run time. See + * http://msdn.microsoft.com/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp + */ +# if defined(__MINGW32__) +# define WINVER 0x0500 +# endif + # include windows.h # include shlobj.h // SHGetFolderPath @@ -299,6 +317,7 @@ string const get_temp_dir() // Typical example: C:/TEMP/. char path[PATH_MAX + 1]; GetTempPath(PATH_MAX, path); + GetLongPathName(path, path, PATH_MAX + 1); return os::internal_path(path); #else // Posix-like. return /tmp; Index: src/support/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v retrieving revision 1.333 diff -u -p -r1.333 ChangeLog --- src/support/ChangeLog 19 Apr 2005 12:12:47 - 1.333 +++ src/support/ChangeLog 19 Apr 2005 12:14:28 - @@ -1,5 +1,9 @@ 2005-04-19 Angus Leeming [EMAIL PROTECTED] + * package.C.in (get_temp_dir): call GetLongPathName on Windows. + +2005-04-19 Angus Leeming [EMAIL PROTECTED] + * pch.h: protect unix-specific headers from breaking compilation on Windows. Index: src/support/package.C.in === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/package.C.in,v retrieving revision 1.9 diff -u -p -r1.9 package.C.in --- src/support/package.C.in 15 Feb 2005 13:45:40 - 1.9 +++ src/support/package.C.in 19 Apr 2005 12:14:28 - @@ -38,6 +38,24 @@ #endif #if defined (USE_WINDOWS_PACKAGING) + +/* + * MinGW's version of winver.h contains this comment: + * + * If you need Win32 API features newer the Win95 and WinNT then you must + * define WINVER before including windows.h or any other method of including + * the windef.h header. + * + * GetLongPathNameA requires WINVER == 0x0500. + * + * It doesn't matter if the Windows version is older than this because the + * function will compile but will fail at run time. See + * http://msdn.microsoft.com/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp + */ +# if defined(__MINGW32__) +# define WINVER 0x0500 +# endif + # include windows.h # include shlobj.h // SHGetFolderPath @@ -363,6 +381,7 @@ string const get_temp_dir() // Typical example: C:/TEMP/. char path[PATH_MAX + 1]; GetTempPath(PATH_MAX, path); + GetLongPathName(path, path, PATH_MAX + 1); return os::internal_path(path); #else // Posix-like. return /tmp;
[PATCH 13x, 14x] child processes
These patches implement asynchronous loading of graphics in Windows.
The code on *nix is unchanged in the 1.3.x tree, apart from the removal of
some functions that are no longer called. (They were used by the dialog to
kill child processes but that went some time ago.)
The 1.4.x code on *nix *is* changed. Basically, I've reverted to the code
in LyX 1.3.x, for two reasons:
1. 'Issues' remain with the SIGCHLD handling code. (Read it's not robust).
2. Such a solution cannot be implemented on Windows and I want to minimize
the changes to get this Windows port working.
Going the 1.3.x way, explicitly polling for any completed child processes
is safe and robust and can be implemented with relatively little change on
Windows.
I won't commit these just yet, but will do so tomorrow unless there are any
strong objections.
Jean-Marc, that's basically it for the port of LyX 1.3.x to Windows.
There's another small patch to disable ispell support and the lyxserver
and to enable the autosave code to work (blocking). I attach this patch
also (win32_kludge_13x.diff)
We should also address the issue of accepting 'files with spaces' in the
dialogs, but that's not Windows-specific.
--
Angus
child_13x.diff.gz
Description: GNU Zip compressed data
child_14x.diff.gz
Description: GNU Zip compressed data
Index: src/ispell.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ispell.C,v
retrieving revision 1.5.2.5
diff -u -a -u -r1.5.2.5 ispell.C
--- src/ispell.C 7 Dec 2004 10:48:23 - 1.5.2.5
+++ src/ispell.C 15 Apr 2005 22:28:12 -
@@ -21,12 +21,28 @@
#include support/forkedcall.h
#include support/lstrings.h
+#ifdef _WIN32
+// sys/select.h
+# define FD_ZERO(a)
+# define FD_SET(a,b)
+# define FD_ISSET(fd, set) 0
+//sys/types.h
+# define fd_set int
+// unistd.h
+# define fork() -1
+# define pipe(a) _pipe(a,0,0)
+#endif
+
// HP-UX 11.x doesn't have this header
#ifdef HAVE_SYS_SELECT_H
#include sys/select.h
#endif
#include sys/time.h
+#ifdef HAVE_UNISTD_H
+# include unistd.h
+#endif
+
#ifndef CXX_GLOBAL_CSTD
using std::strcpy;
using std::strlen;
@@ -309,11 +325,15 @@
tv.tv_sec = 2;
tv.tv_usec = 0;
+#ifdef _WIN32
+ retval = -1;
+#else
retval = ::select(SELECT_TYPE_ARG1 (max(pipeout[0], pipeerr[0]) + 1),
SELECT_TYPE_ARG234 (infds),
0,
0,
SELECT_TYPE_ARG5 (tv));
+#endif
// error
if (retval = 0)
Index: src/lyx_cb.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_cb.C,v
retrieving revision 1.190.2.3
diff -u -a -u -r1.190.2.3 lyx_cb.C
--- src/lyx_cb.C 10 Jan 2005 19:17:24 - 1.190.2.3
+++ src/lyx_cb.C 15 Apr 2005 20:29:06 -
@@ -37,6 +37,11 @@
#include support/systemcall.h
#include support/lstrings.h
+#ifdef _WIN32
+// unistd.h
+# define fork() -1
+#endif
+
#include BoostFormat.h
#include fstream
Index: src/lyxserver.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxserver.C,v
retrieving revision 1.48.2.3
diff -u -a -u -r1.48.2.3 lyxserver.C
--- src/lyxserver.C 20 Jan 2005 10:47:28 - 1.48.2.3
+++ src/lyxserver.C 15 Apr 2005 22:22:20 -
@@ -36,14 +36,6 @@
#include config.h
-#include sys/types.h
-#include sys/stat.h
-#ifdef HAVE_UNISTD_H
-#include unistd.h
-#endif
-#include fcntl.h
-#include cerrno
-
#include lyxserver.h
#include debug.h
#include lyxfunc.h
@@ -51,14 +43,28 @@
#include support/lyxlib.h
#include frontends/lyx_gui.h
-#ifdef __EMX__
-#include cstdlib
-#include io.h
-#define OS2EMX_PLAIN_CHAR
-#define INCL_DOSNMPIPES
-#define INCL_DOSERRORS
-#include os2.h
-#include support/os2_errortable.h
+#include sys/types.h
+#include sys/stat.h
+#include cerrno
+#include fcntl.h
+
+#if defined (_WIN32)
+# define F_SETFD2
+# define F_SETFL4
+# define O_NONBLOCK 0x4000
+ inline int fcntl (int, int, ...) {return -1;}
+
+#elif defined (__EMX__)
+# include cstdlib
+# include io.h
+# define OS2EMX_PLAIN_CHAR
+# define INCL_DOSNMPIPES
+# define INCL_DOSERRORS
+# include os2.h
+# include support/os2_errortable.h
+
+#else // POSIX
+# include unistd.h
#endif
using std::endl;
Re: [PATCH 13x, 14x] child processes
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus These patches implement asynchronous loading of graphics in Angus Windows. The code on *nix is unchanged in the 1.3.x tree, apart Angus from the removal of some functions that are no longer called. Angus (They were used by the dialog to kill child processes but that Angus went some time ago.) I cannot do much to make sure that the new win32 code works, so I'll have to trust you on this :) Why do you use #if defined(_WIN32) instead of #ifdef _WIN32 like everywhere else? (this kind of useless remark is further proof that I do not have any real problem with the patch!) Angus Jean-Marc, that's basically it for the port of LyX 1.3.x to Angus Windows. There's another small patch to disable ispell support Angus and the lyxserver and to enable the autosave code to work Angus (blocking). I attach this patch also (win32_kludge_13x.diff) Concerning this patch, how difficult would it be to really disable the spellchecker and lyxserver under win32, that is to keep those two files unix-only? We should just make sure that it is possible to run LyX without any spellchecker or lyxserver. I guess this is what Lars will request for 1.4.0cvs, so if it is not too disruptive we might as well do it here. The idea would be for ispell to disable its support when select() is not available, for example. Angus We should also address the issue of accepting 'files with Angus spaces' in the dialogs, but that's not Windows-specific. Yes. JMarc
Re: lyxrc.tex_allow_spaces and the frontends
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc has added a configure test to ascertain Angus whether LaTeX can understand file names containing spaces. Angus However, lyxrc.tex_allows_spaces seems a little arbitrary. Angus Perhaps a LyXRC string variable lyxrc.tex_file_special_chars Angus which would be set to ~ if the TeX version was sufficiently Angus modern? I am not sure that it is arbitrary. Unless you can prove me false, I believe that _all_ TeX implementation have the same behaviour wrt at least ~. If we can prove that some characters are not handled identically by various TeXs, then it will be time to adapt. I believe that the problem with space is related to the syntax of file-related primitives as Knuth implemented them. Another problem which is probably version-dependent is the acceptance of 8bit characters. But I'd like to understand better what versions are impacted before acting on that. Angus In fact, I think that adding the test to the file name widget Angus itself is a much better idea. Let's scrap the check in the Angus Browser and instead highlight the offending widget in Angus red/deactivate the Ok,Apply buttons in the dialog. This is definitely a good idea, especially since few files will require it. JMarc
Re: [PATCH 13x] paths
Angus == Angus Leeming [EMAIL PROTECTED] writes: This stuff with dvi rewriting is not really something I like :) Did you try to contact the miktex and/or web2c people about it? It seems that the bug is more in tex than in the dvi tools: the extra quotes should not be there... Angus Granted. But people are going to be using these buggy tools for Angus a while, so we need to devise a work-around. I can certainly Angus contact the web2c people too. Do they have a newsgroup? Did you try to contact the tex-k list? http://www.tug.org/mailman/listinfo/tex-k JMarc
Re: [PATCH] Various counter-related fixes
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc If no problems are uncovered in this patch, I would like to Jean-Marc commit it. If some parts are controversial, I can commit Jean-Marc the rest. I applied this. There is more work to do. JMarc
Re: [PATCH 13x] paths
Jean-Marc Lasgouttes wrote: Did you try to contact the tex-k list? http://www.tug.org/mailman/listinfo/tex-k Nope. There's only so much time in the day :) Do you want to do it? -- Angus
Re: [PATCH 13x, 14x] child processes
Jean-Marc Lasgouttes wrote: Angus These patches implement asynchronous loading of graphics in Angus Windows. The code on *nix is unchanged in the 1.3.x tree, apart Angus from the removal of some functions that are no longer called. Angus (They were used by the dialog to kill child processes but that Angus went some time ago.) I cannot do much to make sure that the new win32 code works, so I'll have to trust you on this :) No, all you have to do is convince yourself that it doesn't break on *nix. We've never supported win32 before so we can't regress :) Why do you use #if defined(_WIN32) instead of #ifdef _WIN32 like everywhere else? (this kind of useless remark is further proof that I do not have any real problem with the patch!) I just find it easier to read. Especially when there're a couple of parts to the test. Angus Jean-Marc, that's basically it for the port of LyX 1.3.x to Angus Windows. There's another small patch to disable ispell support Angus and the lyxserver and to enable the autosave code to work Angus (blocking). I attach this patch also (win32_kludge_13x.diff) Concerning this patch, how difficult would it be to really disable the spellchecker and lyxserver under win32, that is to keep those two files unix-only? We should just make sure that it is possible to run LyX without any spellchecker or lyxserver. I guess this is what Lars will request for 1.4.0cvs, so if it is not too disruptive we might as well do it here. More code == more possibility for breakage, no? We'd have to start messing around in the preferences dialog and in whatever stuff calls these things. I'd rather not do that. -- Angus
Re: lyxrc.tex_allow_spaces and the frontends
Jean-Marc Lasgouttes wrote: Angus Jean-Marc has added a configure test to ascertain Angus whether LaTeX can understand file names containing spaces. Angus However, lyxrc.tex_allows_spaces seems a little arbitrary. Angus Perhaps a LyXRC string variable lyxrc.tex_file_special_chars Angus which would be set to ~ if the TeX version was sufficiently Angus modern? I am not sure that it is arbitrary. Unless you can prove me false, I believe that _all_ TeX implementation have the same behaviour wrt at least ~. If we can prove that some characters are not handled identically by various TeXs, then it will be time to adapt. Ok. The detailed testing of what works with what compiler is at http://wiki.lyx.org/LaTeX/FilesWithSpecialChars I guess I was thinking ahead to a latex_path that handles some of the more 'difficult' characters. Let's just shelve it for now. Angus In fact, I think that adding the test to the file name widget Angus itself is a much better idea. Let's scrap the check in the Angus Browser and instead highlight the offending widget in Angus red/deactivate the Ok,Apply buttons in the dialog. This is definitely a good idea, especially since few files will require it. I'll see what I can do. -- Angus
Re: [PATCH] Various counter-related fixes
Jean-Marc Lasgouttes wrote: Jean-Marc If no problems are uncovered in this patch, I would like to Jean-Marc commit it. If some parts are controversial, I can commit Jean-Marc the rest. I applied this. There is more work to do. JMarc, there appears to be something wrong in the Naviage menu when playing with this with the UserGuide. If I open up the Document-Settings dialog, NumberingToc pane and select 'section's to appear in the TOC but not subsections, then the Navigate menu looks like 1.1 1.2 1.3 ... 6.7 If, however, I set sections not to appear, then the menu contains nothing. What happened to 1 2 3 4 5 6 ? Also, the menu is huge. Wouldn't 1 1.1 1.2 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 2 3 4 5 6 be better? -- Angus
Re: lyxrc.tex_allow_spaces and the frontends
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Ok. The detailed testing of what works with what compiler is at Angus http://wiki.lyx.org/LaTeX/FilesWithSpecialChars I guess I was Angus thinking ahead to a latex_path that handles some of the more Angus 'difficult' characters. Let's just shelve it for now. OK. JMarc
Re: [PATCH] Various counter-related fixes
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: Jean-Marc If no problems are uncovered in this patch, I would like to Jean-Marc commit it. If some parts are controversial, I can commit Jean-Marc the rest. I applied this. There is more work to do. Angus JMarc, there appears to be something wrong in the Naviage menu Angus when playing with this with the UserGuide. If I open up the Angus Document-Settings dialog, NumberingToc pane and select Angus 'section's to appear in the TOC but not subsections, then the Angus Navigate menu looks like I do not remember whether I mentionned it when sending the patch, but the toc-related stuff is broken right now. I'll try to fix it asap. JMarc
Re: [PATCH 13x, 14x] child processes
Angus == Angus Leeming [EMAIL PROTECTED] writes: I cannot do much to make sure that the new win32 code works, so I'll have to trust you on this :) Angus No, all you have to do is convince yourself that it doesn't Angus break on *nix. We've never supported win32 before so we can't Angus regress :) Fair enough. Why do you use #if defined(_WIN32) instead of #ifdef _WIN32 like everywhere else? (this kind of useless remark is further proof that I do not have any real problem with the patch!) Angus I just find it easier to read. Especially when there're a Angus couple of parts to the test. OK, it seems that our Code_Rules do not say anything about that... Angus More code == more possibility for breakage, no? We'd have to Angus start messing around in the preferences dialog and in whatever Angus stuff calls these things. I'd rather not do that. What happens under windows when someone tries to invoke the spellchecker? JMarc
Re: [PATCH 13x] paths
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: Did you try to contact the tex-k list? http://www.tug.org/mailman/listinfo/tex-k Angus Nope. There's only so much time in the day :) Angus Do you want to do it? I am no sure anymore what the question is :) JMarc
Re: double/triple clicking (bug 1811)
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen The attached patch gets the selection back, but it does not
Juergen work for insets. Double clicking inside a footnote lets the
Juergen cursor jump outside the inset. Triple clicking selects the
Juergen line of the owning main text, instead of only the insettext.
It looks like you did the hardest part. The following patch fixes
double/triple clicking for me.
However, I see a perceptible lag when selecting by double clicking
(not with xforms). Could it be related to the lag when selecting by
dragging the mouse? This gives a very bad idea of LyX performance. The
xforms version is very good in this respect.
Lars, OK?
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2158
diff -u -p -r1.2158 ChangeLog
--- src/ChangeLog 19 Apr 2005 09:04:24 - 1.2158
+++ src/ChangeLog 19 Apr 2005 14:48:30 -
@@ -1,3 +1,7 @@
+2005-04-19 Jürgen Spitzmüller [EMAIL PROTECTED]
+
+ * text3.C (dispatch): set cursor on double/triple click events.
+
2005-04-14 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* lyxfunc.C (actOnUpdatedPrefs): avoid warning
Index: src/text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.289
diff -u -p -r1.289 text3.C
--- src/text3.C 14 Apr 2005 10:19:37 - 1.289
+++ src/text3.C 19 Apr 2005 14:48:30 -
@@ -981,6 +981,7 @@ void LyXText::dispatch(LCursor cur, Fu
cur.resetAnchor();
cursorEnd(cur);
cur.setSelection();
+ bv-cursor() = cur;
bv-haveSelection(cur.selection());
}
break;
@@ -988,6 +989,7 @@ void LyXText::dispatch(LCursor cur, Fu
case LFUN_MOUSE_DOUBLE:
if (cmd.button() == mouse_button::button1) {
selectWord(cur, lyx::WHOLE_WORD_STRICT);
+ bv-cursor() = cur;
bv-haveSelection(cur.selection());
}
break;
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.1132
diff -u -p -r1.1132 ChangeLog
--- src/insets/ChangeLog 19 Apr 2005 08:55:19 - 1.1132
+++ src/insets/ChangeLog 19 Apr 2005 14:48:30 -
@@ -1,3 +1,8 @@
+2005-04-19 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * insetcollapsable.C (doDispatch): pass through double/triple
+ click events.
+
2005-04-14 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* insetwrap.C (addToToc): copy the code from InsetFloat::addToToc.
Index: src/insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.267
diff -u -p -r1.267 insetcollapsable.C
--- src/insets/insetcollapsable.C 20 Feb 2005 16:33:08 - 1.267
+++ src/insets/insetcollapsable.C 19 Apr 2005 14:48:30 -
@@ -340,11 +340,6 @@ void InsetCollapsable::doDispatch(LCurso
}
break;
- case LFUN_MOUSE_DOUBLE:
- case LFUN_MOUSE_TRIPLE:
- cur.undispatched();
- break;
-
case LFUN_INSET_TOGGLE:
if (cmd.argument == open)
setStatus(Open);
Re: [PATCH 13x] paths
Jean-Marc Lasgouttes wrote: Angus Jean-Marc Lasgouttes wrote: Did you try to contact the tex-k list? http://www.tug.org/mailman/listinfo/tex-k Angus Nope. There's only so much time in the day :) Angus Do you want to do it? I am no sure anymore what the question is :) Why are files referenced in the dvi file as ...PSfile=foo bar.eps llx=... rather than ..PSfile=foo bar.eps llx=... ? The extra quotes break things like xdvi, yap, dvips and need to be removed by a post-processing script if the dvi file is to be useful. -- Angus
About spaces in file names
Hello, We are in the process of porting LyX (www.lyx.org, a frontend to LaTeX) to windows, and of course we would like to be able to typeset files with spaces in their names. I understand that this is possible since web2c 7.5.3, but we still have problems with LaTeX and \includegraphics. In this case, it appears that files are referenced in the dvi file as ...PSfile=foo bar.eps llx=... rather than ..PSfile=foo bar.eps llx=... The extra quotes break things like xdvi, yap, dvips and need to be removed by a post-processing script if the dvi file is to be useful. Is this a known limitation of this spaces handling? Are there known workarounds? We have a page on our wiki where we tried to investigate which characters are allowed and which are not here: http://wiki.lyx.org/LaTeX/FilesWithSpecialChars On a related note, is there documentation on the status of 8bit characters in file names? All pointers appreciated.
Re: lyxrc.tex_allow_spaces and the frontends
Angus Leeming wrote: I think that you misunderstand. I think so, too. Thereafter, I'm suggesting removing all checks from the file browser. Browse for any file you like. If, however, you choose something invalid, foo%bar.eps say, then the widget in the graphics browser will be highlighed red and the Ok,Apply buttons will be disabled. Sounds pretty good to me. To me, too. Michael
Problem with autosave of new unsaved document
When lyx crashes, it does an autosave first so nothing is lost. When restarting lyx, i.e. lyx somefile.lyx I usually get the question about the autosaved file being newer, and if I want to use it. That is a very nice feature. Except if the crash happened to some new and yet not saved file. An emergency somefile.lyx.emergency is created, but lyx somefile.lyx does not ask if I want to use the existing emergency file if somefile.lyx itself does not exist. All I get is the question wether I want to create a *new* file, and that makes me nervous. I believe this is much worse for people with less knowledge of computers, those probably don't figure out that they can rename the emergency file manually. It'd be really nice if lyx checked for an emergency save file even when no original exists, in order to avoid this problem. Ideally, lyx won't crash at all. But it is this fabulous stability that caused my way of working - just begin a new document and don't save at all for hours. Lyx won't ever loose my work anyway, not even the alpha-quality 1.4. :-) I sometimes have a document open for days, and save upon close. One gets used to stability. Helge Hafting
UI problem with custom bullet dialog
Lyx allow custom bullets for the bulleted list. There is a nice selection from available fonts, and even an option for entering your own latex command for a custom bullet. Great for using an image, for example. All this works, but there is a problem with custom bullets, it is hard to make changes. Re-open the custom bullet dialog, and the previous custom bullet is gone. I get a blank box, instead of an opportunity to adjust my existing custom bullet. Of course I can get at the command by export-latex but that is cumbersome. Helge Hafting
[PATCH] prebuilt development/win32/package.C for Visual Studio Windows builds
I've modified the prebuilt development/win32/package.C file based on the recent changes to package.C.in. I'd appeciate it if this could be committed. Thanks Rob package.C.diff Description: package.C.diff
Re: Request - relative paths for BibTeX references (maybe only relevant for Windows port)
Both file dialogs should work alike in theory: Return a relative filename if the file is in the document directory or a subdirectory thereof, and return an absolute filename if not. Do you get different behaviour? Yes, with LyX 1.3.5 qt (Windows port). Ekkehart
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> I have a list of dates for the LyX meeting in Paris. Jean-Marc> Unfortunately it is a bit short, but we'll see if they suit Jean-Marc> enough people to be useful. So it sound the dates are not too bad. Let's see who answered already: Jul 16Jul 23Jul 30 Aug 06 JMarc 5 5 5 5 Jose' 5 5 0 0 Lars 5 5 5 5 Michael5 0 0 0 Andre' 5 5 5 5 Alfredo0 0 0 0 Asger 0 0 3 5 Of course, I made up the numbers :) Feel free to correct me. Concerning other dates, it will be more difficult for me, especially since only school stops around Jul 12. And later in August, I will have difficulties to avoid family vacations... Who else is wanting to come? All answers are appreciated, even ``I can't tell you yet'' or ``I'd hate to be there''. I can't tell you yet for sure, but it looks like it happens to me to stay in Paris appr. from 8th of July til 20th of July. I'll have a "trip" for these days with my family and I'm interested in visiting the LyX meeting. And as always, everybody is welcome. If my appartment turns out to be too small, I have both a plan B and a plan C. So I would say you may add my name for Jul 16 ranked 4 and ranked 0 for the rest of time. Of course my name shouldn't weight to much on this list. I cannot contribute any hardware but I don't need a bed for the night. And I'm not a "beer drinker" :) Greetings, Stephan
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: "Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: Asger> No good for me. We bought a house in Turkey, and we are going Asger> there to see it, decorate it, and enjoy it for three weeks Asger> starting from the second week of July. Is there internet access there? Just wondering... Not yet. In fact, the houst is being built, so when we get there, it will be completely empty. Next year, or maybe the year after that, we might have a LyX meeting there. Regards, Asger
Re: [PATCH] Can't test due to broken QDocumentDialog.h
Angus Leeming <[EMAIL PROTECTED]> writes: | Helge Hafting wrote: >> In file included from QDocumentDialog_moc.C:11: >> ../QDocumentDialog.h:90: error: parse error before `<<' token >> ../QDocumentDialog.h:99: error: parse error before `==' token >> ../QDocumentDialog.h:108: error: parse error before `>>' token > >> This file wasn't touched by the patch, but it broke the compile. >> This did not happen earlier today, so I believe it has to be a >> recent patch. > | There is a CVS conflict; CVS has updated the file and found that your | version of some lines in the file is different what it thinks those | lines should be. Try removing the file and running | cvs update src/frontends/qt2/QDocumentDialog.h The trick is: "cvs up -C src/frontends/qt2/QDocumentDialog.h", without removing the file first. -- Lgb
Re: LyX meeting in Paris. When?
> "Asger" == Asger Alstrup <[EMAIL PROTECTED]> writes: Asger> Jean-Marc Lasgouttes wrote: >>> "Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: Asger> No good for me. We bought a house in Turkey, and we are going Asger> there to see it, decorate it, and enjoy it for three weeks Asger> starting from the second week of July. >> Is there internet access there? Just wondering... Asger> Not yet. In fact, the houst is being built, so when we get Asger> there, it will be completely empty. Next year, or maybe the Asger> year after that, we might have a LyX meeting there. Where is it? JMarc
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: Where is it? It's in YalÄkarvak on the Bodrum peninsula: http://www.mapquest.com/maps/map.adp?searchtype=address=TR=address==OByyLVuYfVoegQSvvFGo%2fWzHZknBIaN2HHB8D4nTDC%2bHL2sp1al0NOwvQrj%2fvi%2bhLY%2bt4CeuxqZO5qxTCTRMqXx3Y6o%2fa0E1 Regards, Asger
Re: LyX meeting in Paris. When?
> "Asger" == Asger Alstrup <[EMAIL PROTECTED]> writes: Asger> Jean-Marc Lasgouttes wrote: >> Where is it? Asger> It's in YalÄkarvak on the Bodrum peninsula: So now you get to use dotless Ä in everyday life. I am sure this geekness factor was a good reason to pick the place. I do not know much this part of Turkey, but it is said to be very nice... JMarc PS: Google tends to think you meant YalÄkavak instead.
Re: LyX meeting in Paris. When?
New updated list looks like: Jul 16Jul 23Jul 30 Aug 06 JMarc 5 5 5 5 Jose' 5 5 0 0 Lars 5 5 5 5 Michael5 0 0 0 Andre' 5 5 5 5 Alfredo0 0 0 2 Asger 0 0 3 5 Stephan4 0 0 0 Will not be able to come: Juergen S., John L. (I upped Alfredo to a 2 for Aug 06, the 0 was a mistake...). JMarc
Re: LyX meeting in Paris. When?
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Mon, Apr 18, 2005 at 05:15:32PM +0200, Jean-Marc Lasgouttes John> wrote: >> Who else is wanting to come? All answers are appreciated, even ``I >> can't tell you yet'' or ``I'd hate to be there''. John> Yet again (sigh) it's extremely unlikely I can make it... sigh, indeed. JMarc
Re: LyX meeting in Paris. When?
> "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: Stephan> I can't tell you yet for sure, but it looks like it happens Stephan> to me to stay in Paris appr. from 8th of July til 20th of Stephan> July. I'll have a "trip" for these days with my family and Stephan> I'm interested in visiting the LyX meeting. You will be very welcome. Stephan> So I would say you may add my name for Jul 16 ranked 4 and Stephan> ranked 0 for the rest of time. I did that. Stephan> Of course my name shouldn't weight to much on this list. I Stephan> cannot contribute any hardware but I don't need a bed for the Stephan> night. And I'm not a "beer drinker" :) Everybody weights (even beer non-drinkers). JMarc
Re: LyX meeting in Paris. When?
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> - who will not be able to come, whatever the date? Juergen> Me. The agenda is again too overloaded this summer, I'm Juergen> afraid :-( Too bad, really. Next time, maybe? JMarc
Re: configure test for GetLongPathNameA ?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I give up! I would like to write a configure test for the Angus> existence of GetLongPathNameA. Since existence of such things for various windows versions is well documented, I'd say that you should condition on windows version. Why do you need GetLongPathNameA instead of GetLongPathName? What windows versions do not know about it? JMarc
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: I do not know much this part of Turkey, but it is said to be very nice... Yes, I like it a lot. It is not as humid as the area around Alanya and Antalya. It is a bit expensive compared to other areas of Turkey, but still cheap compared to Denmark. PS: Google tends to think you meant YalÄkavak instead. And Google is right. I notice right after I clicked send, but the undo stack is flushed when you click Send in my mail program, so there is nothing I could do about it. Regards, Asger
Re: [PATCH] patch worked as advertised
Lars Gullik BjÃnnes wrote: Angus Leeming <[EMAIL PROTECTED]> writes: | Helge Hafting wrote: In file included from QDocumentDialog_moc.C:11: ../QDocumentDialog.h:90: error: parse error before `<<' token ../QDocumentDialog.h:99: error: parse error before `==' token ../QDocumentDialog.h:108: error: parse error before `>>' token This file wasn't touched by the patch, but it broke the compile. This did not happen earlier today, so I believe it has to be a recent patch. | There is a CVS conflict; CVS has updated the file and found that your | version of some lines in the file is different what it thinks those | lines should be. Try removing the file and running | cvs update src/frontends/qt2/QDocumentDialog.h The trick is: "cvs up -C src/frontends/qt2/QDocumentDialog.h", without removing the file first. My "cvs" did not understand "-C" But removing the file and then doing "cvs update filename" worked. The patch worked, I can again turn emphasis on and off as I wish. Helge Hafting
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: > Too bad, really. Next time, maybe? Yes, I hope to make it possible eventually. I'd really appreciate to have a beer with you guys. Jürgen
Re: configure test for GetLongPathNameA ?
Jean-Marc Lasgouttes wrote: Angus> I give up! I would like to write a configure test for the Angus> existence of GetLongPathNameA. Since existence of such things for various windows versions is well documented, I'd say that you should condition on windows version. Yes, but how? The function declaration is protected in /mingw/include/winbase.h by macros _WIN32_WINDOWS (not defined) and _WIN32_WINNT: #if (_WIN32_WINNT >= 0x0500 || _WIN32_WINDOWS >= 0x0410) WINBASEAPI DWORD WINAPI GetLongPathNameA(LPCSTR,LPSTR,DWORD); WINBASEAPI DWORD WINAPI GetLongPathNameW(LPCWSTR,LPWSTR,DWORD); #endif In turn, _WIN32_WINNT is defined in /mingw/include/windef.h: #ifndef WINVER #define WINVER 0x0400 /* * If you need Win32 API features newer the Win95 and WinNT then * you must define WINVER before including windows.h or any other * method of including the windef.h header. */ #endif #define _WIN32_WINNT WINVER So, really, truly, the header files aren't helping any. Hence the need for a configure test to see whether the function is present in the standard library. Why do you need GetLongPathNameA instead of GetLongPathName? GetLongPathName is just a #define for GetLongPathNameA in this case. #ifdef UNICODE #else #if (_WIN32_WINNT >= 0x0500 || _WIN32_WINDOWS >= 0x0410) #define GetLongPathName GetLongPathNameA #endif What windows versions do not know about it? Windows 95 and Windows NT and earlier. Angus
Re: [PATCH] patch worked as advertised
On Tue, 2005-04-19 at 12:31, Helge Hafting wrote: > Lars Gullik BjÃnnes wrote: > > >Angus Leeming <[EMAIL PROTECTED]> writes: > > > >| Helge Hafting wrote: > > > > > >>>In file included from QDocumentDialog_moc.C:11: > >>>../QDocumentDialog.h:90: error: parse error before `<<' token > >>>../QDocumentDialog.h:99: error: parse error before `==' token > >>>../QDocumentDialog.h:108: error: parse error before `>>' token > >>> > >>> > >>>This file wasn't touched by the patch, but it broke the compile. > >>>This did not happen earlier today, so I believe it has to be a > >>>recent patch. > >>> > >>> > >| There is a CVS conflict; CVS has updated the file and found that your > >| version of some lines in the file is different what it thinks those > >| lines should be. Try removing the file and running > >| cvs update src/frontends/qt2/QDocumentDialog.h > > > >The trick is: "cvs up -C src/frontends/qt2/QDocumentDialog.h", without > >removing the file first. > > > > > My "cvs" did not understand "-C" But removing the file and then > doing "cvs update filename" worked. The patch worked, > I can again turn emphasis on and off as I wish. > > Helge Hafting Did you notice anything else fishy? Esp. with languages. Maybe you noticed that you cannot now switch languages on the fly while writing: you have to select first and then apply. Not that you would often want to do that. - Martin PS. I still think that this is not the _right_ fix for the problem. That would be to assure that everytime a lyxtext is created, current_font and real_current_font are set to the buffer defaults. But I see no easy way to do that, and I did try. This fix is good enough for 1.4.0, I think. signature.asc Description: This is a digitally signed message part
Re: [PATCH] patch worked as advertised
Helge Hafting <[EMAIL PROTECTED]> writes: >>The trick is: "cvs up -C src/frontends/qt2/QDocumentDialog.h", without >>removing the file first. >> | My "cvs" did not understand "-C" But removing the file and then Hmm then your cvs should be upgraded. | doing "cvs update filename" worked. The patch worked, | I can again turn emphasis on and off as I wish. good -- Lgb
Re: configure test for GetLongPathNameA ?
Angus Leeming wrote: So, really, truly, the header files aren't helping any. Hence the need for a configure test to see whether the function is present in the standard library. I asked on the autoconf list "autoconf test for dllimport-ed function?" http://news.gmane.org/gmane.comp.sysutils.autoconf.general The reply just back is that no test currently exists but I should consider submitting one :) | Any suggestions? You should be able to use AC_TRY_COMPILE or AC_COMPILE_IFELSE to create a macro, say AC_CHECK_WINDOWS_FUNCS, which does something like AC_CHECK_FUNCS for MSYS. Obviously, such a thing will not be very portable. But if it turns out to be useful, the autoconf archive might want to include it. Looking at the autoconf macro archive, wouldn't this fit the bill? http://autoconf-archive.cryp.to/ac_check_func_in.html AC_CHECK_FUNC_IN(windows.h, GetLongPathName) However, when I come to run autogen.sh on it, I get: configure.ac:257: error: AC_LANG: unknown language: autoconf/lang.m4:123: _AC_LANG_SET is expanded from... autoconf/lang.m4:132: AC_LANG is expanded from... autoconf/general.m4:1799: AC_CACHE_VAL is expanded from... acinclude.m4:800: AC_CHECK_FUNC_IN is expanded from... configure.ac:257: the top level autom4te: /bin/m4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 Patch attached. Any clues? Wrapping it in AC_LANG_PUSH(C)... POP doesn't have any effect. Angus Index: config/configure.ac === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/Attic/configure.ac,v retrieving revision 1.24.2.31 diff -u -a -u -r1.24.2.31 configure.ac --- config/configure.ac 30 Mar 2005 14:50:53 - 1.24.2.31 +++ config/configure.ac 19 Apr 2005 09:11:58 - @@ -254,6 +254,7 @@ AC_TYPE_UID_T AC_CHECK_FUNCS(snprintf vsnprintf strerror) +AC_CHECK_FUNC_IN(windows.h, GetLongPathName) LYX_CHECK_DECL(snprintf, stdio.h) LYX_CHECK_DECL(vsnprintf, stdio.h) LYX_CHECK_DECL(istreambuf_iterator, iterator) Index: config/lyxinclude.m4 === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/lyxinclude.m4,v retrieving revision 1.81.2.7 diff -u -a -u -r1.81.2.7 lyxinclude.m4 --- config/lyxinclude.m44 Feb 2005 09:14:24 - 1.81.2.7 +++ config/lyxinclude.m419 Apr 2005 09:13:38 - @@ -750,3 +750,51 @@ [Define if mkdir takes only one argument.]) fi ]) + +dnl Checking for library functions in a given header file +dnl +dnl @category Misc +dnl @author Guido Draheim <[EMAIL PROTECTED]> +dnl @version 2001-05-03 +dnl @license GPLWithACException +dnl http://autoconf-archive.cryp.to/ac_check_func_in.html + +dnl AC_CHECK_FUNC_IN(HEADER, FUNCTION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]) +AC_DEFUN([AC_CHECK_FUNC_IN], +[AC_MSG_CHECKING([for $2 in $1]) +AC_CACHE_VAL(ac_cv_func_$2, +[AC_TRY_LINK( +dnl Don't include because on OSF/1 3.0 it includes +dnl which includes which contains a prototype for +dnl select. Similarly for bzero. +[/* System header to define __stub macros and hopefully few prototypes, +which can conflict with char $2(); below. */ +#include +#include <$1> +/* Override any gcc2 internal prototype to avoid an error. */ +]ifelse(AC_LANG, CPLUSPLUS, [#ifdef __cplusplus +extern "C" +#endif +])dnl +[/* We use char because int might match the return type of a gcc2 +builtin and then its argument prototype would still apply. */ +char $2(); +], [ +/* The GNU C library defines this for functions which it implements +to always fail with ENOSYS. Some functions are actually named +something starting with __ and the normal name is an alias. */ +#if defined (__stub_$2) || defined (__stub___$2) +choke me +#else +$2(); +#endif +], eval "ac_cv_func_$2=yes", eval "ac_cv_func_$2=no")]) +if eval "test \"`echo '$ac_cv_func_'$2`\" = yes"; then + AC_MSG_RESULT(yes) + ifelse([$3], , :, [$3]) +else + AC_MSG_RESULT(no) +ifelse([$4], , , [$4 +])dnl +fi +])
Re: configure test for GetLongPathNameA ?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Looking at the autoconf macro archive, wouldn't this fit the Angus> bill? http://autoconf-archive.cryp.to/ac_check_func_in.html Angus> AC_CHECK_FUNC_IN(windows.h, GetLongPathName) But it does not do anything special related to windows, does it? Angus> However, when I come to run autogen.sh on it, I get: Angus> configure.ac:257: error: AC_LANG: unknown language: It uses AC_LANG as a variable, whereas it is a macro with argument. I'd propose to drop this macro. Looking at functions.m4 in autoconf data directory, I see: # AC_CHECK_FUNC(FUNCTION, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # - AC_DEFUN([AC_CHECK_FUNC], [AS_VAR_PUSHDEF([ac_var], [ac_cv_func_$1])dnl AC_CACHE_CHECK([for $1], ac_var, [AC_LINK_IFELSE([AC_LANG_FUNC_LINK_TRY([$1])], [AS_VAR_SET(ac_var, yes)], [AS_VAR_SET(ac_var, no)])]) AS_IF([test AS_VAR_GET(ac_var) = yes], [$2], [$3])dnl AS_VAR_POPDEF([ac_var])dnl ])# AC_CHECK_FUNC # AC_CHECK_FUNCS(FUNCTION..., [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # - AC_DEFUN([AC_CHECK_FUNCS], [AC_FOREACH([AC_Func], [$1], [AH_TEMPLATE(AS_TR_CPP(HAVE_[]AC_Func), [Define to 1 if you have the `]AC_Func[' function.])])dnl for ac_func in $1 do AC_CHECK_FUNC($ac_func, [AC_DEFINE_UNQUOTED([AS_TR_CPP([HAVE_$ac_func])]) $2], [$3])dnl done ]) So, all you'd have to do would be to make a copy of these two macros and change AC_CHECK_WINDOWS_FUNC to invoke your own version of AC_LANG_FUNC_LINK_TRY(C), which is in c.m4. Of course, then you will need a different version for autoconf 2.13... JMarc
Re: configure test for GetLongPathNameA ?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: I give up! I would like to write a Angus> configure test for the existence of GetLongPathNameA. >> Since existence of such things for various windows versions is well >> documented, I'd say that you should condition on windows version. Angus> Yes, but how? OK, did you see this? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp It seems that under windows they have some way to allow calling unimplemented functions. The only thing is that they will return an error. Isn't this the natural way of using GetLongPathName? I would say that just testing whether the return code is 0 would be enough. No need to lookup GetLastError. JMarc
Re: configure test for GetLongPathNameA ?
Jean-Marc Lasgouttes wrote: OK, did you see this? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp It seems that under windows they have some way to allow calling unimplemented functions. The only thing is that they will return an error. Isn't this the natural way of using GetLongPathName? I would say that just testing whether the return code is 0 would be enough. No need to lookup GetLastError. Jean-Marc, you are a wizard! Thank you. Angus
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: > > New updated list looks like: > > Jul 16Jul 23Jul 30 Aug 06 > JMarc 5 5 5 5 > Jose' 5 5 0 0 > Lars 5 5 5 5 > Michael5 0 0 0 > Andre' 5 5 5 5 > Alfredo0 0 0 2 > Asger 0 0 3 5 > Stephan4 0 0 0 > > Will not be able to come: Juergen S., John L. > > (I upped Alfredo to a 2 for Aug 06, the 0 was a mistake...). Thanks! Dates before Jul 16 are out of the question, right? Regards, Alfredo
Re: LyX meeting in Paris. When?
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes: Alfredo> Dates before Jul 16 are out of the question, right? The problem is that my wife works at 200km from Paris and our children will still have to attend school, so things will be very difficult for us. I can try again to find a solution, but don't hold your breath. JMarc
[PATCH 14x] fix support/pch.h on Windows
Trivial patch that prevents unix-specific headers from breaking compilation on Windows. Committing now. -- AngusIndex: src/support/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v retrieving revision 1.332 diff -u -p -r1.332 ChangeLog --- src/support/ChangeLog 18 Apr 2005 17:43:11 - 1.332 +++ src/support/ChangeLog 19 Apr 2005 12:04:16 - @@ -1,4 +1,9 @@ - 2005-04-17 Angus Leeming <[EMAIL PROTECTED]> +2005-04-19 Angus Leeming <[EMAIL PROTECTED]> + + * pch.h: protect unix-specific headers from breaking compilation + on Windows. + +2005-04-17 Angus Leeming <[EMAIL PROTECTED]> * filetools.C (MakeDisplayPath): invoke os::external_path before returning path. Index: src/support/pch.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/pch.h,v retrieving revision 1.5 diff -u -p -r1.5 pch.h --- src/support/pch.h 20 Jan 2005 15:38:14 - 1.5 +++ src/support/pch.h 19 Apr 2005 12:04:16 - @@ -15,13 +15,13 @@ #include #include -#include #include #include -#include -#include #include -#ifdef HAVE_UNISTD_H +#ifndef _WIN32 +# include +# include +# include # include #endif
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: > Alfredo> Dates before Jul 16 are out of the question, right? > > The problem is that my wife works at 200km from Paris and our children > will still have to attend school, so things will be very difficult for > us. I can try again to find a solution, but don't hold your breath. No, please don't bother, I was just curious. Alfredo
Re: LyX meeting in Paris. When?
On Fri, 2005-04-15 at 16:56, Jean-Marc Lasgouttes wrote: > I have a list of dates for the LyX meeting in Paris. Unfortunately it > is a bit short, but we'll see if they suit enough people to be useful. > > I just give the dates of the corresponding saturdays. The idea would > be to meet for 4-5 days around that. > > The dates are: > > Jul 16 > Jul 23 > Jul 30 > Aug 06 > > The questions are: > > - who would be able to come at one of these dates? > > - who would like to come, but not at these dates? > > - who will not be able to come, whatever the date? > > > For now I propose to do this at my new home, where I could provide > accommodation for 7-8 people. If more people want to come, I think I > can come up with something else. > > JMarc I don't think that I can make it. All our money went to the summer cottage :-( - Martin signature.asc Description: This is a digitally signed message part
[PATCH 13x, 14x] GetLongPathName on Windows
I think that this one is now resolved, so I'll commit these now. -- AngusIndex: src/support/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v retrieving revision 1.149.2.40 diff -u -p -r1.149.2.40 ChangeLog --- src/support/ChangeLog 18 Apr 2005 17:44:05 - 1.149.2.40 +++ src/support/ChangeLog 19 Apr 2005 12:15:14 - @@ -1,3 +1,7 @@ +2005-04-19 Angus Leeming <[EMAIL PROTECTED]> + + * package.C (get_temp_dir): call GetLongPathName on Windows. + 2005-04-17 Angus Leeming <[EMAIL PROTECTED]> * filetools.C (MakeDisplayPath): invoke os::external_path before Index: src/support/package.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/Attic/package.C,v retrieving revision 1.1.2.3 diff -u -p -r1.1.2.3 package.C --- src/support/package.C 17 Jan 2005 11:50:16 - 1.1.2.3 +++ src/support/package.C 19 Apr 2005 12:15:15 - @@ -35,6 +35,24 @@ #if defined (USE_WINDOWS_PACKAGING) + +/* + * MinGW's version of winver.h contains this comment: + * + * If you need Win32 API features newer the Win95 and WinNT then you must + * define WINVER before including windows.h or any other method of including + * the windef.h header. + * + * GetLongPathNameA requires WINVER == 0x0500. + * + * It doesn't matter if the Windows version is older than this because the + * function will compile but will fail at run time. See + * http://msdn.microsoft.com/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp + */ +# if defined(__MINGW32__) +# define WINVER 0x0500 +# endif + # include # include // SHGetFolderPath @@ -299,6 +317,7 @@ string const get_temp_dir() // Typical example: C:/TEMP/. char path[PATH_MAX + 1]; GetTempPath(PATH_MAX, path); + GetLongPathName(path, path, PATH_MAX + 1); return os::internal_path(path); #else // Posix-like. return "/tmp"; Index: src/support/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v retrieving revision 1.333 diff -u -p -r1.333 ChangeLog --- src/support/ChangeLog 19 Apr 2005 12:12:47 - 1.333 +++ src/support/ChangeLog 19 Apr 2005 12:14:28 - @@ -1,5 +1,9 @@ 2005-04-19 Angus Leeming <[EMAIL PROTECTED]> + * package.C.in (get_temp_dir): call GetLongPathName on Windows. + +2005-04-19 Angus Leeming <[EMAIL PROTECTED]> + * pch.h: protect unix-specific headers from breaking compilation on Windows. Index: src/support/package.C.in === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/package.C.in,v retrieving revision 1.9 diff -u -p -r1.9 package.C.in --- src/support/package.C.in 15 Feb 2005 13:45:40 - 1.9 +++ src/support/package.C.in 19 Apr 2005 12:14:28 - @@ -38,6 +38,24 @@ #endif #if defined (USE_WINDOWS_PACKAGING) + +/* + * MinGW's version of winver.h contains this comment: + * + * If you need Win32 API features newer the Win95 and WinNT then you must + * define WINVER before including windows.h or any other method of including + * the windef.h header. + * + * GetLongPathNameA requires WINVER == 0x0500. + * + * It doesn't matter if the Windows version is older than this because the + * function will compile but will fail at run time. See + * http://msdn.microsoft.com/library/en-us/mslu/winprog/microsoft_layer_for_unicode_apis_with_limited_support.asp + */ +# if defined(__MINGW32__) +# define WINVER 0x0500 +# endif + # include # include // SHGetFolderPath @@ -363,6 +381,7 @@ string const get_temp_dir() // Typical example: C:/TEMP/. char path[PATH_MAX + 1]; GetTempPath(PATH_MAX, path); + GetLongPathName(path, path, PATH_MAX + 1); return os::internal_path(path); #else // Posix-like. return "/tmp";
[PATCH 13x, 14x] child processes
These patches implement asynchronous loading of graphics in Windows.
The code on *nix is unchanged in the 1.3.x tree, apart from the removal of
some functions that are no longer called. (They were used by the dialog to
kill child processes but that went some time ago.)
The 1.4.x code on *nix *is* changed. Basically, I've reverted to the code
in LyX 1.3.x, for two reasons:
1. 'Issues' remain with the SIGCHLD handling code. (Read it's not robust).
2. Such a solution cannot be implemented on Windows and I want to minimize
the changes to get this Windows port working.
Going the 1.3.x way, explicitly polling for any completed child processes
is safe and robust and can be implemented with relatively little change on
Windows.
I won't commit these just yet, but will do so tomorrow unless there are any
strong objections.
Jean-Marc, that's basically it for the port of LyX 1.3.x to Windows.
There's another small patch to disable ispell support and the lyxserver
and to enable the autosave code to work (blocking). I attach this patch
also (win32_kludge_13x.diff)
We should also address the issue of accepting 'files with spaces' in the
dialogs, but that's not Windows-specific.
--
Angus
child_13x.diff.gz
Description: GNU Zip compressed data
child_14x.diff.gz
Description: GNU Zip compressed data
Index: src/ispell.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ispell.C,v
retrieving revision 1.5.2.5
diff -u -a -u -r1.5.2.5 ispell.C
--- src/ispell.C 7 Dec 2004 10:48:23 - 1.5.2.5
+++ src/ispell.C 15 Apr 2005 22:28:12 -
@@ -21,12 +21,28 @@
#include "support/forkedcall.h"
#include "support/lstrings.h"
+#ifdef _WIN32
+// sys/select.h
+# define FD_ZERO(a)
+# define FD_SET(a,b)
+# define FD_ISSET(fd, set) 0
+//sys/types.h
+# define fd_set int
+// unistd.h
+# define fork() -1
+# define pipe(a) _pipe(a,0,0)
+#endif
+
// HP-UX 11.x doesn't have this header
#ifdef HAVE_SYS_SELECT_H
#include
#endif
#include
+#ifdef HAVE_UNISTD_H
+# include
+#endif
+
#ifndef CXX_GLOBAL_CSTD
using std::strcpy;
using std::strlen;
@@ -309,11 +325,15 @@
tv.tv_sec = 2;
tv.tv_usec = 0;
+#ifdef _WIN32
+ retval = -1;
+#else
retval = ::select(SELECT_TYPE_ARG1 (max(pipeout[0], pipeerr[0]) + 1),
SELECT_TYPE_ARG234 (),
0,
0,
SELECT_TYPE_ARG5 ());
+#endif
// error
if (retval <= 0)
Index: src/lyx_cb.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_cb.C,v
retrieving revision 1.190.2.3
diff -u -a -u -r1.190.2.3 lyx_cb.C
--- src/lyx_cb.C 10 Jan 2005 19:17:24 - 1.190.2.3
+++ src/lyx_cb.C 15 Apr 2005 20:29:06 -
@@ -37,6 +37,11 @@
#include "support/systemcall.h"
#include "support/lstrings.h"
+#ifdef _WIN32
+// unistd.h
+# define fork() -1
+#endif
+
#include "BoostFormat.h"
#include
Index: src/lyxserver.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxserver.C,v
retrieving revision 1.48.2.3
diff -u -a -u -r1.48.2.3 lyxserver.C
--- src/lyxserver.C 20 Jan 2005 10:47:28 - 1.48.2.3
+++ src/lyxserver.C 15 Apr 2005 22:22:20 -
@@ -36,14 +36,6 @@
#include
-#include
-#include
-#ifdef HAVE_UNISTD_H
-#include
-#endif
-#include
-#include
-
#include "lyxserver.h"
#include "debug.h"
#include "lyxfunc.h"
@@ -51,14 +43,28 @@
#include "support/lyxlib.h"
#include "frontends/lyx_gui.h"
-#ifdef __EMX__
-#include
-#include
-#define OS2EMX_PLAIN_CHAR
-#define INCL_DOSNMPIPES
-#define INCL_DOSERRORS
-#include
-#include "support/os2_errortable.h"
+#include
+#include
+#include
+#include
+
+#if defined (_WIN32)
+# define F_SETFD2
+# define F_SETFL4
+# define O_NONBLOCK 0x4000
+ inline int fcntl (int, int, ...) {return -1;}
+
+#elif defined (__EMX__)
+# include
+# include
+# define OS2EMX_PLAIN_CHAR
+# define INCL_DOSNMPIPES
+# define INCL_DOSERRORS
+# include
+# include "support/os2_errortable.h"
+
+#else // POSIX
+# include
#endif
using std::endl;
Re: [PATCH 13x, 14x] child processes
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> These patches implement asynchronous loading of graphics in Angus> Windows. The code on *nix is unchanged in the 1.3.x tree, apart Angus> from the removal of some functions that are no longer called. Angus> (They were used by the dialog to kill child processes but that Angus> went some time ago.) I cannot do much to make sure that the new win32 code works, so I'll have to trust you on this :) Why do you use #if defined(_WIN32) instead of #ifdef _WIN32 like everywhere else? (this kind of useless remark is further proof that I do not have any real problem with the patch!) Angus> Jean-Marc, that's basically it for the port of LyX 1.3.x to Angus> Windows. There's another small patch to disable ispell support Angus> and the lyxserver and to enable the autosave code to work Angus> (blocking). I attach this patch also (win32_kludge_13x.diff) Concerning this patch, how difficult would it be to really disable the spellchecker and lyxserver under win32, that is to keep those two files unix-only? We should just make sure that it is possible to run LyX without any spellchecker or lyxserver. I guess this is what Lars will request for 1.4.0cvs, so if it is not too disruptive we might as well do it here. The idea would be for ispell to disable its support when select() is not available, for example. Angus> We should also address the issue of accepting 'files with Angus> spaces' in the dialogs, but that's not Windows-specific. Yes. JMarc
Re: lyxrc.tex_allow_spaces and the frontends
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc has added a configure test to ascertain Angus> whether LaTeX can understand file names containing spaces. Angus> However, lyxrc.tex_allows_spaces seems a little arbitrary. Angus> Perhaps a LyXRC string variable lyxrc.tex_file_special_chars Angus> which would be set to " ~" if the TeX version was sufficiently Angus> modern? I am not sure that it is arbitrary. Unless you can prove me false, I believe that _all_ TeX implementation have the same behaviour wrt at least ~. If we can prove that some characters are not handled identically by various TeXs, then it will be time to adapt. I believe that the problem with space is related to the syntax of file-related primitives as Knuth implemented them. Another problem which is probably version-dependent is the acceptance of 8bit characters. But I'd like to understand better what versions are impacted before acting on that. Angus> In fact, I think that adding the test to the file name widget Angus> itself is a much better idea. Let's scrap the check in the Angus> Browser and instead highlight the offending widget in Angus> red/deactivate the Ok,Apply buttons in the dialog. This is definitely a good idea, especially since few files will require it. JMarc
Re: [PATCH 13x] paths
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> This stuff with dvi rewriting is not really something I like :) Did >> you try to contact the miktex and/or web2c people about it? It >> seems that the bug is more in tex than in the dvi tools: the extra >> quotes should not be there... Angus> Granted. But people are going to be using these buggy tools for Angus> a while, so we need to devise a work-around. I can certainly Angus> contact the web2c people too. Do they have a newsgroup? Did you try to contact the tex-k list? http://www.tug.org/mailman/listinfo/tex-k JMarc
Re: [PATCH] Various counter-related fixes
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> If no problems are uncovered in this patch, I would like to Jean-Marc> commit it. If some parts are controversial, I can commit Jean-Marc> the rest. I applied this. There is more work to do. JMarc
Re: [PATCH 13x] paths
Jean-Marc Lasgouttes wrote: > Did you try to contact the tex-k list? > http://www.tug.org/mailman/listinfo/tex-k Nope. There's only so much time in the day :) Do you want to do it? -- Angus
Re: [PATCH 13x, 14x] child processes
Jean-Marc Lasgouttes wrote: > Angus> These patches implement asynchronous loading of graphics in > Angus> Windows. The code on *nix is unchanged in the 1.3.x tree, apart > Angus> from the removal of some functions that are no longer called. > Angus> (They were used by the dialog to kill child processes but that > Angus> went some time ago.) > > I cannot do much to make sure that the new win32 code works, so I'll > have to trust you on this :) No, all you have to do is convince yourself that it doesn't break on *nix. We've never supported win32 before so we can't regress :) > Why do you use > #if defined(_WIN32) > instead of > #ifdef _WIN32 > like everywhere else? > > (this kind of useless remark is further proof that I do not have any > real problem with the patch!) I just find it easier to read. Especially when there're a couple of parts to the test. > Angus> Jean-Marc, that's basically it for the port of LyX 1.3.x to > Angus> Windows. There's another small patch to disable ispell support > Angus> and the lyxserver and to enable the autosave code to work > Angus> (blocking). I attach this patch also (win32_kludge_13x.diff) > > Concerning this patch, how difficult would it be to really disable the > spellchecker and lyxserver under win32, that is to keep those two > files unix-only? We should just make sure that it is possible to run > LyX without any spellchecker or lyxserver. I guess this is what Lars > will request for 1.4.0cvs, so if it is not too disruptive we might as > well do it here. More code == more possibility for breakage, no? We'd have to start messing around in the preferences dialog and in whatever stuff calls these things. I'd rather not do that. -- Angus
Re: lyxrc.tex_allow_spaces and the frontends
Jean-Marc Lasgouttes wrote: > Angus> Jean-Marc has added a configure test to ascertain > Angus> whether LaTeX can understand file names containing spaces. > Angus> However, lyxrc.tex_allows_spaces seems a little arbitrary. > Angus> Perhaps a LyXRC string variable lyxrc.tex_file_special_chars > Angus> which would be set to " ~" if the TeX version was sufficiently > Angus> modern? > > I am not sure that it is arbitrary. Unless you can prove me false, I > believe that _all_ TeX implementation have the same behaviour wrt at > least ~. If we can prove that some characters are not handled > identically by various TeXs, then it will be time to adapt. Ok. The detailed testing of what works with what compiler is at http://wiki.lyx.org/LaTeX/FilesWithSpecialChars I guess I was thinking ahead to a latex_path that handles some of the more 'difficult' characters. Let's just shelve it for now. > Angus> In fact, I think that adding the test to the file name widget > Angus> itself is a much better idea. Let's scrap the check in the > Angus> Browser and instead highlight the offending widget in > Angus> red/deactivate the Ok,Apply buttons in the dialog. > > This is definitely a good idea, especially since few files will require > it. I'll see what I can do. -- Angus
Re: [PATCH] Various counter-related fixes
Jean-Marc Lasgouttes wrote: > Jean-Marc> If no problems are uncovered in this patch, I would like to > Jean-Marc> commit it. If some parts are controversial, I can commit > Jean-Marc> the rest. > > I applied this. There is more work to do. JMarc, there appears to be something wrong in the Naviage menu when playing with this with the UserGuide. If I open up the Document->Settings dialog, Numbering pane and select 'section's to appear in the TOC but not subsections, then the Navigate menu looks like 1.1 1.2 1.3 ... 6.7 If, however, I set sections not to appear, then the menu contains nothing. What happened to 1 2 3 4 5 6 ? Also, the menu is huge. Wouldn't 1 > 1.1 1.2 > 1.3 > 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 2 > 3 > 4 > 5 > 6 > be better? -- Angus
Re: lyxrc.tex_allow_spaces and the frontends
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Ok. The detailed testing of what works with what compiler is at Angus> http://wiki.lyx.org/LaTeX/FilesWithSpecialChars I guess I was Angus> thinking ahead to a latex_path that handles some of the more Angus> 'difficult' characters. Let's just shelve it for now. OK. JMarc
Re: [PATCH] Various counter-related fixes
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: Jean-Marc> If no problems are uncovered in this patch, I would like to Jean-Marc> commit it. If some parts are controversial, I can commit Jean-Marc> the rest. >> I applied this. There is more work to do. Angus> JMarc, there appears to be something wrong in the Naviage menu Angus> when playing with this with the UserGuide. If I open up the Angus> Document->Settings dialog, Numbering pane and select Angus> 'section's to appear in the TOC but not subsections, then the Angus> Navigate menu looks like I do not remember whether I mentionned it when sending the patch, but the toc-related stuff is broken right now. I'll try to fix it asap. JMarc
Re: [PATCH 13x, 14x] child processes
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> I cannot do much to make sure that the new win32 code works, so >> I'll have to trust you on this :) Angus> No, all you have to do is convince yourself that it doesn't Angus> break on *nix. We've never supported win32 before so we can't Angus> regress :) Fair enough. >> Why do you use #if defined(_WIN32) instead of #ifdef _WIN32 like >> everywhere else? >> >> (this kind of useless remark is further proof that I do not have >> any real problem with the patch!) Angus> I just find it easier to read. Especially when there're a Angus> couple of parts to the test. OK, it seems that our Code_Rules do not say anything about that... Angus> More code == more possibility for breakage, no? We'd have to Angus> start messing around in the preferences dialog and in whatever Angus> stuff calls these things. I'd rather not do that. What happens under windows when someone tries to invoke the spellchecker? JMarc
Re: [PATCH 13x] paths
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: >> Did you try to contact the tex-k list? >> http://www.tug.org/mailman/listinfo/tex-k Angus> Nope. There's only so much time in the day :) Angus> Do you want to do it? I am no sure anymore what the question is :) JMarc
Re: double/triple clicking (bug 1811)
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> The attached patch gets the selection back, but it does not
Juergen> work for insets. Double clicking inside a footnote lets the
Juergen> cursor jump outside the inset. Triple clicking selects the
Juergen> line of the owning main text, instead of only the insettext.
It looks like you did the hardest part. The following patch fixes
double/triple clicking for me.
However, I see a perceptible lag when selecting by double clicking
(not with xforms). Could it be related to the lag when selecting by
dragging the mouse? This gives a very bad idea of LyX performance. The
xforms version is very good in this respect.
Lars, OK?
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2158
diff -u -p -r1.2158 ChangeLog
--- src/ChangeLog 19 Apr 2005 09:04:24 - 1.2158
+++ src/ChangeLog 19 Apr 2005 14:48:30 -
@@ -1,3 +1,7 @@
+2005-04-19 Jürgen Spitzmüller <[EMAIL PROTECTED]>
+
+ * text3.C (dispatch): set cursor on double/triple click events.
+
2005-04-14 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* lyxfunc.C (actOnUpdatedPrefs): avoid warning
Index: src/text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.289
diff -u -p -r1.289 text3.C
--- src/text3.C 14 Apr 2005 10:19:37 - 1.289
+++ src/text3.C 19 Apr 2005 14:48:30 -
@@ -981,6 +981,7 @@ void LyXText::dispatch(LCursor & cur, Fu
cur.resetAnchor();
cursorEnd(cur);
cur.setSelection();
+ bv->cursor() = cur;
bv->haveSelection(cur.selection());
}
break;
@@ -988,6 +989,7 @@ void LyXText::dispatch(LCursor & cur, Fu
case LFUN_MOUSE_DOUBLE:
if (cmd.button() == mouse_button::button1) {
selectWord(cur, lyx::WHOLE_WORD_STRICT);
+ bv->cursor() = cur;
bv->haveSelection(cur.selection());
}
break;
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.1132
diff -u -p -r1.1132 ChangeLog
--- src/insets/ChangeLog 19 Apr 2005 08:55:19 - 1.1132
+++ src/insets/ChangeLog 19 Apr 2005 14:48:30 -
@@ -1,3 +1,8 @@
+2005-04-19 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * insetcollapsable.C (doDispatch): pass through double/triple
+ click events.
+
2005-04-14 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* insetwrap.C (addToToc): copy the code from InsetFloat::addToToc.
Index: src/insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.267
diff -u -p -r1.267 insetcollapsable.C
--- src/insets/insetcollapsable.C 20 Feb 2005 16:33:08 - 1.267
+++ src/insets/insetcollapsable.C 19 Apr 2005 14:48:30 -
@@ -340,11 +340,6 @@ void InsetCollapsable::doDispatch(LCurso
}
break;
- case LFUN_MOUSE_DOUBLE:
- case LFUN_MOUSE_TRIPLE:
- cur.undispatched();
- break;
-
case LFUN_INSET_TOGGLE:
if (cmd.argument == "open")
setStatus(Open);
Re: [PATCH 13x] paths
Jean-Marc Lasgouttes wrote: > Angus> Jean-Marc Lasgouttes wrote: >>> Did you try to contact the tex-k list? >>> http://www.tug.org/mailman/listinfo/tex-k > > Angus> Nope. There's only so much time in the day :) > > Angus> Do you want to do it? > > I am no sure anymore what the question is :) Why are files referenced in the dvi file as ...PSfile=""foo bar".eps" llx=... rather than ..PSfile="foo bar.eps" llx=... ? The extra quotes break things like xdvi, yap, dvips and need to be removed by a post-processing script if the dvi file is to be useful. -- Angus
About spaces in file names
Hello, We are in the process of porting LyX (www.lyx.org, a frontend to LaTeX) to windows, and of course we would like to be able to typeset files with spaces in their names. I understand that this is possible since web2c 7.5.3, but we still have problems with LaTeX and \includegraphics. In this case, it appears that files are referenced in the dvi file as ...PSfile=""foo bar".eps" llx=... rather than ..PSfile="foo bar.eps" llx=... The extra quotes break things like xdvi, yap, dvips and need to be removed by a post-processing script if the dvi file is to be useful. Is this a known limitation of this spaces handling? Are there known workarounds? We have a page on our wiki where we tried to investigate which characters are allowed and which are not here: http://wiki.lyx.org/LaTeX/FilesWithSpecialChars On a related note, is there documentation on the status of 8bit characters in file names? All pointers appreciated.
Re: lyxrc.tex_allow_spaces and the frontends
Angus Leeming wrote: I think that you misunderstand. I think so, too. Thereafter, I'm suggesting removing all checks from the file browser. Browse for any file you like. If, however, you choose something invalid, foo%bar.eps say, then the widget in the graphics browser will be highlighed red and the Ok,Apply buttons will be disabled. Sounds pretty good to me. To me, too. Michael
Problem with autosave of new unsaved document
When lyx crashes, it does an autosave first so nothing is lost. When restarting lyx, i.e. "lyx somefile.lyx" I usually get the question about the autosaved file being newer, and if I want to use it. That is a very nice feature. Except if the crash happened to some new and yet not saved file. An emergency "somefile.lyx.emergency" is created, but "lyx somefile.ïlyx" does not ask if I want to use the existing emergency file if "somefile.lyx" itself does not exist. All I get is the question wether I want to create a *new* file, and that makes me nervous. I believe this is much worse for people with less knowledge of computers, those probably donï't figure out that they can rename the emergency file manually. It'd be really nice if lyx checked for an emergency save file even when no "original" exists, in order to avoid this problem. Ideally, lyx won't crash at all. But it is this fabulous stability that caused my way of working - just begin a new document and don't save at all for hours. Lyx won't ever loose my work anyway, not even the alpha-quality 1.4. :-) I sometimes have a document open for days, and save upon close. One gets used to stability. Helge Hafting
UI problem with custom bullet dialog
Lyx allow custom bullets for the bulleted list. There is a nice selection from available fonts, and even an option for entering your own latex command for a custom bullet. Great for using an image, for example. All this works, but there is a problem with custom bullets, it is hard to make changes. Re-open the custom bullet dialog, and the previous custom bullet is gone. I get a blank box, instead of an opportunity to adjust my existing custom bullet. Of course I can get at the command by "export->latex" but that is cumbersome. Helge Hafting
[PATCH] prebuilt development/win32/package.C for Visual Studio Windows builds
I've modified the prebuilt development/win32/package.C file based on the recent changes to package.C.in. I'd appeciate it if this could be committed. Thanks Rob package.C.diff Description: package.C.diff
Re: Request - relative paths for BibTeX references (maybe only relevant for Windows port)
Both file dialogs should work alike in theory: Return a relative filename if the file is in the document directory or a subdirectory thereof, and return an absolute filename if not. Do you get different behaviour? Yes, with LyX 1.3.5 qt (Windows port). Ekkehart
