lyx-cvs delays
Is it normal to get mails like Delivered-To: [EMAIL PROTECTED] Received: from localhost (localhost [127.0.0.1]) by millo.mpi.htwm.de (Postfix) with ESMTP id C0F7B80151 for <[EMAIL PROTECTED]>; Fri, 14 Oct 2005 19:31:49 +0200 (CEST) Envelope-to: [EMAIL PROTECTED] Delivery-date: Fri, 14 Oct 2005 09:06:30 +0200 Received: from mail.htwm.de [141.55.192.84] by localhost with POP3 (fetchmail-6.2.3) for [EMAIL PROTECTED] (single-drop); Fri, 14 Oct 2005 19:31:49 +0200 (CEST) Received: from mailto1.htwm.de ([141.55.192.81]:50908 helo=mailto.htwm.de) by mail.htwm.de with esmtp (Exim 4.24) id 1EQJeA-es-CH for [EMAIL PROTECTED]; Fri, 14 Oct 2005 09:06:30 +0200 Received: from aussie.lyx.org ([80.232.38.164]:37047) by mailto.htwm.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1EQJe9-0007lk-Kv for [EMAIL PROTECTED]; Fri, 14 Oct 2005 09:06:29 +0200 Received: from aussie.lyx.org (localhost.localdomain [127.0.0.1]) by aussie.lyx.org (8.13.4/8.13.4) with ESMTP id j9E72DBx027418; Fri, 14 Oct 2005 09:02:13 +0200 Received: from baywatch.lyx.org (baywatch.lyx.org [80.232.38.163]) by aussie.lyx.org (8.13.4/8.13.4) with ESMTP id j8JBVRvj015551 for <[EMAIL PROTECTED]>; Mon, 19 Sep 2005 13:31:27 +0200 Received: (from [EMAIL PROTECTED]) Note the gap between Sep 19 and Oct 14... Andre'
Re: [patch] bug 2066: C-i for opening/closing insets only works when cursor is at the beginning of the inset
Jean-Marc Lasgouttes wrote: > That would be changing cmd to LFUN_INSET_TOGGLE and setting > cur.undispatched. I tend to think that then the dispatch mechanism > will try to apply LFUN_INSET_TOGGLE to all insets in the cursor stack. > > Do you see what I mean? Not quite. Jürgen
Re: LyX 1.4 on Windows (MinGW)
Am Mittwoch, 12. Oktober 2005 22:08 schrieb Michael Gerz: > Martin Vermeer wrote: > > >Neither am I... but I did it anyway, just to get the stuff working. But > >your idea is better. > > > >All you have to do, at start-up, is > > > >1) Check that a locale is defined, and if not, define en_US; > >2) remove any encoding suffixes like fi_FI.utf-8 --> fi_FI. > > > >Doing it in one place at start-up (and only using, say, LC_ALL or LANG, > >and making the others conform) would allow a lot of special code to be > >taken out. In theory. The problem is that this would also change the encoding for child processes if we sue setenv(), such as viewers and editors for graphics. So this is actually not so good. We could however strip the suffix and cache the value internally, but this is IMHO not for 1.4.0. > >I wonder if this is 1.4 stuff. Perhaps not. So I say, do the minimal > >patch based on Michael's idea. > > > > > > I had a very short look at the code this evening. AFAICS we need all the > stuff because we want to control the translation based on the language > of the current document. In other words, you can have a Finnish UI with > German layout styles (labels). The code in messages.C seems to do the > right thing. > > Nevertheless, my patch changes it in two ways: > > - It checks a couple of environment variables to determine lang_. This > is needed for MinGW on the Windows platform. > > - It moves a couple of checks out of the getter method and into the > constructor. This is more efficient but not necessary in principle. > > But, of course, it would be nice if someone with more gettext experience > could have a look at the code as well. I am wondering whether we need to work around a broken setlocale() on windows. Isn't it possible to fix it? Georg
[patch] fix bug 2086
See http://bugzilla.lyx.org/show_bug.cgi?id=2086. The problem is that the
pointer 'codec' can be 0, and that is not checked before dereferencing.
The patch is based on the one sent by Andreas (but without the codec for
the "C" locale, because I don't know if that is correct), + some
whitespace corrections.
It seems that encode() is called with an empty encoding. I don't know why,
so this patch does not cure the root of the problem, but symptoms.
I'd apply it anyway, since a 0 pointer can also occur for unknown
encodings.
OK to apply?
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/frontends/qt2/ChangeLog lyx-1.4-cvs/src/frontends/qt2/ChangeLog
--- lyx-1.4-clean/src/frontends/qt2/ChangeLog 2005-10-08 10:43:51.0 +0200
+++ lyx-1.4-cvs/src/frontends/qt2/ChangeLog 2005-10-16 17:27:09.016876088 +0200
@@ -1,3 +1,7 @@
+2005-10-16 Georg Baum <[EMAIL PROTECTED]>
+
+ * QLyXKeySym.C (initEncodings): prevent crash when no codec found
+
2005-10-07 Martin Vermeer <[EMAIL PROTECTED]>
* QContentPane.C (QContentPane): make times 50 msec instead of 25,
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/frontends/qt2/QLyXKeySym.C lyx-1.4-cvs/src/frontends/qt2/QLyXKeySym.C
--- lyx-1.4-clean/src/frontends/qt2/QLyXKeySym.C 2005-07-17 14:57:28.0 +0200
+++ lyx-1.4-cvs/src/frontends/qt2/QLyXKeySym.C 2005-10-13 14:33:18.0 +0200
@@ -45,20 +45,23 @@ char const encode(string const & encodin
EncodingMap::const_iterator cit = encoding_map.find(encoding);
if (cit == encoding_map.end()) {
- if (lyxerr.debugging())
- lyxerr[Debug::KEY] << "Unrecognised encoding "
-<< encoding << endl;
+ lyxerr[Debug::KEY] << "Unrecognised encoding '" << encoding
+ << "'." << endl;
codec = encoding_map.find("")->second;
} else {
codec = cit->second;
}
- if (lyxerr.debugging())
- lyxerr[Debug::KEY] << "Using codec " << fromqstr(codec->name()) << endl;
+ if (!codec) {
+ lyxerr[Debug::KEY] << "No codec for encoding '" << encoding
+ << "' found." << endl;
+ return 0;
+ }
+
+ lyxerr[Debug::KEY] << "Using codec " << fromqstr(codec->name()) << endl;
if (!codec->canEncode(str)) {
- if (lyxerr.debugging())
- lyxerr[Debug::KEY] << "Oof. Can't encode the text !" << endl;
+ lyxerr[Debug::KEY] << "Oof. Can't encode the text !" << endl;
return 0;
}
@@ -84,7 +87,7 @@ void initEncodings()
s = "C";
}
}
-
+
if (s.find("UTF") != string::npos || s.find("utf") != string::npos)
//if (contains(c, "UTF") || contains(c, "utf"))
lyxerr << "Warning: this system's locale uses Unicode." << endl;
@@ -112,17 +116,16 @@ void initEncodings()
encoding_map["pt154"] = 0;
// There are lots more codecs in Qt too ...
-
+
// when no document open
// use the appropriate encoding for the system language
lyxerr << "Language code:" << s << endl;
for (Languages::const_iterator it=languages.begin(); it != languages.end(); ++it) {
//lyxerr << it->second.code() << ":" << it->second.encodingStr() << ":" << it->second.encoding() << endl;
- if (it->second.code() == s)
- {
-s = it->second.encodingStr();
-break;
- }
+ if (it->second.code() == s) {
+ s = it->second.encodingStr();
+ break;
+ }
}
lyxerr << "Setting new locale for Qt:" << s << endl;
QTextCodec * defaultCodec = encoding_map[s];
Re: lyx140cvs: internationalization
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Oct 13, 2005 at 06:34:44PM +0200, Hartmut Haase wrote:
|
| > - lyxerr << "\nlyx: SIGHUP signal caught\nBye." << endl;
| > + lyxerr << _("\nlyx: SIGHUP signal caught\nBye.") << endl;
|
| Is the l12n effort worth it for these?
|
| > - << " of " << lyx_release_date << endl;
| > - lyxerr << "Built on " << __DATE__ << ", " << __TIME__ << endl;
| > + << _(" of ") << lyx_release_date << endl;
| > + lyxerr << _("Built on ") << __DATE__ << ", " << __TIME__ << endl;
|
| It doesn't look like this is translatable, it needs to be a full
| sentence. Look for the use of bformat() elsewhere to see what's needed.
Also I belive these has been left as "always english" on purpose.
Sure, that can be changed but bformat must be used.
--
Lgb
Re: lyx-cvs delays
Andre Poenitz <[EMAIL PROTECTED]> writes: | Is it normal to get mails like Only when I just recently discoverd that the mailinglist was stuck and just collected emails, but sent none out... -- Lgb
Re: lyx-cvs delays
On Sun, Oct 16, 2005 at 06:46:40PM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | Is it normal to get mails like > > Only when I just recently discoverd that the mailinglist was stuck and > just collected emails, but sent none out... Ah, well. So maybe next time you could just send a reminder that you won't discover that the mailinglist got stuck before you keep doing so for three weeks or so ;-} Andre'
Re: 1.4.0pre2 on cygwin
Kayvan A. Sylvan <[EMAIL PROTECTED]> writes: > > On Sat, Oct 15, 2005 at 04:40:28PM +, Luis Rivera wrote: > > > > minires solved the problem. LyX now compiles happily on my brand new Cygwin > > installation... > > > > So, this far, I have compiled LyX on cygwin succesfully, both with-xforms > > and > > with-qt. > > Cool. This is with gcc-3.4.4? > I used cygwin, version 1.5.18-1, with gcc 3.4.4-1, and the qt3 3.3.4-2 bundled with cygwin. However, as I say in the other thread, I can can compile LyX succesfully, but it doesn't display any characters: just plain white squares. Perhaps there is nothing wrong with LyX, and the problem is the qt library, or there is some font display library for XWin on cygwin that I haven't loaded. I'll get a look at it tomorrow. Luis.
