Re: [LyX/master] Refine lang nesting fix

[Georg Baum]

Scott Kostyshak wrote:

> Much better. The following tests still fail (compared to not using your
> patch and reverting the commit in question, where these tests pass)
> 
> ctest -R
> "(export/doc/de/Additional_pdf4_systemF|
export/doc/fr/Additional_pdf4_systemF|export/doc/he/Tutorial_pdf4_systemF|
export/examples/he/example_lyxified_pdf4_systemF)"
> 
> These tests are equivalent to doing the following manual steps (using
> de/Additional.lyx as an example):
> 
> 1. Open de/Additional.lyx
> 2. Click the box "Use non-TeX Fonts"
> 3. Set Roman, Sans Serif, and Typewriter all to FreeSans.
> 4. Compile (with XeTeX).
> 
> Can you reproduce?

Yes, and after some debugging and with the hint from Jürgen that there 
should not be a difference between babel and polyglossia I understand the 
reason: OutputState::open_polyglossia_lang_ serves a double purpose: It is 
used to mark the needed language at the beginning of an environment (which 
is not yet output), and it also tracks the language that has already been 
written. Since this is only done for environments, there are a few other 
places where language changes are written, but 
OutputState::open_polyglossia_lang_ is not touched. I fixed this in the 
attached patch, which replaces the previous one. The fix is a minimal one, 
and I am pretty sure that one can construct corner cases where it does not 
work. I am also sure that such corner cases existed before the introduction 
of OutputState::open_polyglossia_lang_. In the long term I think we'll ned 
to simplify this complicated nesting logic (also for CJK languages and CJK 
encodings) by using some stack-like structures. However, I don't think that 
now is a good time to do that (and I don't have the time to do it anyway).

Scott, could you please look whether the tests do still produce any 
regression? Unfortunately I cannot do it myself, since I don't know what is 
expected to fail, and since the tests run ages (even on my new machine). Is 
there any possibility to make use of more than one core?

In the future we need to better document how these tests can be run, and we 
must not allow the error explosion that we currently have. This would be a 
huge time saver.


Georgdiff --git a/src/output_latex.cpp b/src/output_latex.cpp
index 94c261d..cca533b 100644
--- a/src/output_latex.cpp
+++ b/src/output_latex.cpp
@@ -703,6 +703,8 @@ void TeXOnePar(Buffer const & buf,
 "$$lang",
 prev_lang))
 			   << lang_command_termination;
+			if (prev_lang == state->open_polyglossia_lang_)
+state->open_polyglossia_lang_ = "";
 		}
 
 		// We need to open a new language if we couldn't close the previous
@@ -1249,6 +1251,8 @@ void latexParagraphs(Buffer const & buf,
 	"$$lang",
 	mainlang))
 			<< '\n';
+		if (state->open_polyglossia_lang_ == mainlang)
+			state->open_polyglossia_lang_ = "";
 	}
 
 	// If the last paragraph is an environment, we'll have to close

Re: When to court Qt 5.6?

[Scott Kostyshak]

On Wed, Oct 14, 2015 at 06:16:30PM -0400, Scott Kostyshak wrote:
> On Wed, Oct 14, 2015 at 09:13:12PM +0200, Georg Baum wrote:
> > Scott Kostyshak wrote:
> 
> > > Any other opinions?
> 
> OK sounds like there is enough of a consensus. From what I understand,
> after explanations Liviu is now OK with this as well.

The Qt 5.6 beta has been delayed to October 27th. From what I
understand, the delay is due to time needed for creating binaries. I
suppose this is good (as opposed to a critical bug found), as to me it
suggests like it won't be delayed again:
http://blog.gmane.org/gmane.comp.lib.qt.releasing/month=20151001

In any case, there are still some matters that we should clear up before
our alpha release so I am now proposing that we release our alpha after
October 27th.

Scott

Re: [LyX/master] Refine lang nesting fix

[Kornel Benko]

Am Sonntag, 18. Oktober 2015 um 21:42:08, schrieb Georg Baum 

> Scott Kostyshak wrote:
> 
> > Much better. The following tests still fail (compared to not using your
> > patch and reverting the commit in question, where these tests pass)
> > 
> > ctest -R
> > "(export/doc/de/Additional_pdf4_systemF|
> export/doc/fr/Additional_pdf4_systemF|export/doc/he/Tutorial_pdf4_systemF|
> export/examples/he/example_lyxified_pdf4_systemF)"
> > 
> > These tests are equivalent to doing the following manual steps (using
> > de/Additional.lyx as an example):
> > 
> > 1. Open de/Additional.lyx
> > 2. Click the box "Use non-TeX Fonts"
> > 3. Set Roman, Sans Serif, and Typewriter all to FreeSans.
> > 4. Compile (with XeTeX).
> > 
> > Can you reproduce?
> 
> Yes, and after some debugging and with the hint from Jürgen that there 
> should not be a difference between babel and polyglossia I understand the 
> reason: OutputState::open_polyglossia_lang_ serves a double purpose: It is 
> used to mark the needed language at the beginning of an environment (which 
> is not yet output), and it also tracks the language that has already been 
> written. Since this is only done for environments, there are a few other 
> places where language changes are written, but 
> OutputState::open_polyglossia_lang_ is not touched. I fixed this in the 
> attached patch, which replaces the previous one. The fix is a minimal one, 
> and I am pretty sure that one can construct corner cases where it does not 
> work. I am also sure that such corner cases existed before the introduction 
> of OutputState::open_polyglossia_lang_. In the long term I think we'll ned 
> to simplify this complicated nesting logic (also for CJK languages and CJK 
> encodings) by using some stack-like structures. However, I don't think that 
> now is a good time to do that (and I don't have the time to do it anyway).
> 
> Scott, could you please look whether the tests do still produce any 
> regression? Unfortunately I cannot do it myself, since I don't know what is 
> expected to fail, and since the tests run ages (even on my new machine). Is 
> there any possibility to make use of more than one core?

I can do that ...
The specified tests passed with your patch.
...
Test project /usr/BUILD/BuildLyxGitQt5.4
Start 603: export/doc/de/Additional_pdf4_systemF
1/4 Test #603: export/doc/de/Additional_pdf4_systemF ..   Passed   
18.54 sec
Start 953: export/doc/fr/Additional_pdf4_systemF
2/4 Test #953: export/doc/fr/Additional_pdf4_systemF ..   Passed   
12.05 sec
Start 1149: export/doc/he/Tutorial_pdf4_systemF
3/4 Test #1149: export/doc/he/Tutorial_pdf4_systemF    Passed   
33.66 sec
Start 3500: export/examples/he/example_lyxified_pdf4_systemF
4/4 Test #3500: export/examples/he/example_lyxified_pdf4_systemF ...   Passed   
 7.84 sec

100% tests passed, 0 tests failed out of 4

> In the future we need to better document how these tests can be run, and we 
> must not allow the error explosion that we currently have. This would be a 
> huge time saver.

+1

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [patches] the last ones before 2.2

[Guillaume Munch]

Le 17/10/2015 12:00, Georg Baum a écrit :

Guillaume Munch wrote:

But if the memory usage is still too high, various solutions:
* pointer comparison (what is your opinion on pointer comparison vs.
using a counter?)
* variable-length integers encoding.
* pointer comparison, but somehow keep the possibility to use a counter
instead for using jointly with the other debug options.


The two last ones are probably too complicated. As I see it, we do now have
a trade off between easier debugging (ids), and less memory consumption
(pointers). Apart from that, both solutions would work. Since you are the
one who is probably doing most of the debugging work please decide, I am now
fine with either solution.



The choice is simple, because just adding a new variable member to math
insets as per the attached (trivial) .diff leads to new segfaults with
math macros. The .diff must be applied to current master (before or
after my upcoming TexRow patches). Compiler is g++ 4.9.2 in C++11 mode
(I did not try with C++98). Then open the attached segv-math-demo.lyx,
select all and hold Ctrl+C until it crashes (not more than a few seconds).

The backtrace is as follows:

#0  0x00816c47 in lyx::MathMacro::optionals 
(this=this@entry=0x978e140)

at ../../src/mathed/MathMacro.cpp:733
#1  0x007f8bf9 in lyx::MathData::detachMacroParameters (
this=this@entry=0x6451df0, cur=cur@entry=0x0, 
macroPos=macroPos@entry=0)

at ../../src/mathed/MathData.cpp:528
#2  0x007facab in lyx::MathData::updateMacros (this=0x6451df0,
cur=cur@entry=0x0, mc=..., utype=utype@entry=lyx::OutputUpdate)
at ../../src/mathed/MathData.cpp:437
#3  0x004b7fac in lyx::Buffer::updateMacroInstances (
this=this@entry=0x8885a60, utype=utype@entry=lyx::OutputUpdate)
at ../../src/Buffer.cpp:3365
#4  0x00567a28 in lyx::(anonymous namespace)::putClipboard (
paragraphs=..., docclass=std::shared_ptr (count 5, weak 0) 0x2ad5390,
plaintext=L"(…)"...)
at ../../src/CutAndPaste.cpp:548
#5  0x00568f32 in lyx::cap::copySelection (cur=...,
plaintext=L"(…)"...)
at ../../src/CutAndPaste.cpp:1026


In addition, I saw the following message several times while preparing
the MWE (though I do not know if it's relevant):

Buffer.cpp (334): Warning: a buffer should not have two parents!


The crash does not occur if we only apply the diff on InsetMath.h, i.e.
if we change the structure of the class but leave the new member
uninitialized. (An ironic twist on the g++-5 crash-on-copy bug which
occurs when some variables are not initialized that I saw passing on the
list, if you want.)

So it seems in that mathed/ is in a brittle state. This is a deeper
reason for just using pointers for now. This seems serious. Or did
I miss something obvious to C++ experts?


Guillaume

diff --git a/src/mathed/InsetMathNest.cpp b/src/mathed/InsetMathNest.cpp
index 94b4d68..e8e2778 100644
--- a/src/mathed/InsetMathNest.cpp
+++ b/src/mathed/InsetMathNest.cpp
@@ -81,14 +81,16 @@ using cap::selClearOrDel;
 
 
 InsetMathNest::InsetMathNest(Buffer * buf, idx_type nargs)
-	: InsetMath(buf), cells_(nargs), lock_(false)
+	: InsetMath(buf), cells_(nargs), lock_(false),
+	  uid_(0)
 {
 	setBuffer(*buf);
 }
 
 
 InsetMathNest::InsetMathNest(InsetMathNest const & inset)
-	: InsetMath(inset), cells_(inset.cells_), lock_(inset.lock_)
+	: InsetMath(inset), cells_(inset.cells_), lock_(inset.lock_),
+	  uid_(0)
 {}
 
 
diff --git a/src/mathed/InsetMathNest.h b/src/mathed/InsetMathNest.h
index b9cc1f6..326bbef 100644
--- a/src/mathed/InsetMathNest.h
+++ b/src/mathed/InsetMathNest.h
@@ -193,6 +193,8 @@ private:
 	bool cursorMathForward(Cursor & cur);
 	/// move cursor backwards
 	bool cursorMathBackward(Cursor & cur);
+	///
+	int uid_;
 
 protected:
 	/// we store the cells in a vector


segv-math-demo.lyx
Description: application/lyx


segv-math-demo-aux.lyx
Description: application/lyx

Re: [patches] the last ones before 2.2

[Guillaume Munch]

Le 17/10/2015 21:19, Guillaume Munch a écrit :

Le 17/10/2015 15:13, Richard Heck a écrit :

On 10/16/2015 12:34 PM, Guillaume Munch wrote:


The id is now only on InsetMathNest. Please, tell me if you still feel
uncomfortable about this id and I will try a version with pointer
comparison. This incremental id, I found, gives interesting clues in
debug mode when trying to understand how math in LyX works by seeing
how much the id changes. For instance it has been invaluable for
knowing how to even start looking for the cause of the bug addressed
by patch 0006.


Is it possible to activate this only in devel mode? not in release mode?
Then we have the convenience of the debug feature, while keeping memory
usage in releases low.

Richard




I thought about that, but I do not want to introduce a divergence in the
behaviour of release mode compared to devel mode in a fundamental
aspect. This can open the door to a lot of problems: unreproducibility
of bugs, etc.



...as perfectly exemplified by the segfault that I just described.

Re: Does LyX work with MBP Retina screen?

[Scott Kostyshak]

On Sat, Oct 17, 2015 at 06:31:27PM +0200, Stephan Witt wrote:
> Am 16.10.2015 um 22:49 schrieb Christopher Menzel :
> 
> > Greetings Stephan,
> > 
> > One issue: the “Do not swap Apple and Control keys” checkbox does not seem 
> > to have any effect — whether it’s checked or unchecked, my Control keys — I 
> > map CapsLock to Ctrl as well — behave as if they are Apple Command keys and 
> > the Apple Command key behaves as if it’s the Control key.
> 
> Hi Chris,
> 
> yes, indeed. I didn't notice this until now. I have to check for the details 
> again, but it looks like a problem with Qt5 introduced with version 5.4 :( - 
> (See https://github.com/Swordfish90/cool-retro-term/issues/203). I don't have 
> 5.3 at hand but with 4.8 it works again.

It would be interesting to know whether this bug exists still with Qt
5.6 beta when it is released.

Scott

Re: [LyX/master] Refine lang nesting fix

[Scott Kostyshak]

On Sun, Oct 18, 2015 at 09:42:08PM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > Much better. The following tests still fail (compared to not using your
> > patch and reverting the commit in question, where these tests pass)
> > 
> > ctest -R
> > "(export/doc/de/Additional_pdf4_systemF|
> export/doc/fr/Additional_pdf4_systemF|export/doc/he/Tutorial_pdf4_systemF|
> export/examples/he/example_lyxified_pdf4_systemF)"
> > 
> > These tests are equivalent to doing the following manual steps (using
> > de/Additional.lyx as an example):
> > 
> > 1. Open de/Additional.lyx
> > 2. Click the box "Use non-TeX Fonts"
> > 3. Set Roman, Sans Serif, and Typewriter all to FreeSans.
> > 4. Compile (with XeTeX).
> > 
> > Can you reproduce?
> 
> Yes, and after some debugging and with the hint from Jürgen that there 
> should not be a difference between babel and polyglossia I understand the 
> reason: OutputState::open_polyglossia_lang_ serves a double purpose: It is 
> used to mark the needed language at the beginning of an environment (which 
> is not yet output), and it also tracks the language that has already been 
> written. Since this is only done for environments, there are a few other 
> places where language changes are written, but 
> OutputState::open_polyglossia_lang_ is not touched. I fixed this in the 
> attached patch, which replaces the previous one. The fix is a minimal one, 
> and I am pretty sure that one can construct corner cases where it does not 
> work. I am also sure that such corner cases existed before the introduction 
> of OutputState::open_polyglossia_lang_.

Thanks for taking a look at this mess, Georg.

> Scott, could you please look whether the tests do still produce any 
> regression?

Do you mean with the patch in this email? Or do you mean on current
master, after commit 86325e50?

> Unfortunately I cannot do it myself, since I don't know what is 
> expected to fail

Yes we will have to discuss this. One issue is that you need a lot of
dependencies to run all the tests. Another issue is that a couple of
commits have broken many (100s) of tests:

edd37de8
8bd66109

Both commits did not introduce bugs themselves (although they might have
introduced regressions from the perspective of the user) but they did
expose current LyX bugs. I'm not sure what can be done here. Either we
turn the tests off in order to get cleaner test output or we fix the
exposed bugs:

http://www.lyx.org/trac/ticket/9633
http://www.lyx.org/trac/ticket/9744

> and since the tests run ages (even on my new machine). Is 
> there any possibility to make use of more than one core?

Yes, Kornel has improved things a lot for this. To run with 8 cores you
can do
ctest -j8

There are still problems with running the tests in parallel. I run them
on just one core to be safe, but I think a reasonable approach is to run
them on multiple cores, then re-run the failed test. So something like:

ctest -j8
ctest --rerun-failed

In other words, I think that there is more of a concern of tests failing
when they should pass than the other way around, when doing the tests in
parallel.

> In the future we need to better document how these tests can be run, and we 
> must not allow the error explosion that we currently have. This would be a 
> huge time saver.

+1

Scott
> 
> 
> Georg

> diff --git a/src/output_latex.cpp b/src/output_latex.cpp
> index 94c261d..cca533b 100644
> --- a/src/output_latex.cpp
> +++ b/src/output_latex.cpp
> @@ -703,6 +703,8 @@ void TeXOnePar(Buffer const & buf,
>   "$$lang",
>   prev_lang))
>  << lang_command_termination;
> + if (prev_lang == state->open_polyglossia_lang_)
> + state->open_polyglossia_lang_ = "";
>   }
>  
>   // We need to open a new language if we couldn't close the 
> previous
> @@ -1249,6 +1251,8 @@ void latexParagraphs(Buffer const & buf,
>   "$$lang",
>   mainlang))
>   << '\n';
> + if (state->open_polyglossia_lang_ == mainlang)
> + state->open_polyglossia_lang_ = "";
>   }
>  
>   // If the last paragraph is an environment, we'll have to close
> 

Re: [LyX/master] colored-boxes.lyx: new example file for the tcolorbox.module

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:10:13AM +0200, Uwe Stöhr wrote:
> commit ce933b1e14fc9e18f2cb3f987ce84d068a3b1d44
> Author: Uwe Stöhr 
> Date:   Mon Oct 19 07:10:09 2015 +0200
> 
> colored-boxes.lyx: new example file for the tcolorbox.module
> 
> - also improve the tcolorbox.module
> 
> This is a fileformat change - only to be able to revert the new styles 
> defined in the module.

Is that code in the preample needed, Uwe? It would be nice to keep the
examples as clean as possible. This example file does not compile with
system fonts (using either XeTeX or LuaTeX). If I delete everything from
the preamble after 

% increase link area for cross-references and autoname them,

then the system font tests pass.

Does increasing the link area for cross-references and autoname them
help to show off the features in the example file that are the main
purpose?

Scott

Re: [LyX/master] tcolorbox.module: uniform whitespace

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:15:21AM +0200, Uwe Stöhr wrote:
> commit 8da453fd30a1df085782ae5a3772a07cea38b77b
> Author: Uwe Stöhr 
> Date:   Mon Oct 19 07:15:18 2015 +0200
> 
> tcolorbox.module: uniform whitespace

Uwe can you please catch up on reading the emails on the mailing list
before making new commits? We need to be on the same page.

Scott

Re: Translations and 2.2.alpha?

[Scott Kostyshak]

On Sun, Oct 18, 2015 at 01:56:57PM -0400, Richard Heck wrote:
> 
> Do we want to give our translators a chance to get stuff in for 2.2.alpha?
> Or has that already been done?

This has not been done yet. I had thought this was done at a later
stage. For example it seems for 2.1.0 it was done before beta:
https://www.mail-archive.com/search?l=mid=50E0.1050404%40lyx.org

Should we do it before alpha?

Do we first need Uwe to copy the existing translations from 2.0.x to
2.1.x like he requested in the following message?:
https://www.mail-archive.com/lyx-docs@lists.lyx.org/msg07586.html

Is this up-to-date for 2.2dev?
http://www.lyx.org/I18n-trunk

Scott

Re: [LyX/master] chkconfig.ltx: add packages supported by LyX

[Vincent van Ravesteijn]

Op 18-10-2015 om 15:21 schreef Uwe Stöhr:

commit c246ca2d43663dbce3d3052b2ae9459b45bf4acc
Author: Uwe Stöhr 
Date:   Sun Oct 18 15:21:50 2015 +0200

 chkconfig.ltx: add packages supported by LyX
 
 - also update Win installer package list (trimspaces is required by tcolorbox but not listed as required in the tcolorbox manual)


diff --git a/lib/chkconfig.ltx b/lib/chkconfig.ltx
index 86cef0c..b0f3cd4 100644
--- a/lib/chkconfig.ltx
+++ b/lib/chkconfig.ltx
@@ -268,6 +268,7 @@
  
  
  %%% Packages

+\TestPackage[a0poster}
...
+\TestPackage[sciposter}
...
+\TestPackage[wallpaper}


Uwe,

It looks to me that the rectangular brackets should be replaced by curly 
braces.


Vincent

Re: lyx.org down for me

[Jean-Marc Lasgouttes]

Le 18/10/15 01:29, Richard Heck a écrit :

Not sure where to go from there :( I am not sure that we have a live
contact with people of stw-bonn.de who host us.


Lars set that up, didn't he?


I just sent a message to netad...@stw-bonn.de

JMarc

Re: lyx.org down for me

[Jean-Marc Lasgouttes]

Le 18/10/15 15:31, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I just sent a message to netad...@stw-bonn.de


Seems to have worked ;-)


Yes, these guys are quite responsive.

JMarc

Re: [LyX/master] Refine lang nesting fix

[Georg Baum]

Jürgen Spitzmüller wrote:

> Am Freitag 16 Oktober 2015, 23:50:38 schrieb Georg Baum:
>
>> Under the assumption that the old babel output was correct the fix is
>> indeed trivial.
> 
> I am not sure. When a babel language environment is used
> (\begin{otherlanguage}...\end{otherlanguage}), I'd expect the same nesting
> issues than with polyglossia.

That makes sense, however the regression occured with \foreignlanguage. I'll 
have another look.


Georg

Re: lyx.org down for me

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> I just sent a message to netad...@stw-bonn.de

Seems to have worked ;-)


Georg

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

[Georg Baum]

Guenter Milde wrote:

> Unfortunately, there is also no agreement on the way out, as the proper
> fix requires changing unicodesymbols, tex2lyx, and test-files (bugs in
> the expected test outcome).

I thought we agreed on a solution? You explained how the inconsistency in 
unicodesymbols needs to be fixed, you suggested changes to the .tex test 
files to improve test coverage, and you pointed to a bug in tex2lyx which 
(if fixed) does of course need changed .lyx test references. IIRC the only 
different opinions where in how these changes should be grouped in one or 
more commits, but these are not too important, and for stuff like this I'd 
always say those who do the work decide how to do it.

> I'll try workaround 2) sometimes in the next days...

That would be very nice!


Georg

Re: #9772: Crash when copying to clipboard

[Gilles Moyse]

I have this bug on a computer I do not manage, i.e. administrators do it
for us and we do not have any root access, so I'm afraid I won't be able to
add much here.
For now they have downgraded our version to 2.1.2 and they will install
2.1.5 which will contain the fix I guess.
So I think this ticket can be closed.

Thanks a lot for your help!

___
Gilles Moyse
LinkedIn : fr.linkedin.com/in/gillesmoyse
Twitter : @GillesMoyse 
Mobile : +33 6 38 03 71 63

On 18 October 2015 at 17:31, LyX Ticket Tracker  wrote:

> #9772: Crash when copying to clipboard
> --+-
>  Reporter:  gilles.moyse  |   Owner:  lasgouttes
>  Type:  defect|  Status:  new
>  Priority:  normal|   Milestone:
> Component:  general   | Version:  2.1.4
>  Severity:  major |  Resolution:
>  Keywords:  infoneeded|
> --+-
>
> Comment (by baum):
>
>  Replying to [comment:3 gilles.moyse]:
>  > I haven't compiled it so I don't know which version has been used.
>  However, it's very likely the same problem than #9771.
>
>  If you tell us where you got the binary from then we can probably find out
>  which compiler was used.
>
>  > I've seen it has been fixed. How can I fix it too? Do I need to download
>  the latest sources? Are there some specific command line options to be
>  passed to gcc?
>
>  No commandline options, we changed the source code to avoid the compiler
>  bug. The fix is not in any released LyX version yet, so you can either get
>  the latest git sources (see http://www.lyx.org/HowToUseGIT, use the 2.1.x
>  branch), or you can download the 2.1.4 source package and then apply the
>  change [12ab5dd81/lyxgit].
>
> --
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor
>

Re: Regression in lyx2lyx box alignment

[Georg Baum]

Richard Heck wrote:

> On 10/16/2015 05:15 PM, Scott Kostyshak wrote:
>> On Fri, Oct 16, 2015 at 11:04:32PM +0200, Georg Baum wrote:
>>
 In my opinion this is a serious regression. Many users have boxes.
>>> We should not release the alpha version with this regression IMHO.
>> OK. This issue is now considered a blocker of alpha.
> 
> Agreed. Georg, do you have an opinion what should be done here? I
> remember the discussion back in the day, but don't remember what options
> there were then.

I am not sure what to do. Since this regression is in for such a long time 
(about 5 months), it is not possible anymore to fix this for all cases. 
Whatever we do, we will silently change the output of some documents. This 
is what I found out (depending whether the new alignment handling is kept or 
not, see below for possible reasons not to keep it):

1) New alignment handling is kept: In this case the attached patch would fix 
lyx2lyx. All old documents which are converted with the patched lyx2lyx will 
be fine, all 2.2 documents that are created in format 489 or nwer will be 
fine as well. All old documents that have been converted with the unpatched 
lyx2lyx will produce wrong output for boxes with these parameters: makebox 
is not used and not (type Boxed and without inner box).

2) New alignment handling is not kept, first option: Do nothing in lyx2lyx, 
declare the new alignment handling a bug, remove the new alignment code from 
InsetBox.cpp and no additional format change. All 2.2 documents that were 
produced in format 489 or later until the alignment code revert will then 
produce wrong output for boxes with the parameters mentioned above.

3) New alignment handling is not kept, second option: Apply the attached 
patch, remove the new alignment code from InsetBox.cpp and do a new format 
change with lyx2lyx code to adjust the alignment settings. The documents 
that produce wrong output are the same ones as in 1).

What is wrong with the new alignment handling? It is IMHO confusing and not 
needed, we have paragraph alignment. Look at the attached example: I set the 
box alignment to centered, and the paragraph alignment to right. This will 
produce \centered \begin{flushright} which does not really make sense. I 
think we should try to be consistent and not offer different ways to do the 
same thing unless there is a very clear advantage (which I do not see in 
this case). Has this change been discussed on the list? If yes, then I 
missed it.

I do therefore vote for removing the new aligment handling again. I have no 
strong optinion whether we should prefer option 2) or 3). Basically we need 
to decide which is more important: Old documents imported into 2.2 during 
the last 5 months, or new documents created during the last 5 months? I 
slightly tend towards 2), also because it is less work.


Georg
diff --git a/development/FORMAT b/development/FORMAT
index 7861f62..e1c0cd1 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -59,6 +59,13 @@ adjustments are made to tex2lyx and bugs are fixed in lyx2lyx.
  	  - thickness
  	  - separation
  	  - shadowsize
+	  Previously, the horizontal position was ignored except for the
+	  following parameter combinations:
+	  - fixed width and type Boxed and without inner box
+	  - fixed width and any type   and withinner box and with makebox
+	  Now, it is also used for the parameter combination below:
+	  - makebox is not used and not (type Boxed and without inner box)
+
 
 2015-04-21 Jürgen Spitzmüller 
  	* Format incremented to 488: Rewrite the Glosse insets (Glosse and Tri-Glosse).
diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index a09ad22..3c0672e 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@ -968,11 +968,23 @@ def convert_BoxFeatures(document):
 
 i = 0
 while True:
-i = find_token(document.body, "height_special", i)
+i = find_token(document.body, "\\begin_inset Box", i)
 if i == -1:
 return
-document.body[i+1:i+1] = ['thickness "0.4pt"', 'separation "3pt"', 'shadowsize "4pt"']
-i = i + 4
+j = find_token(document.body, "height_special", i)
+if j == -1:
+document.warning("Malformed LyX document: Can't find height_special parameter of Box inset")
+i += 1
+continue
+boxtype = get_value(document.body, "\\begin_inset Box", i, i+1, "Frameless")
+use_makebox = get_value(document.body, "use_makebox", i, j, "0")
+has_inner_box = get_value(document.body, "has_inner_box", i, j, "0")
+if use_makebox == "0" and not (boxtype == "Boxed" and has_inner_box == 0):
+k = find_token(document.body, "hor_pos", i, j)
+if k != -1:
+document.body[k:k+1] = ["hor_pos \"l\""]
+document.body[j+1:j+1] = ['thickness "0.4pt"', 'separation "3pt"', 'shadowsize "4pt"']
+i = j + 1
 
 
 def revert_BoxFeatures(document):

Translations and 2.2.alpha?

[Richard Heck]

Do we want to give our translators a chance to get stuff in for 
2.2.alpha? Or has that already been done?


Richard

bug 9626: new handling of "LyX" is unintuitive

[Georg Baum]

Bug 9626 complains about the removed automatic translation of LyX, LaTeX etc 
to logos. Since this was done intentionally, we will not revert it. However, 
the questions whether we can do something to help people who work on our 
docs (these are the only ones who need the logos very often). This is the 
reason why the bug has 2.2.0 milestone. There have been several suggestions 
in trac:

- the menu to insert logos is shifted to a new menu Insert -> Logos
- adding a tooltip to InsetSpecialChar
- rename the top level menu "Special Characters" to "Special Characters & 
Strings"

Shall we do any of the above? Or anything else? I want to close this bug to 
get it from my list.


Georg