On Sun, Dec 30, 2007 at 10:13:19AM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > I think that something like the attached should do it. The trick is
> > using the same strings as argument of the _() function as they are
> > then coalesced in a single translation.
>
> Fine with m
Enrico Forestieri wrote:
> I think that something like the attached should do it. The trick is
> using the same strings as argument of the _() function as they are
> then coalesced in a single translation.
Fine with me.
Jürgen
On Sat, Dec 29, 2007 at 03:43:44PM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > I see. But shouldn't this translation be decoupled from the
> > "LyX Warning" one in order to avoid problems in the matching?
> > I mean, there's a _("") in
> > Paragraph.cpp and a qt_(" > so, in the
Enrico Forestieri wrote:
> I see. But shouldn't this translation be decoupled from the
> "LyX Warning" one in order to avoid problems in the matching?
> I mean, there's a _("") in
> Paragraph.cpp and a qt_(" so, in theory, "LyX Warning" could be translated differently.
> For example, I could transl
On Sat, Dec 29, 2007 at 01:53:20PM +0100, Jürgen Spitzmüller wrote:
> The "uncodable character" part will be translated as well (see Paragraph.cpp).
I see. But shouldn't this translation be decoupled from the
"LyX Warning" one in order to avoid problems in the matching?
I mean, there's a _("") in
Enrico Forestieri wrote:
> > Wouldn't it be easier to just show
> > right from the beginning?
>
> This would already be less ugly.
OK, then let's do this.
> > BTW your patch forgets that "LyX Warning" is translatable (which of
> > course only makes sense if this string is also displayed).
>
> I
On Sat, Dec 29, 2007 at 11:01:58AM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > What about the attached?
>
> Honestly, I doubt it is worth inserting the XML-like tags and removing them
> again in the next step.
It is not strange if you think that it allows for frontend indepe
Enrico Forestieri wrote:
> What about the attached?
Honestly, I doubt it is worth inserting the XML-like tags and removing them
again in the next step.
Wouldn't it be easier to just show
right from the beginning?
BTW your patch forgets that "LyX Warning" is translatable (which of course
only
On Wed, Dec 26, 2007 at 11:18:16AM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > Yes, I got that, but I think that it could be improved.
>
> Improvements are certainly welcome.
What about the attached?
--
Enrico
Index: src/frontends/qt4/QViewSource.cpp
===
Enrico Forestieri wrote:
> Yes, I got that, but I think that it could be improved.
Improvements are certainly welcome.
Jürgen
On Mon, Dec 24, 2007 at 04:37:21PM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > This is perfect. I only dislike the verbose warning in the view source
> > window.
>
> At least you can hardly miss it ;-)
That's for sure ;-)
> > I would have preferred to only have the offendin
Enrico Forestieri wrote:
> This is perfect. I only dislike the verbose warning in the view source
> window.
At least you can hardly miss it ;-)
> I would have preferred to only have the offending character
> shown in red,
This is difficult to achieve.
> or at least something less verbose suc
On Mon, Dec 24, 2007 at 02:44:59PM +0100, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > I think the character code point should rather be displayed in the error
> > dialog.
>
> I did this (see attached) and also changed the error message to something
> really translatable, using bfor
On Sun, Dec 23, 2007 at 09:50:46PM -0600, Bo Peng wrote:
> > docstring s;
> > s.resize(1);
> > s[0] = c;
>
> Isn't this docstring s(1, c)?
Yes, of course.
> BTW, do you see the offending characters in the view source dialog?
Yes, both on windows
"Bo Peng" <[EMAIL PROTECTED]> writes:
> I agree that it would be nice to show all offending characters, but
> it is perfectly fine to me to show only the first one. This might be
> an reaction to the fact that I usually only need to locate (the hard
> part) and fix the first compiling error when gc
Jürgen Spitzmüller wrote:
> I think the character code point should rather be displayed in the error
> dialog.
I did this (see attached) and also changed the error message to something
really translatable, using bformat.
Jürgen
Index: src/frontends/qt4/QViewSource.cpp
===
Enrico Forestieri wrote:
> I think that it is also useful to know the character code point. This
> could be achieved by also giving a warning to the console. Something
> like:
I think the character code point should rather be displayed in the error
dialog.
Jürgen
> docstring s;
> s.resize(1);
> s[0] = c;
Isn't this docstring s(1, c)?
BTW, do you see the offending characters in the view source dialog?
Bo
On Sun, Dec 23, 2007 at 03:14:48PM -0600, Bo Peng wrote:
> > Like this.
>
> The patch looks fine to me, but I still can not see the offending
> characters in the view source dialog. (chaning os << a to os.put(a)
> does not help)...
>
> If Enrico and you can see them, you can commit the patch and
On Dec 23, 2007 3:20 PM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> >> I just tested it. It looks good. One thing I noted: If the document
> >> contains
> >> multiple unknown characters, only the first one is reported by the error
> >> dialog. Is
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> I just tested it. It looks good. One thing I noted: If the document contains
>> multiple unknown characters, only the first one is reported by the error
>> dialog. Is this intended?
>
> Right now, the exception will stop the export process so only the
> fir
> Like this.
The patch looks fine to me, but I still can not see the offending
characters in the view source dialog. (chaning os << a to os.put(a)
does not help)...
If Enrico and you can see them, you can commit the patch and leave the
issue for later.
Bo
Jürgen Spitzmüller wrote:
> we could use the LaTeX highlighter in QViewSource to make this warning red
> and bold (which should even work with translated strings, right?).
Like this.
Jürgen
Index: src/frontends/qt4/QViewSource.cpp
==
Enrico Forestieri wrote:
> I attach here your patch revised such that to comply to the above.
Enrico's patch works for me.
As for the representation, I'd suggest , which
should of course be translatable.
And we could use the LaTeX highlighter in QViewSource to make this warning red
and bold (w
> Maybe the offending character could be simply shown in red, for example.
I do not know how to tell qt to show certain characters in red,
especially when we are supposed to support multiple frontends.
> This is a known problem. Due to the fact that our wide char is not a
> real type but a typede
On Sun, Dec 23, 2007 at 05:14:40PM +1800, Bo Peng wrote:
> > Yes. I am trying to display the character ... There is something
> > tricky about the handling of a character in docstring.
>
> OK. With the attached simple patch, the offending characters are
> replaced by . The whole paragraph is
> di
> Yes. I am trying to display the character ... There is something
> tricky about the handling of a character in docstring.
OK. With the attached simple patch, the offending characters are
replaced by . The whole paragraph is
displayed (as Enrico wishes), but it is easy to see where the
offending
On Dec 22, 2007 4:23 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
> Enrico Forestieri wrote:
> > I guess this is a personal preference. Nonetheless, given that the
> > view source window can display the character, why giving only its
> > decimal code (hexadecimal would be better) and not also
Enrico Forestieri wrote:
> I guess this is a personal preference. Nonetheless, given that the
> view source window can display the character, why giving only its
> decimal code (hexadecimal would be better) and not also show it?
I agree with Enrico.
Jürgen
On Fri, Dec 21, 2007 at 05:55:41PM -0600, Bo Peng wrote:
> > This patch avoids the crash. However, note that previously the
> > untranslatable character was actually correctly shown in the
> > ViewSource window and a warning was output to the console.
> > Could the old behavior be restored?
> >
>
> This patch avoids the crash. However, note that previously the
> untranslatable character was actually correctly shown in the
> ViewSource window and a warning was output to the console.
> Could the old behavior be restored?
>
I do not like the old behavior at all. The problematic character is
h
On Sat, Dec 22, 2007 at 02:09:40PM +1800, Bo Peng wrote:
> > > > So please commit and close bug 3511 with target 1.5.4.
> > >
> > > Done.
> >
> > Note that now LyX crashes on View->Source.
>
> Ohmm, This is because view source does not catch this exception. How
> about the attached patch? It is n
> > > So please commit and close bug 3511 with target 1.5.4.
> >
> > Done.
>
> Note that now LyX crashes on View->Source.
Ohmm, This is because view source does not catch this exception. How
about the attached patch? It is not a good idea to show the error
dialog here because the view source dialo
On Sat, Dec 22, 2007 at 11:33:23AM +1800, Bo Peng wrote:
> > So please commit and close bug 3511 with target 1.5.4.
>
> Done.
Note that now LyX crashes on View->Source.
--
Enrico
> So please commit and close bug 3511 with target 1.5.4.
Done.
Bo
Bo Peng wrote:
> Right now, the exception will stop the export process so only the
> first unknown character is reported. If we want to report all of them,
> ErrorList has to be passed to a deeper level which would lead to a
> more intrusive patch. I chose the simpler solution because I think it
>
> I just tested it. It looks good. One thing I noted: If the document contains
> multiple unknown characters, only the first one is reported by the error
> dialog. Is this intended?
Right now, the exception will stop the export process so only the
first unknown character is reported. If we want to
Bo Peng wrote:
> Jurgen,
>
> Is it OK to apply this patch to the branch now?
I just tested it. It looks good. One thing I noted: If the document contains
multiple unknown characters, only the first one is reported by the error
dialog. Is this intended?
Jürgen
On Dec 19, 2007 11:54 AM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > The patch is for 1.5.4, please test. I will commit after a few days of
> > using it.
Jurgen,
Is it OK to apply this patch to the branch now?
Bo
> The patch is for 1.5.4, please test. I will commit after a few days of using
> it.
I have committed the 1.6.x version of the patch. Please test. The only
problem, AFAIK, is that the ErrorList dialog can not display the
offending character in my test case. The message should be "Could not
find L
> OutputParams is used to give some context to the called methods (e.g.
> local_font, document_language...). Adding par_id ad pos would
> certainly not be a problem. I still think it is better than to
> generate an exception in two steps, but it does not ,qke q big
> difference in the end.
Encodin
"Bo Peng" <[EMAIL PROTECTED]> writes:
> I never though of that because OutputParams (such as nice, linelen) is
> used to control how output is generated, not to collect errors. Of
> course, because OutputParams is passed along the export process, it
> can be used for such purposes, but I would not
> The traditional solution to such
> problems was to use the OutputParams struct and to add there whatever
> variable is necessary. Is it really unfeasible here?
I never though of that because OutputParams (such as nice, linelen) is
used to control how output is generated, not to collect errors. O
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Dear all,
>
> Using a trick that add par_id and pos information during the handling
> of encoding_exception, I came up with a much simpler patch. Basically,
This patch is welcome, since not knowing what character has a problem
is really annoying. I am not s
>
> 'EncodingException' please.
I followed the name iconv_codecvt_facet_exception, but I will change
to EncodingException.
Bo
On Tue, Dec 18, 2007 at 01:21:22PM +1800, Bo Peng wrote:
> Dear all,
>
> Using a trick that add par_id and pos information during the handling
> of encoding_exception, I came up with a much simpler patch. Basically,
>
> 1. Define an exception with all needed information.
> +class encoding_excepti
Bo Peng wrote:
> The patch is for 1.5.4, please test. I will commit after a few days of
> using it.
For branch, I'd like to hear some opinions on the patch first (although I
agree on the overall direction).
BTW, this is bug 3511:
http://bugzilla.lyx.org/show_bug.cgi?id=3511
Jürgen
47 matches
Mail list logo
