Re: Bug in configure.py

[Richard Heck]

On 06/01/2011 06:26 PM, Enrico Forestieri wrote:
 On Wed, Jun 01, 2011 at 01:03:43PM -0400, Richard Heck wrote:

 On 05/31/2011 09:31 PM, Enrico Forestieri wrote:
 On Tue, May 31, 2011 at 02:23:28PM +0200, Michal wrote:

 From http://msdn.microsoft.com/en-us/library/aa364989%28v=vs.85%29.aspx
 The short form can be longer than the specified path.

 (so using len(longname)+1 as the length of the output buffer could
 end badly)
 I assume that this may happen if the long name stem has less then 8 chars.
 Indeed:

 $ cygpath -d 'a b.tex'
 AB2E6D~1.TEX

 This can be easily taken into account.

 If this has been sorted out to your satisfaction, please feel free to
 commit to branch.
 Done at r38921.

Thanks.

rh

Language change within Flex inset exports wrong babel construct

[Jean-Pierre Chrétien]

Hello,

I checked the pdf export of the French version of the Custolization manual, and 
I discovered a number of extra spaces after constructs where a word remained in 
English inside a Flex inset, e.g.:


\begin_inset Flex Code
status collapsed

\begin_layout Plain Layout

\lang english
word
\end_layout

\end_inset

This exports as

\code{\selectlanguage{english}%
word\selectlanguage{french}
}

If I turn the word in English outside the Flex inset, the exported code is

 \foreignlanguage{english}{\code{word}}

and the extra space disappears.

So a correct export in the first case would be

\code{\foreignlanguage{english}{word}}

Attached is a simple example.

I checked with other Flex insets (emphasize and such), same behaviour.

Does this deserve a ticket ?

Note that if I reverse languages (main language English, foreign language 
French), I get also an extra space *before* the word, even with the corrected 
version, but the latter is anyway better than the former. This seems an issue 
with babel itself, so LyX should not try to correct it, but IMHO LyX must export 
the best latex construct, and \selectlanguage does not seem appropriate inside a 
sentence (does not work well on a single word outside a Flex inset).


--
Jean-Pierre


test_foreign_in_Flex.lyx
Description: application/lyx

Assertion in current trunk: WordList.cpp

[BH]

I'm noticing many of these assertions showing up in the console
whenever I type a non-space character:

lyx-devel/src/support/lassert.cpp(35): ASSERTION it != d-words_.end()
VIOLATED IN lyx-devel/src/WordList.cpp:76

BH

Re: Assertion in current trunk: WordList.cpp

[Richard Heck]

On 06/02/2011 12:47 PM, BH wrote:
 I'm noticing many of these assertions showing up in the console
 whenever I type a non-space character:

 lyx-devel/src/support/lassert.cpp(35): ASSERTION it != d-words_.end()
 VIOLATED IN lyx-devel/src/WordList.cpp:76

I don't see this right now under Linux.

rh

Re: Assertion in current trunk: WordList.cpp

[BH]

On Thu, Jun 2, 2011 at 1:22 PM, Richard Heck rgh...@comcast.net wrote:
 On 06/02/2011 12:47 PM, BH wrote:
 I'm noticing many of these assertions showing up in the console
 whenever I type a non-space character:

 lyx-devel/src/support/lassert.cpp(35): ASSERTION it != d-words_.end()
 VIOLATED IN lyx-devel/src/WordList.cpp:76

 I don't see this right now under Linux.

Quitting and restarting LyX, I now don't see it either. I'll keep an
eye out to see if (and under what conditions) it happens again

BH

Re: Language change within Flex inset exports wrong babel construct

[Richard Heck]

On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
 Hello,

 I checked the pdf export of the French version of the Custolization
 manual, and I discovered a number of extra spaces after constructs
 where a word remained in English inside a Flex inset, e.g.:

 \begin_inset Flex Code
 status collapsed

 \begin_layout Plain Layout

 \lang english
 word
 \end_layout

 \end_inset

 This exports as

 \code{\selectlanguage{english}%
 word\selectlanguage{french}
 }

 If I turn the word in English outside the Flex inset, the exported
 code is

  \foreignlanguage{english}{\code{word}}

 and the extra space disappears.

 So a correct export in the first case would be

 \code{\foreignlanguage{english}{word}}

 Attached is a simple example.

 I checked with other Flex insets (emphasize and such), same behaviour.

 Does this deserve a ticket ?

I think so. I've had a look at it, and it's more difficult than it might
seem. A comment in the code (this is output_latex.cpp, lines 770ff)
suggests that sometimes we do need to restore the language, whereas it
seems that in this sort of case we do not. That suggests we need a
layout tag.

Richard

Re: Lyx 2.0.0 OSX crashes

[Stephan Witt]

Am 01.06.2011 um 18:28 schrieb Murat Yildizoglu:

 Hello Stephan,
 
 I have been using the new OSX binary and I see some strange things going on 
 with the cursor: it does not correctly indicate its position (it is always a 
 little bit on the right of its actual position), and when I insert or delete 
 characters, the operations do not take place at the correct place. The 
 problem does not seem to depend on the font  I choose for the screen.
 
  Do you observe this problem? 

Yes, now I do. Currently, I don't have much time for LyX. That's why I didn't 
notice it.
Until now I thought it's a problem starting with Qt-4.7 - but obviously it's a 
problem with Cocoa.
We have problems with the text width of drawn text and the cursor positioning.
The solution for Qt-4.7 should be activated in general.

Stephan

Re: r38934 - lyx-devel/trunk/src/frontends/qt4

[Jean-Marc Lasgouttes]

Le 02/06/11 22:46, sw...@lyx.org a écrit :

Author: switt
Date: Thu Jun  2 22:46:25 2011
New Revision: 38934
URL: http://www.lyx.org/trac/changeset/38934

Log:
Cocoa based Qt-4.6 needs to paint every character separately to match metrics 
computation, there is no Qt version dependency


But is there a cocoa dependency? Can we catch that?

JMarc

Re: Language change within Flex inset exports wrong babel construct

[Enrico Forestieri]

On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:

 On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
  Hello,
 
  I checked the pdf export of the French version of the Custolization
  manual, and I discovered a number of extra spaces after constructs
  where a word remained in English inside a Flex inset, e.g.:
 
  \begin_inset Flex Code
  status collapsed
 
  \begin_layout Plain Layout
 
  \lang english
  word
  \end_layout
 
  \end_inset
 
  This exports as
 
  \code{\selectlanguage{english}%
  word\selectlanguage{french}
  }
 
  If I turn the word in English outside the Flex inset, the exported
  code is
 
   \foreignlanguage{english}{\code{word}}
 
  and the extra space disappears.
 
  So a correct export in the first case would be
 
  \code{\foreignlanguage{english}{word}}
 
  Attached is a simple example.
 
  I checked with other Flex insets (emphasize and such), same behaviour.
 
  Does this deserve a ticket ?
 
 I think so. I've had a look at it, and it's more difficult than it might
 seem. A comment in the code (this is output_latex.cpp, lines 770ff)
 suggests that sometimes we do need to restore the language, whereas it
 seems that in this sort of case we do not. That suggests we need a
 layout tag.

I am not sure it's so difficult. Note that \selectlanguage is used when the
language is changed at the start of a paragraph, otherwise \foreignlanguage
is used. In the given example, a workaround is inserting {} in ERT right
before word and then changing the language of word only. You can see
that \foreignlanguage is then employed. Maybe \selectlanguage could be
used at the start of a paragraph only if Text::isMainText() is true.

-- 
Enrico

Re: Language change within Flex inset exports wrong babel construct

[Enrico Forestieri]

On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:

 On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
 
  I think so. I've had a look at it, and it's more difficult than it might
  seem. A comment in the code (this is output_latex.cpp, lines 770ff)
  suggests that sometimes we do need to restore the language, whereas it
  seems that in this sort of case we do not. That suggests we need a
  layout tag.
 
 I am not sure it's so difficult. Note that \selectlanguage is used when the
 language is changed at the start of a paragraph, otherwise \foreignlanguage
 is used. In the given example, a workaround is inserting {} in ERT right
 before word and then changing the language of word only. You can see
 that \foreignlanguage is then employed. Maybe \selectlanguage could be
 used at the start of a paragraph only if Text::isMainText() is true.

See attached patch.

-- 
Enrico
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(revisione 38933)
+++ src/output_latex.cpp(copia locale)
@@ -86,6 +86,8 @@ static TeXEnvironmentData prepareEnviron
 
BufferParams const  bparams = buf.params();
 
+   bool const maintext = text.isMainText();
+
// FIXME This test should not be necessary.
// We should perhaps issue an error if it is.
Layout const  style = text.inset().forcePlainLayout() ?
@@ -118,9 +120,12 @@ static TeXEnvironmentData prepareEnviron
string const doc_lang = use_pg ?
getPolyglossiaEnvName(doc_language) : doc_language-babel();
string const lang_begin_command = use_pg ?
-   \\begin{$$lang} : lyxrc.language_command_begin;
+   \\begin{$$lang} : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
-   \\end{$$lang} : lyxrc.language_command_end;
+   \\end{$$lang} : maintext ? lyxrc.language_command_end : };
+
+   bool const breakline = maintext || use_pg;
 
if (par_lang != prev_par_lang) {
if (!lang_end_command.empty() 
@@ -129,9 +134,10 @@ static TeXEnvironmentData prepareEnviron
os  from_ascii(subst(
lang_end_command,
$$lang,
-   prev_par_lang))
- // the '%' is necessary to prevent unwanted whitespace
-  %\n;
+   prev_par_lang));
+   if (breakline)
+   // break line but prevent unwanted whitespace
+   os  safebreakln;
}
 
if ((lang_end_command.empty() ||
@@ -146,8 +152,9 @@ static TeXEnvironmentData prepareEnviron
os  [

from_ascii(data.par_language-polyglossiaOpts())
];
- // the '%' is necessary to prevent unwanted whitespace
-   os  %\n;
+   if (breakline)
+   // break line but prevent unwanted whitespace
+   os  safebreakln;
}
}
 
@@ -518,9 +525,12 @@ void TeXOnePar(Buffer const  buf,
string const outer_lang = use_pg ?
getPolyglossiaEnvName(outer_language) : outer_language-babel();
string const lang_begin_command = use_pg ?
-   \\begin{$$lang} : lyxrc.language_command_begin;
+   \\begin{$$lang} : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
-   \\end{$$lang} : lyxrc.language_command_end;
+   \\end{$$lang} : maintext ? lyxrc.language_command_end : };
+
+   bool const breakline = maintext || use_pg;
 
if (par_lang != prev_lang
// check if we already put language command in TeXEnvironment()
@@ -535,9 +545,10 @@ void TeXOnePar(Buffer const  buf,
{
os  from_ascii(subst(lang_end_command,
$$lang,
-   prev_lang))
-  // the '%' is necessary to prevent unwanted 
whitespace
-   %\n;
+   prev_lang));
+   if (breakline)
+   // break line but prevent unwanted whitespace
+   os  safebreakln;
}
 
// We need to open a new language if we couldn't close the 
previous
@@ -594,8 +605,9 @@ void TeXOnePar(Buffer const  buf,
os  [

Re: Language change within Flex inset exports wrong babel construct

[Richard Heck]

On 06/02/2011 08:07 PM, Enrico Forestieri wrote:
 On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:

 On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:

 I think so. I've had a look at it, and it's more difficult than it might
 seem. A comment in the code (this is output_latex.cpp, lines 770ff)
 suggests that sometimes we do need to restore the language, whereas it
 seems that in this sort of case we do not. That suggests we need a
 layout tag.
 I am not sure it's so difficult. Note that \selectlanguage is used when the
 language is changed at the start of a paragraph, otherwise \foreignlanguage
 is used. In the given example, a workaround is inserting {} in ERT right
 before word and then changing the language of word only. You can see
 that \foreignlanguage is then employed. Maybe \selectlanguage could be
 used at the start of a paragraph only if Text::isMainText() is true.
 See attached patch.

Well, you understand this part of the code much (MUCH!) better than I
do, which is pretty much not at all. Jurgen, you care to comment (for
branch)?

Richard

Re: r38934 - lyx-devel/trunk/src/frontends/qt4

[Stephan Witt]

Am 02.06.2011 um 23:00 schrieb Jean-Marc Lasgouttes:

 Le 02/06/11 22:46, sw...@lyx.org a écrit :
 Author: switt
 Date: Thu Jun  2 22:46:25 2011
 New Revision: 38934
 URL: http://www.lyx.org/trac/changeset/38934
 
 Log:
 Cocoa based Qt-4.6 needs to paint every character separately to match 
 metrics computation, there is no Qt version dependency
 
 But is there a cocoa dependency?

Yes, it seems so. But it is visible on Linux too, AFAIK.
And for Mac I'd like to make the future builds with Cocoa.

 Can we catch that?

If possible we should fix the rowpainter/text metrics cache stuff.
I don't know how difficult and time consuming (man power) this is...

Stephan

PS. I'm off for the next three days and perhaps I'm offline.

Re: Bug in configure.py

[Richard Heck]

On 06/01/2011 06:26 PM, Enrico Forestieri wrote:
> On Wed, Jun 01, 2011 at 01:03:43PM -0400, Richard Heck wrote:
>
>> On 05/31/2011 09:31 PM, Enrico Forestieri wrote:
>>> On Tue, May 31, 2011 at 02:23:28PM +0200, Michal wrote:
>>>
 From http://msdn.microsoft.com/en-us/library/aa364989%28v=vs.85%29.aspx
 "The short form can be longer than the specified path."

 (so using len(longname)+1 as the length of the output buffer could
 end badly)
>>> I assume that this may happen if the "long" name stem has less then 8 chars.
>>> Indeed:
>>>
>>> $ cygpath -d 'a b.tex'
>>> AB2E6D~1.TEX
>>>
>>> This can be easily taken into account.
>>>
>> If this has been sorted out to your satisfaction, please feel free to
>> commit to branch.
> Done at r38921.
>
Thanks.

rh

Language change within Flex inset exports wrong babel construct

[Jean-Pierre Chrétien]

Hello,

I checked the pdf export of the French version of the Custolization manual, and 
I discovered a number of extra spaces after constructs where a word remained in 
English inside a Flex inset, e.g.:


\begin_inset Flex Code
status collapsed

\begin_layout Plain Layout

\lang english
word
\end_layout

\end_inset

This exports as

\code{\selectlanguage{english}%
word\selectlanguage{french}
}

If I turn the word in English outside the Flex inset, the exported code is

 \foreignlanguage{english}{\code{word}}

and the extra space disappears.

So a correct export in the first case would be

\code{\foreignlanguage{english}{word}}

Attached is a simple example.

I checked with other Flex insets (emphasize and such), same behaviour.

Does this deserve a ticket ?

Note that if I reverse languages (main language English, foreign language 
French), I get also an extra space *before* the word, even with the corrected 
version, but the latter is anyway better than the former. This seems an issue 
with babel itself, so LyX should not try to correct it, but IMHO LyX must export 
the best latex construct, and \selectlanguage does not seem appropriate inside a 
sentence (does not work well on a single word outside a Flex inset).


--
Jean-Pierre


test_foreign_in_Flex.lyx
Description: application/lyx

Assertion in current trunk: WordList.cpp

[BH]

I'm noticing many of these assertions showing up in the console
whenever I type a non-space character:

lyx-devel/src/support/lassert.cpp(35): ASSERTION it != d->words_.end()
VIOLATED IN lyx-devel/src/WordList.cpp:76

BH

Re: Assertion in current trunk: WordList.cpp

[Richard Heck]

On 06/02/2011 12:47 PM, BH wrote:
> I'm noticing many of these assertions showing up in the console
> whenever I type a non-space character:
>
> lyx-devel/src/support/lassert.cpp(35): ASSERTION it != d->words_.end()
> VIOLATED IN lyx-devel/src/WordList.cpp:76
>
I don't see this right now under Linux.

rh

Re: Assertion in current trunk: WordList.cpp

[BH]

On Thu, Jun 2, 2011 at 1:22 PM, Richard Heck  wrote:
> On 06/02/2011 12:47 PM, BH wrote:
>> I'm noticing many of these assertions showing up in the console
>> whenever I type a non-space character:
>>
>> lyx-devel/src/support/lassert.cpp(35): ASSERTION it != d->words_.end()
>> VIOLATED IN lyx-devel/src/WordList.cpp:76
>>
> I don't see this right now under Linux.

Quitting and restarting LyX, I now don't see it either. I'll keep an
eye out to see if (and under what conditions) it happens again

BH

Re: Language change within Flex inset exports wrong babel construct

[Richard Heck]

On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
> Hello,
>
> I checked the pdf export of the French version of the Custolization
> manual, and I discovered a number of extra spaces after constructs
> where a word remained in English inside a Flex inset, e.g.:
>
> \begin_inset Flex Code
> status collapsed
>
> \begin_layout Plain Layout
>
> \lang english
> word
> \end_layout
>
> \end_inset
>
> This exports as
>
> \code{\selectlanguage{english}%
> word\selectlanguage{french}
> }
>
> If I turn the word in English outside the Flex inset, the exported
> code is
>
>  \foreignlanguage{english}{\code{word}}
>
> and the extra space disappears.
>
> So a correct export in the first case would be
>
> \code{\foreignlanguage{english}{word}}
>
> Attached is a simple example.
>
> I checked with other Flex insets (emphasize and such), same behaviour.
>
> Does this deserve a ticket ?
>
I think so. I've had a look at it, and it's more difficult than it might
seem. A comment in the code (this is output_latex.cpp, lines 770ff)
suggests that sometimes we do need to restore the language, whereas it
seems that in this sort of case we do not. That suggests we need a
layout tag.

Richard

Re: Lyx 2.0.0 OSX crashes

[Stephan Witt]

Am 01.06.2011 um 18:28 schrieb Murat Yildizoglu:

> Hello Stephan,
> 
> I have been using the new OSX binary and I see some strange things going on 
> with the cursor: it does not correctly indicate its position (it is always a 
> little bit on the right of its actual position), and when I insert or delete 
> characters, the operations do not take place at the correct place. The 
> problem does not seem to depend on the font  I choose for the screen.
> 
>  Do you observe this problem? 

Yes, now I do. Currently, I don't have much time for LyX. That's why I didn't 
notice it.
Until now I thought it's a problem starting with Qt-4.7 - but obviously it's a 
problem with Cocoa.
We have problems with the text width of drawn text and the cursor positioning.
The "solution" for Qt-4.7 should be activated in general.

Stephan

Re: r38934 - lyx-devel/trunk/src/frontends/qt4

[Jean-Marc Lasgouttes]

Le 02/06/11 22:46, sw...@lyx.org a écrit :

Author: switt
Date: Thu Jun  2 22:46:25 2011
New Revision: 38934
URL: http://www.lyx.org/trac/changeset/38934

Log:
Cocoa based Qt-4.6 needs to paint every character separately to match metrics 
computation, there is no Qt version dependency


But is there a cocoa dependency? Can we catch that?

JMarc

Re: Language change within Flex inset exports wrong babel construct

[Enrico Forestieri]

On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:

> On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
> > Hello,
> >
> > I checked the pdf export of the French version of the Custolization
> > manual, and I discovered a number of extra spaces after constructs
> > where a word remained in English inside a Flex inset, e.g.:
> >
> > \begin_inset Flex Code
> > status collapsed
> >
> > \begin_layout Plain Layout
> >
> > \lang english
> > word
> > \end_layout
> >
> > \end_inset
> >
> > This exports as
> >
> > \code{\selectlanguage{english}%
> > word\selectlanguage{french}
> > }
> >
> > If I turn the word in English outside the Flex inset, the exported
> > code is
> >
> >  \foreignlanguage{english}{\code{word}}
> >
> > and the extra space disappears.
> >
> > So a correct export in the first case would be
> >
> > \code{\foreignlanguage{english}{word}}
> >
> > Attached is a simple example.
> >
> > I checked with other Flex insets (emphasize and such), same behaviour.
> >
> > Does this deserve a ticket ?
> >
> I think so. I've had a look at it, and it's more difficult than it might
> seem. A comment in the code (this is output_latex.cpp, lines 770ff)
> suggests that sometimes we do need to restore the language, whereas it
> seems that in this sort of case we do not. That suggests we need a
> layout tag.

I am not sure it's so difficult. Note that \selectlanguage is used when the
language is changed at the start of a paragraph, otherwise \foreignlanguage
is used. In the given example, a workaround is inserting {} in ERT right
before "word" and then changing the language of "word" only. You can see
that \foreignlanguage is then employed. Maybe \selectlanguage could be
used at the start of a paragraph only if Text::isMainText() is true.

-- 
Enrico

Re: Language change within Flex inset exports wrong babel construct

[Enrico Forestieri]

On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:

> On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
> 
> > I think so. I've had a look at it, and it's more difficult than it might
> > seem. A comment in the code (this is output_latex.cpp, lines 770ff)
> > suggests that sometimes we do need to restore the language, whereas it
> > seems that in this sort of case we do not. That suggests we need a
> > layout tag.
> 
> I am not sure it's so difficult. Note that \selectlanguage is used when the
> language is changed at the start of a paragraph, otherwise \foreignlanguage
> is used. In the given example, a workaround is inserting {} in ERT right
> before "word" and then changing the language of "word" only. You can see
> that \foreignlanguage is then employed. Maybe \selectlanguage could be
> used at the start of a paragraph only if Text::isMainText() is true.

See attached patch.

-- 
Enrico
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(revisione 38933)
+++ src/output_latex.cpp(copia locale)
@@ -86,6 +86,8 @@ static TeXEnvironmentData prepareEnviron
 
BufferParams const & bparams = buf.params();
 
+   bool const maintext = text.isMainText();
+
// FIXME This test should not be necessary.
// We should perhaps issue an error if it is.
Layout const & style = text.inset().forcePlainLayout() ?
@@ -118,9 +120,12 @@ static TeXEnvironmentData prepareEnviron
string const doc_lang = use_pg ?
getPolyglossiaEnvName(doc_language) : doc_language->babel();
string const lang_begin_command = use_pg ?
-   "\\begin{$$lang}" : lyxrc.language_command_begin;
+   "\\begin{$$lang}" : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
-   "\\end{$$lang}" : lyxrc.language_command_end;
+   "\\end{$$lang}" : maintext ? lyxrc.language_command_end : "}";
+
+   bool const breakline = maintext || use_pg;
 
if (par_lang != prev_par_lang) {
if (!lang_end_command.empty() &&
@@ -129,9 +134,10 @@ static TeXEnvironmentData prepareEnviron
os << from_ascii(subst(
lang_end_command,
"$$lang",
-   prev_par_lang))
- // the '%' is necessary to prevent unwanted whitespace
- << "%\n";
+   prev_par_lang));
+   if (breakline)
+   // break line but prevent unwanted whitespace
+   os << safebreakln;
}
 
if ((lang_end_command.empty() ||
@@ -146,8 +152,9 @@ static TeXEnvironmentData prepareEnviron
os << "["
   << 
from_ascii(data.par_language->polyglossiaOpts())
   << "]";
- // the '%' is necessary to prevent unwanted whitespace
-   os << "%\n";
+   if (breakline)
+   // break line but prevent unwanted whitespace
+   os << safebreakln;
}
}
 
@@ -518,9 +525,12 @@ void TeXOnePar(Buffer const & buf,
string const outer_lang = use_pg ?
getPolyglossiaEnvName(outer_language) : outer_language->babel();
string const lang_begin_command = use_pg ?
-   "\\begin{$$lang}" : lyxrc.language_command_begin;
+   "\\begin{$$lang}" : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
-   "\\end{$$lang}" : lyxrc.language_command_end;
+   "\\end{$$lang}" : maintext ? lyxrc.language_command_end : "}";
+
+   bool const breakline = maintext || use_pg;
 
if (par_lang != prev_lang
// check if we already put language command in TeXEnvironment()
@@ -535,9 +545,10 @@ void TeXOnePar(Buffer const & buf,
{
os << from_ascii(subst(lang_end_command,
"$$lang",
-   prev_lang))
-  // the '%' is necessary to prevent unwanted 
whitespace
-  << "%\n";
+   prev_lang));
+   if (breakline)
+   // break line but prevent unwanted whitespace
+   os << safebreakln;
}
 
// We need to open a new language if we couldn't close the 
previous
@@ -594,8 +605,9 @@ void TeXOnePar(Buffer const & 

Re: Language change within Flex inset exports wrong babel construct

[Richard Heck]

On 06/02/2011 08:07 PM, Enrico Forestieri wrote:
> On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:
>
>> On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
>>
>>> I think so. I've had a look at it, and it's more difficult than it might
>>> seem. A comment in the code (this is output_latex.cpp, lines 770ff)
>>> suggests that sometimes we do need to restore the language, whereas it
>>> seems that in this sort of case we do not. That suggests we need a
>>> layout tag.
>> I am not sure it's so difficult. Note that \selectlanguage is used when the
>> language is changed at the start of a paragraph, otherwise \foreignlanguage
>> is used. In the given example, a workaround is inserting {} in ERT right
>> before "word" and then changing the language of "word" only. You can see
>> that \foreignlanguage is then employed. Maybe \selectlanguage could be
>> used at the start of a paragraph only if Text::isMainText() is true.
> See attached patch.
>
Well, you understand this part of the code much (MUCH!) better than I
do, which is pretty much not at all. Jurgen, you care to comment (for
branch)?

Richard

Re: r38934 - lyx-devel/trunk/src/frontends/qt4

[Stephan Witt]

Am 02.06.2011 um 23:00 schrieb Jean-Marc Lasgouttes:

> Le 02/06/11 22:46, sw...@lyx.org a écrit :
>> Author: switt
>> Date: Thu Jun  2 22:46:25 2011
>> New Revision: 38934
>> URL: http://www.lyx.org/trac/changeset/38934
>> 
>> Log:
>> Cocoa based Qt-4.6 needs to paint every character separately to match 
>> metrics computation, there is no Qt version dependency
> 
> But is there a cocoa dependency?

Yes, it seems so. But it is visible on Linux too, AFAIK.
And for Mac I'd like to make the future builds with Cocoa.

> Can we catch that?

If possible we should fix the rowpainter/text metrics cache stuff.
I don't know how difficult and time consuming (man power) this is...

Stephan

PS. I'm off for the next three days and perhaps I'm offline.