Re: test of math previews

[Enrico Forestieri]

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:

 Le 07/06/2015 12:49, Enrico Forestieri a écrit :
 On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:
 
 lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten
 from the list. The third inset works and is meant as a control. All 3 work
 without the patch.
 
 Here I was forgetting to also scan nested insets.
 
 lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
 activated. Does not assert without the patch.
 
 Here I did not account for the fact that also the macros defined in the
 symbols file are spotted. However, they do not have a valid DataMacro
 and this was causing the assert.
 
 Note that there is another bug here, but it is not a regression as it
 seems to be like that since ever (I checked with lyx versions since 1.3).
 The bug is that when using a symbol defined in the symbols file and this
 symbol requires a certain package, this requirement is not taken into
 account when generating the tex file for preview and thus latex fails.
 
 Notice that my thourough test is basically loading my current paper with
 preview on.
 
 I think that your paper is a very valid test case for macros ;)
 
 The attached patch solves all of the above problems (and also the segfault
 you report separately) for me. I am also attaching the patch for #9354
 accordingly updated. Please test both and report the issues you find.
 If your paper pass the tests, I think they are good for stable ;)
 
 
 Hello again,

Hi Guillaume,

 I tested the latest stable that seems to include the patches. As I already
 told Enrico, sorry for the delay as I did not have much free time until now.
 
 Thank you very much, this is really quick now. Thanks also for the timer for
 generating previews. Also I only had 1 segmentation error, which I could not
 reproduce unfortunately. It happened after changing from Instant preview:
 On to No maths and zooming. But probably it's part of the bigger issues
 with math macros, and again I could not reproduce.

Yes, I also think this is not specifically related to previews.

 Here are two examples that still fail.
 
 lyx-bug-undefined.lyx: the macro used in the argument of another macro is
 not defined. I had many bugs of this style, so let's hope that this one is
 representative, otherwise I'll come back with more errors.

Yes, I think it is. I was not taking into account that macros could also
occur in the arguments of other macros. Should be fixed in master now.

 lyx-bug-renewcommandx4.lyx: here we have again an error where renewcommandx
 is used while the macro is not defined beforehand. If it is really too error
 prone to keep track of what has already been defined then it is easy to work
 around by using \definecommandx:
   \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
 This seems to work at least for the way newcommandx is used in lyx previews
 (but maybe you have other reasons for distinguishing the cases newcommandx
 and renewcommandx that I don't understand).

This was due to a stupid typo and should also be fixed in master.
As regards your proposal, I don't like defining commands only to immediately
redefining them. And the fix was quite straightforward.

 Lastly I see that you prevent loading the microtype package by redefining
 \usepackage as you described earlier in the thread. While your redefinition
 of \usepackage seems to be very careful, I still think that passing the
 option draft to microtype is more reliable in case the user actually uses
 macros from microtype (in addition there's no need to test whether the user
 loads microtype).

I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.

 I don't want to be too much of a PITA so here's a patch to
 lyxpreview2bitmap.py that integrates my above two suggestions and solves the
 above two problems. (The bug in lyx-bug-undefined.lyx has to be addressed
 separately.) Parsing a file using regexps is always delicate so I think it's
 good that with my patch there are fewer of these. I do not think that I
 missed any subtlety in the existing code, but in any case you don't need to
 accept it as is.

In this particular case the regexp was simply wrong.

 Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening the
 preview is not generated because \Coloneqq is not defined. This looks like
 the bug that you are referring to in your message where packages for symbols
 are not properly loaded. But, notice that the preview is correctly generated
 on a second time, when entering and leaving the math inset. So maybe it's
 easier to fix than it seemed. But indeed it's not a regression.

Yes, this has always been the case, seemingly. However, now one can obtain
a preview after entering and exiting a math inset, while previously the
preview was simply never generated. So, this is a step forward. As regards
the reason it occurs, I 

Re: What should $\delta$ be exported as for plain text?

[Enrico Forestieri]

On Fri, Jun 19, 2015 at 08:13:45AM +, Guenter Milde wrote:

 On 2015-06-19, Scott Kostyshak wrote:
  We have all of the information/patches needed to resolve the following
  ticket: http://www.lyx.org/trac/ticket/2342
 
  What should we export for plain text for math? For example, if we have a
  math inset with $\delta$ what should be exported?
 
  I see the following options:
 
  1. \delta (current behavior)
  2. $\delta$ (Enrico's proposed behavior)
  3. delta
 
 4. δ 03B4 GREEK SMALL LETTER DELTA
 5. 훥 1D6E5MATHEMATICAL ITALIC CAPITAL DELTA
 
 Matching Unicode characters can be determined from the mathcommand in 
 unicodesymbols. This would also work for many non-alphabetical symbols
 like arrows and operators.
 
  I have mixed opinions. The reason why I originally liked option (1) is
  because $U$-shaped was exported as U-shaped. I could easily copy the
  abstract of my paper and paste that into a text box for submission of an
  abstract to a conference.
 
 I would argue, that $U$-shaped is wrong use of a formula inset in the first
 place (unless this is not in the common sense of shaped like a letter U but
 you define a variable $U$ for the shape of an object earlier in your text
 and use it then).
 
 There are many such cases of formula for text styling, like 20 $\mu$m
 (locigally and visually wrong, because the SI-prefix µ is a constant
 factor and (like any physical unit) must be written upright, not italic).
 
  However, for cases such as $\delta$, I am not so sure. Option (1) seems
  strange because it is hybrid LaTeX.
 
  Any thoughts?
 
 It really depends on the use case. Some examples:
 
 * (1) is a simple, informal representation for humans familiar with LaTeX
   syntax. Problematic for programmatic post-processing of the text.
 
 * (2) Can be annoying/hard to read/, but is correct and predictable.
   would fit nice when dropping the text into a text box of a page using 
   MathJax or a reStructuredText text (rST would requqire to change the
   $ $ into :math:` ` but otherwise uses LaTeX syntax for maths).
   
   Should formulas that can be easily expressed in text
   like 2x be wrapped in $$, too?
   
 * (4) Is preferred if the text encoding is Unicode and there is a normal
   international text font (with Greek but no mathematical alphanumerical
   characters). 
 
 * (5) Is preferred if the text encoding is Unicode and the target
   device/program has access to a mathematical font that includes the
   mathematical symbols.

What about the attached example? I fail to see how something different
than (2) can be used. It currently is pasted as

f(x)=\int_{0}^{x}f(y)dy
s   =(\begin{array}{cc}
a  b\end{array})\left(\begin{array}{c}
c\\
d
\end{array}\right)

-- 
Enrico
#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Formula 
\begin{align*}
f(x)  =\int_{0}^{x}f(y)dy\\
s  =(\begin{array}{cc}
a  b\end{array})\left(\begin{array}{c}
c\\
d
\end{array}\right)
\end{align*}

\end_inset


\end_layout

\end_body
\end_document

Regression in lyx2lyx box alignment

[Scott Kostyshak]

The attached file produces a left-aligned box in 2.1.3 but a centered
box for 2.2dev.

Uwe I remember you've done a lot of work on boxes in master. Can you
take a look? I did not do a git bisect (let me know if this would be
useful).

Scott
#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Box Frameless
position t
hor_pos c
has_inner_box 1
inner_pos t
use_parbox 0
use_makebox 0
width 100col%
special none
height 1in
height_special totalheight
status open

\begin_layout Plain Layout
This figure shows estimates of age effects controlling for cohort effects
 but not for period effects when all three effects are present.
 Even though single age dummies and single birth-year dummies...
\end_layout

\end_inset


\end_layout

\end_body
\end_document

Re: Re: 2.2

[Enrico Forestieri]

On Fri, Jun 19, 2015 at 04:02:35PM +0100, José Matos wrote:
 
 What do others, namely Georg and Enrico, think about this choice?

Well, you are the real expert here, so I trust you completely :)

-- 
Enrico

Re: Fix xe/lua compilation of our documentation that depends on babel

[Scott Kostyshak]

On Fri, Jun 19, 2015 at 08:26:22AM +, Guenter Milde wrote:
 On 2015-06-19, Jürgen Spitzmüller wrote:
 
  [-- Type: text/plain, Encoding: quoted-printable --]
 
  2015-06-18 22:56 GMT+02:00 Scott Kostyshak:
 
  Our documentation that depends on babel (meaning that there is preamble
  code that assumes that we are using babel and not polyglossia) does not
  compile with XeTeX or LuaTeX with system fonts. From what I understand,
  we can fix this by three ways:
 
  1. Remove the preamble code.
  2. Complicate the preamble code even more by conditioning on if we are
  using babel (is this indeed possible?).
 
  Yes, via \@ifpackageloaded{babel}{}{}
 
  3. Setting Always Babel in Document Settings (under Language).
 
  My personal preference is (1), simply because I think that simplifying
  the preamble is always good (and is a good example to our users).
 
 
  I agree. However, it might depend on the concrete case.
 
 I also vote for a case-by-case consideration: 
 
 * Simplyfying a document is good, but this should be seen in context of the
   complete document, not just preamble.
   
   Preamble code with minimal effect or equivalent GUI-alternatives might go.
   (Quite often, preamble code is taken over from times LyX was more
   restricted than today.)
   
   Another task of the documentation is to show that LyX does not restrict
   you to using the GUI for document configuration - if preamble code is the
   right thing, using it in our examples helps.  
 
 * With some languages, there is no advantage of using Polyglossia over
   Babel, Babel is actively maintained again.
 
   Setting Always Babel is the right thing here (a comment in the LaTeX
   preamble should make this explicite to the user/editor).
   
 * When demonstrating a clever trick that works with both, Polyglossia and
   Babel but requires different code, conditioning is the way to go. This
   should be the last option.
   

Thanks for this breakdown of scenario - action, Günter. Unless someone
beats me to it (please go ahead if anyone is interested) in a few days I
will do as you suggests.

Scott

Re: Fix xe/lua compilation of our documentation that depends on babel

[Jürgen Spitzmüller]

2015-06-18 22:56 GMT+02:00 Scott Kostyshak:

 Our documentation that depends on babel (meaning that there is preamble
 code that assumes that we are using babel and not polyglossia) does not
 compile with XeTeX or LuaTeX with system fonts. From what I understand,
 we can fix this by three ways:

 1. Remove the preamble code.
 2. Complicate the preamble code even more by conditioning on if we are
 using babel (is this indeed possible?).


Yes, via \@ifpackageloaded{babel}{}{}


 3. Setting Always Babel in Document Settings (under Language).

 My personal preference is (1), simply because I think that simplifying
 the preamble is always good (and is a good example to our users).


I agree. However, it might depend on the concrete case.

Jürgen



 Uwe, you are the documentation manager so of course you opinion is extra
 important. What are your thoughts?

 Scott

Re: Fix xe/lua compilation of our documentation that depends on babel

[Guenter Milde]

On 2015-06-19, Jürgen Spitzmüller wrote:

 [-- Type: text/plain, Encoding: quoted-printable --]

 2015-06-18 22:56 GMT+02:00 Scott Kostyshak:

 Our documentation that depends on babel (meaning that there is preamble
 code that assumes that we are using babel and not polyglossia) does not
 compile with XeTeX or LuaTeX with system fonts. From what I understand,
 we can fix this by three ways:

 1. Remove the preamble code.
 2. Complicate the preamble code even more by conditioning on if we are
 using babel (is this indeed possible?).

 Yes, via \@ifpackageloaded{babel}{}{}

 3. Setting Always Babel in Document Settings (under Language).

 My personal preference is (1), simply because I think that simplifying
 the preamble is always good (and is a good example to our users).


 I agree. However, it might depend on the concrete case.

I also vote for a case-by-case consideration: 

* Simplyfying a document is good, but this should be seen in context of the
  complete document, not just preamble.
  
  Preamble code with minimal effect or equivalent GUI-alternatives might go.
  (Quite often, preamble code is taken over from times LyX was more
  restricted than today.)
  
  Another task of the documentation is to show that LyX does not restrict
  you to using the GUI for document configuration - if preamble code is the
  right thing, using it in our examples helps.  

* With some languages, there is no advantage of using Polyglossia over
  Babel, Babel is actively maintained again.

  Setting Always Babel is the right thing here (a comment in the LaTeX
  preamble should make this explicite to the user/editor).
  
* When demonstrating a clever trick that works with both, Polyglossia and
  Babel but requires different code, conditioning is the way to go. This
  should be the last option.
  
Günter

Re: [LyX/master] Fix language nesting problem with polyglossia

[Kornel Benko]

Am Freitag, 19. Juni 2015 um 09:25:42, schrieb Juergen Spitzmueller 
sp...@lyx.org
 commit b1c68dccf8f920b97a8bd23f2c9ba60eeb7fdaf5
 Author: Juergen Spitzmueller sp...@lyx.org
 Date:   Fri Jun 19 09:25:11 2015 +0200
 
 Fix language nesting problem with polyglossia
 
 Part (?) of #9633
 

Thanks Jürgen. It helps a lot.

Kornel

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

Re: [LyX/master] Fix language nesting problem with polyglossia

[Kornel Benko]

Am Freitag, 19. Juni 2015 um 11:20:39, schrieb Kornel Benko kor...@lyx.org
 Am Freitag, 19. Juni 2015 um 09:25:42, schrieb Juergen Spitzmueller 
 sp...@lyx.org
  commit b1c68dccf8f920b97a8bd23f2c9ba60eeb7fdaf5
  Author: Juergen Spitzmueller sp...@lyx.org
  Date:   Fri Jun 19 09:25:11 2015 +0200
 
  Fix language nesting problem with polyglossia
 
  Part (?) of #9633
 

 Thanks Jürgen. It helps a lot.


There still are cases where setting different language for parts of text
leads to error.

The attached (lyx -e pdf5 lang_test1.lyx) is not compilable while the modified 
lang_test2.lyx is.

Kornel

lang_test1.lyx
Description: application/lyx


lang_test2.lyx
Description: application/lyx


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

Re: [PATCH] Auto feature for minibuffer toolbar

[Jean-Marc Lasgouttes]

Le 18/06/2015 17:41, Kornel Benko a écrit :

With this patch every key is going to the minibuffer. I tried cua and emacs 
binding.


Could you give more details on what you do?

JMarc

Re: What should $\delta$ be exported as for plain text?

[Guenter Milde]

On 2015-06-19, Scott Kostyshak wrote:
 We have all of the information/patches needed to resolve the following
 ticket: http://www.lyx.org/trac/ticket/2342

 What should we export for plain text for math? For example, if we have a
 math inset with $\delta$ what should be exported?

 I see the following options:

 1. \delta (current behavior)
 2. $\delta$ (Enrico's proposed behavior)
 3. delta

4. δ 03B4   GREEK SMALL LETTER DELTA
5. 훥 1D6E5  MATHEMATICAL ITALIC CAPITAL DELTA

Matching Unicode characters can be determined from the mathcommand in 
unicodesymbols. This would also work for many non-alphabetical symbols
like arrows and operators.

 I have mixed opinions. The reason why I originally liked option (1) is
 because $U$-shaped was exported as U-shaped. I could easily copy the
 abstract of my paper and paste that into a text box for submission of an
 abstract to a conference.

I would argue, that $U$-shaped is wrong use of a formula inset in the first
place (unless this is not in the common sense of shaped like a letter U but
you define a variable $U$ for the shape of an object earlier in your text
and use it then).

There are many such cases of formula for text styling, like 20 $\mu$m
(locigally and visually wrong, because the SI-prefix µ is a constant
factor and (like any physical unit) must be written upright, not italic).

 However, for cases such as $\delta$, I am not so sure. Option (1) seems
 strange because it is hybrid LaTeX.

 Any thoughts?

It really depends on the use case. Some examples:

* (1) is a simple, informal representation for humans familiar with LaTeX
  syntax. Problematic for programmatic post-processing of the text.

* (2) Can be annoying/hard to read/, but is correct and predictable.
  would fit nice when dropping the text into a text box of a page using 
  MathJax or a reStructuredText text (rST would requqire to change the
  $ $ into :math:` ` but otherwise uses LaTeX syntax for maths).
  
  Should formulas that can be easily expressed in text
  like 2x be wrapped in $$, too?
  
* (4) Is preferred if the text encoding is Unicode and there is a normal
  international text font (with Greek but no mathematical alphanumerical
  characters). 

* (5) Is preferred if the text encoding is Unicode and the target
  device/program has access to a mathematical font that includes the
  mathematical symbols.
  
Günter

Re: Re: 2.2

[José Matos]

I am back again after the end of the American-European-Portuguese Mathematical 
Societies Meeting, more than 1100 participants and some work in the local 
organizing committee. :-)

On Thursday 14 May 2015 20:05:12 Jean-Marc Lasgouttes wrote:
  Python 3 requires that when we open a file to already know the encoding or 
  else to treat the file as binary that is composed of bytes. And bytes and 
  strings do not talk to each other directly.
 
 I see. What is the ETA? Is this a prerequisite before we do a first beta?

It would be nice to have this ready before the beta to improve the test, but 
this should not delay the 2.2 release. The solution will be always better than 
what we have now.

In order to improve the reading of the different lyx files and to make the 
process more robust I was thinking about falling back chardet[1] with a file 
fails to load in python. The idea is to make the process more robust than what 
we have now.

What do others, namely Georg and Enrico, think about this choice?

Regards,

[1] https://pypi.python.org/pypi/chardet
-- 
José Abílio

Re: [PATCH] Auto feature for minibuffer toolbar

[Kornel Benko]

Am Freitag, 19. Juni 2015 um 16:12:17, schrieb Jean-Marc Lasgouttes 
lasgout...@lyx.org
 Le 18/06/2015 17:41, Kornel Benko a écrit :
  With this patch every key is going to the minibuffer. I tried cua and emacs 
  binding.
 
 Could you give more details on what you do?
 
 JMarc

From memory:
1.) start lyx, the minibuffer is already displayed.
2.) open any file
3.) M-x, the cursor is displayed in the minibuffer
4.) M-x, in the minibuffer appears 'x'
5.) click on a view, cursor is displayed in both, minibuffer and buffer
6.) enter 'abcd', it goes to minibuffer and not to buffer

Kornel


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

Re: [LyX/master] Fix language nesting problem with polyglossia

[Jürgen Spitzmüller]

2015-06-19 15:18 GMT+02:00 Kornel Benko kor...@lyx.org:


 There still are cases where setting different language for parts of text
 leads to error.

 The attached (lyx -e pdf5 lang_test1.lyx) is not compilable while the
 modified lang_test2.lyx is.


Thank you. I already have collected some other cases. I'll habe a look.

Jürgen



 Kornel

Re: test of math previews

[Guillaume M-M]

Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten
from the list. The third inset works and is meant as a control. All 3 work
without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my thourough test is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


I tested the latest stable that seems to include the patches. As I 
already told Enrico, sorry for the delay as I did not have much free 
time until now.


Thank you very much, this is really quick now. Thanks also for the timer 
for generating previews. Also I only had 1 segmentation error, which I 
could not reproduce unfortunately. It happened after changing from 
Instant preview: On to No maths and zooming. But probably it's part 
of the bigger issues with math macros, and again I could not reproduce.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro 
is not defined. I had many bugs of this style, so let's hope that this 
one is representative, otherwise I'll come back with more errors.


lyx-bug-renewcommandx4.lyx: here we have again an error where 
renewcommandx is used while the macro is not defined beforehand. If it 
is really too error prone to keep track of what has already been defined 
then it is easy to work around by using \definecommandx:

  \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx 
previews (but maybe you have other reasons for distinguishing the cases 
newcommandx and renewcommandx that I don't understand).


Lastly I see that you prevent loading the microtype package by 
redefining \usepackage as you described earlier in the thread. While 
your redefinition of \usepackage seems to be very careful, I still think 
that passing the option draft to microtype is more reliable in case the 
user actually uses macros from microtype (in addition there's no need to 
test whether the user loads microtype).


I don't want to be too much of a PITA so here's a patch to 
lyxpreview2bitmap.py that integrates my above two suggestions and solves 
the above two problems. (The bug in lyx-bug-undefined.lyx has to be 
addressed separately.) Parsing a file using regexps is always delicate 
so I think it's good that with my patch there are fewer of these. I do 
not think that I missed any subtlety in the existing code, but in any 
case you don't need to accept it as is.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening 
the preview is not generated because \Coloneqq is not defined. This 
looks like the bug that you are referring to in your message where 
packages for symbols are not properly loaded. But, notice that the 
preview is correctly generated on a second time, when entering and 
leaving the math inset. So maybe it's easier to fix than it seemed. But 
indeed it's not a regression.



Best regards
Guillaume



lyx-bug-undefined.lyx
Description: application/lyx


lyx-bug-renewcommandx4.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index a7d7623..fe9bea1 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -159,65 +159,35 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
-def_re = re.compile(r(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z])(.+))
-usepackage_re = re.compile(usepackage)
-userpreamble_re = re.compile(User specified LaTeX commands)
-enduserpreamble_re = re.compile(makeatother)
+documentclass_re = re.compile((documentclass))
+documentclass_pt_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
+def_re = 

Re: [LyX/master] Fix language nesting problem with polyglossia

[Jürgen Spitzmüller]

2015-06-19 17:26 GMT+02:00 Jürgen Spitzmüller sp...@lyx.org:

 2015-06-19 15:18 GMT+02:00 Kornel Benko kor...@lyx.org:


 There still are cases where setting different language for parts of text
 leads to error.

 The attached (lyx -e pdf5 lang_test1.lyx) is not compilable while the
 modified lang_test2.lyx is.


 Thank you. I already have collected some other cases. I'll habe a look.


These should be fixed (others are still open).

Jürgen

Re: Fix xe/lua compilation of our documentation that depends on babel

[Jürgen Spitzmüller]

2015-06-18 22:56 GMT+02:00 Scott Kostyshak:

> Our documentation that depends on babel (meaning that there is preamble
> code that assumes that we are using babel and not polyglossia) does not
> compile with XeTeX or LuaTeX with system fonts. From what I understand,
> we can fix this by three ways:
>
> 1. Remove the preamble code.
> 2. Complicate the preamble code even more by conditioning on if we are
> using babel (is this indeed possible?).
>

Yes, via \@ifpackageloaded{babel}{}{}


> 3. Setting "Always Babel" in Document Settings (under "Language").
>
> My personal preference is (1), simply because I think that simplifying
> the preamble is always good (and is a good example to our users).
>

I agree. However, it might depend on the concrete case.

Jürgen


>
> Uwe, you are the documentation manager so of course you opinion is extra
> important. What are your thoughts?
>
> Scott
>

Re: What should $\delta$ be exported as for plain text?

[Guenter Milde]

On 2015-06-19, Scott Kostyshak wrote:
> We have all of the information/patches needed to resolve the following
> ticket: http://www.lyx.org/trac/ticket/2342

> What should we export for plain text for math? For example, if we have a
> math inset with $\delta$ what should be exported?

> I see the following options:

> 1. \delta (current behavior)
> 2. $\delta$ (Enrico's proposed behavior)
> 3. delta

4. δ 03B4   GREEK SMALL LETTER DELTA
5. 훥 1D6E5  MATHEMATICAL ITALIC CAPITAL DELTA

Matching Unicode characters can be determined from the "mathcommand" in 
"unicodesymbols". This would also work for many non-alphabetical symbols
like arrows and operators.

> I have mixed opinions. The reason why I originally liked option (1) is
> because $U$-shaped was exported as U-shaped. I could easily copy the
> abstract of my paper and paste that into a text box for submission of an
> abstract to a conference.

I would argue, that $U$-shaped is wrong use of a formula inset in the first
place (unless this is not in the common sense of "shaped like a letter U" but
you define a variable $U$ for the shape of an object earlier in your text
and use it then).

There are many such cases of "formula for text styling", like "20 $\mu$m"
(locigally and visually wrong, because the SI-prefix µ is a constant
factor and (like any physical unit) must be written upright, not italic).

> However, for cases such as $\delta$, I am not so sure. Option (1) seems
> strange because it is hybrid LaTeX.

> Any thoughts?

It really depends on the use case. Some examples:

* (1) is a simple, informal representation for humans familiar with LaTeX
  syntax. Problematic for programmatic post-processing of the text.

* (2) Can be annoying/hard to read/, but is correct and predictable.
  would fit nice when dropping the text into a text box of a page using 
  MathJax or a reStructuredText text (rST would requqire to change the
  $ $ into :math:` ` but otherwise uses LaTeX syntax for maths).
  
  Should formulas that can be easily expressed in text
  like "2x" be wrapped in $$, too?
  
* (4) Is preferred if the text encoding is Unicode and there is a "normal"
  international text font (with Greek but no mathematical alphanumerical
  characters). 

* (5) Is preferred if the text encoding is Unicode and the target
  device/program has access to a "mathematical" font that includes the
  mathematical symbols.
  
Günter

Re: Fix xe/lua compilation of our documentation that depends on babel

[Guenter Milde]

On 2015-06-19, Jürgen Spitzmüller wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> 2015-06-18 22:56 GMT+02:00 Scott Kostyshak:

>> Our documentation that depends on babel (meaning that there is preamble
>> code that assumes that we are using babel and not polyglossia) does not
>> compile with XeTeX or LuaTeX with system fonts. From what I understand,
>> we can fix this by three ways:

>> 1. Remove the preamble code.
>> 2. Complicate the preamble code even more by conditioning on if we are
>> using babel (is this indeed possible?).

> Yes, via \@ifpackageloaded{babel}{}{}

>> 3. Setting "Always Babel" in Document Settings (under "Language").

>> My personal preference is (1), simply because I think that simplifying
>> the preamble is always good (and is a good example to our users).


> I agree. However, it might depend on the concrete case.

I also vote for a case-by-case consideration: 

* Simplyfying a document is good, but this should be seen in context of the
  complete document, not just preamble.
  
  Preamble code with minimal effect or equivalent GUI-alternatives might go.
  (Quite often, preamble code is taken over from times LyX was more
  restricted than today.)
  
  Another task of the documentation is to show that LyX does not restrict
  you to using the GUI for document configuration - if preamble code is "the
  right thing", using it in our examples helps.  

* With some languages, there is no advantage of using Polyglossia over
  Babel, Babel is actively maintained again.

  Setting "Always Babel" is the right thing here (a comment in the LaTeX
  preamble should make this explicite to the user/editor).
  
* When demonstrating a clever trick that works with both, Polyglossia and
  Babel but requires different code, conditioning is the way to go. This
  should be the last option.
  
Günter

Re: [LyX/master] Fix language nesting problem with polyglossia

[Kornel Benko]

Am Freitag, 19. Juni 2015 um 09:25:42, schrieb Juergen Spitzmueller 

> commit b1c68dccf8f920b97a8bd23f2c9ba60eeb7fdaf5
> Author: Juergen Spitzmueller 
> Date:   Fri Jun 19 09:25:11 2015 +0200
> 
> Fix language nesting problem with polyglossia
> 
> Part (?) of #9633
> 

Thanks Jürgen. It helps a lot.

Kornel

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

Re: [LyX/master] Fix language nesting problem with polyglossia

[Kornel Benko]

Am Freitag, 19. Juni 2015 um 11:20:39, schrieb Kornel Benko 
> Am Freitag, 19. Juni 2015 um 09:25:42, schrieb Juergen Spitzmueller 
> 
> > commit b1c68dccf8f920b97a8bd23f2c9ba60eeb7fdaf5
> > Author: Juergen Spitzmueller 
> > Date:   Fri Jun 19 09:25:11 2015 +0200
> >
> > Fix language nesting problem with polyglossia
> >
> > Part (?) of #9633
> >
>
> Thanks Jürgen. It helps a lot.
>

There still are cases where setting different language for parts of text
leads to error.

The attached (lyx -e pdf5 lang_test1.lyx) is not compilable while the modified 
lang_test2.lyx is.

Kornel

lang_test1.lyx
Description: application/lyx


lang_test2.lyx
Description: application/lyx


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

Re: [PATCH] Auto feature for minibuffer toolbar

[Jean-Marc Lasgouttes]

Le 18/06/2015 17:41, Kornel Benko a écrit :

With this patch every key is going to the minibuffer. I tried cua and emacs 
binding.


Could you give more details on what you do?

JMarc

Re: [PATCH] Auto feature for minibuffer toolbar

[Kornel Benko]

Am Freitag, 19. Juni 2015 um 16:12:17, schrieb Jean-Marc Lasgouttes 

> Le 18/06/2015 17:41, Kornel Benko a écrit :
> > With this patch every key is going to the minibuffer. I tried cua and emacs 
> > binding.
> 
> Could you give more details on what you do?
> 
> JMarc

From memory:
1.) start lyx, the minibuffer is already displayed.
2.) open any file
3.) M-x, the cursor is displayed in the minibuffer
4.) M-x, in the minibuffer appears 'x'
5.) click on a view, cursor is displayed in both, minibuffer and buffer
6.) enter 'abcd', it goes to minibuffer and not to buffer

Kornel


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

Re: Re: 2.2

[José Matos]

I am back again after the end of the American-European-Portuguese Mathematical 
Societies Meeting, more than 1100 participants and some work in the local 
organizing committee. :-)

On Thursday 14 May 2015 20:05:12 Jean-Marc Lasgouttes wrote:
> > Python 3 requires that when we open a file to already know the encoding or 
> > else to treat the file as binary that is composed of bytes. And bytes and 
> > strings do not talk to each other directly.
> 
> I see. What is the ETA? Is this a prerequisite before we do a first beta?

It would be nice to have this ready before the beta to improve the test, but 
this should not delay the 2.2 release. The solution will be always better than 
what we have now.

In order to improve the reading of the different lyx files and to make the 
process more robust I was thinking about falling back chardet[1] with a file 
fails to load in python. The idea is to make the process more robust than what 
we have now.

What do others, namely Georg and Enrico, think about this choice?

Regards,

[1] https://pypi.python.org/pypi/chardet
-- 
José Abílio

Re: [LyX/master] Fix language nesting problem with polyglossia

[Jürgen Spitzmüller]

2015-06-19 15:18 GMT+02:00 Kornel Benko :

>
> There still are cases where setting different language for parts of text
> leads to error.
>
> The attached (lyx -e pdf5 lang_test1.lyx) is not compilable while the
> modified lang_test2.lyx is.
>

Thank you. I already have collected some other cases. I'll habe a look.

Jürgen


>
> Kornel

Re: test of math previews

[Guillaume M-M]

Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten
from the list. The third inset works and is meant as a control. All 3 work
without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my "thourough test" is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


I tested the latest stable that seems to include the patches. As I 
already told Enrico, sorry for the delay as I did not have much free 
time until now.


Thank you very much, this is really quick now. Thanks also for the timer 
for generating previews. Also I only had 1 segmentation error, which I 
could not reproduce unfortunately. It happened after changing from 
"Instant preview: On" to "No maths" and zooming. But probably it's part 
of the bigger issues with math macros, and again I could not reproduce.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro 
is not defined. I had many bugs of this style, so let's hope that this 
one is representative, otherwise I'll come back with more errors.


lyx-bug-renewcommandx4.lyx: here we have again an error where 
renewcommandx is used while the macro is not defined beforehand. If it 
is really too error prone to keep track of what has already been defined 
then it is easy to work around by using \definecommandx:

  \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx 
previews (but maybe you have other reasons for distinguishing the cases 
newcommandx and renewcommandx that I don't understand).


Lastly I see that you prevent loading the microtype package by 
redefining \usepackage as you described earlier in the thread. While 
your redefinition of \usepackage seems to be very careful, I still think 
that passing the option draft to microtype is more reliable in case the 
user actually uses macros from microtype (in addition there's no need to 
test whether the user loads microtype).


I don't want to be too much of a PITA so here's a patch to 
lyxpreview2bitmap.py that integrates my above two suggestions and solves 
the above two problems. (The bug in lyx-bug-undefined.lyx has to be 
addressed separately.) Parsing a file using regexps is always delicate 
so I think it's good that with my patch there are fewer of these. I do 
not think that I missed any subtlety in the existing code, but in any 
case you don't need to accept it as is.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening 
the preview is not generated because \Coloneqq is not defined. This 
looks like the bug that you are referring to in your message where 
packages for symbols are not properly loaded. But, notice that the 
preview is correctly generated on a second time, when entering and 
leaving the math inset. So maybe it's easier to fix than it seemed. But 
indeed it's not a regression.



Best regards
Guillaume



lyx-bug-undefined.lyx
Description: application/lyx


lyx-bug-renewcommandx4.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index a7d7623..fe9bea1 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -159,65 +159,35 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
-def_re = re.compile(r"(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z])(.+)")
-usepackage_re = re.compile("usepackage")
-userpreamble_re = re.compile("User specified LaTeX commands")
-enduserpreamble_re = re.compile("makeatother")
+documentclass_re = re.compile("(documentclass)")
+documentclass_pt_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
+def_re = 

Re: [LyX/master] Fix language nesting problem with polyglossia

[Jürgen Spitzmüller]

2015-06-19 17:26 GMT+02:00 Jürgen Spitzmüller :

> 2015-06-19 15:18 GMT+02:00 Kornel Benko :
>
>>
>> There still are cases where setting different language for parts of text
>> leads to error.
>>
>> The attached (lyx -e pdf5 lang_test1.lyx) is not compilable while the
>> modified lang_test2.lyx is.
>>
>
> Thank you. I already have collected some other cases. I'll habe a look.
>

These should be fixed (others are still open).

Jürgen

Re: test of math previews

[Enrico Forestieri]

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:

> Le 07/06/2015 12:49, Enrico Forestieri a écrit :
> >On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:
> >>
> >>lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten
> >>from the list. The third inset works and is meant as a control. All 3 work
> >>without the patch.
> >
> >Here I was forgetting to also scan nested insets.
> >
> >>lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
> >>activated. Does not assert without the patch.
> >
> >Here I did not account for the fact that also the macros defined in the
> >symbols file are spotted. However, they do not have a valid DataMacro
> >and this was causing the assert.
> >
> >Note that there is another bug here, but it is not a regression as it
> >seems to be like that since ever (I checked with lyx versions since 1.3).
> >The bug is that when using a symbol defined in the symbols file and this
> >symbol requires a certain package, this requirement is not taken into
> >account when generating the tex file for preview and thus latex fails.
> >
> >>Notice that my "thourough test" is basically loading my current paper with
> >>preview on.
> >
> >I think that your paper is a very valid test case for macros ;)
> >
> >The attached patch solves all of the above problems (and also the segfault
> >you report separately) for me. I am also attaching the patch for #9354
> >accordingly updated. Please test both and report the issues you find.
> >If your paper pass the tests, I think they are good for stable ;)
> >
> 
> Hello again,

Hi Guillaume,

> I tested the latest stable that seems to include the patches. As I already
> told Enrico, sorry for the delay as I did not have much free time until now.
> 
> Thank you very much, this is really quick now. Thanks also for the timer for
> generating previews. Also I only had 1 segmentation error, which I could not
> reproduce unfortunately. It happened after changing from "Instant preview:
> On" to "No maths" and zooming. But probably it's part of the bigger issues
> with math macros, and again I could not reproduce.

Yes, I also think this is not specifically related to previews.

> Here are two examples that still fail.
> 
> lyx-bug-undefined.lyx: the macro used in the argument of another macro is
> not defined. I had many bugs of this style, so let's hope that this one is
> representative, otherwise I'll come back with more errors.

Yes, I think it is. I was not taking into account that macros could also
occur in the arguments of other macros. Should be fixed in master now.

> lyx-bug-renewcommandx4.lyx: here we have again an error where renewcommandx
> is used while the macro is not defined beforehand. If it is really too error
> prone to keep track of what has already been defined then it is easy to work
> around by using \definecommandx:
>   \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
> This seems to work at least for the way newcommandx is used in lyx previews
> (but maybe you have other reasons for distinguishing the cases newcommandx
> and renewcommandx that I don't understand).

This was due to a stupid typo and should also be fixed in master.
As regards your proposal, I don't like defining commands only to immediately
redefining them. And the fix was quite straightforward.

> Lastly I see that you prevent loading the microtype package by redefining
> \usepackage as you described earlier in the thread. While your redefinition
> of \usepackage seems to be very careful, I still think that passing the
> option draft to microtype is more reliable in case the user actually uses
> macros from microtype (in addition there's no need to test whether the user
> loads microtype).

I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.

> I don't want to be too much of a PITA so here's a patch to
> lyxpreview2bitmap.py that integrates my above two suggestions and solves the
> above two problems. (The bug in lyx-bug-undefined.lyx has to be addressed
> separately.) Parsing a file using regexps is always delicate so I think it's
> good that with my patch there are fewer of these. I do not think that I
> missed any subtlety in the existing code, but in any case you don't need to
> accept it as is.

In this particular case the regexp was simply wrong.

> Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening the
> preview is not generated because \Coloneqq is not defined. This looks like
> the bug that you are referring to in your message where packages for symbols
> are not properly loaded. But, notice that the preview is correctly generated
> on a second time, when entering and leaving the math inset. So maybe it's
> easier to fix than it seemed. But indeed it's not a regression.

Yes, this has always been the case, seemingly. However, now one can obtain
a preview after entering and exiting a math inset, 

Re: Re: 2.2

[Enrico Forestieri]

On Fri, Jun 19, 2015 at 04:02:35PM +0100, José Matos wrote:
> 
> What do others, namely Georg and Enrico, think about this choice?

Well, you are the real expert here, so I trust you completely :)

-- 
Enrico

Re: What should $\delta$ be exported as for plain text?

[Enrico Forestieri]

On Fri, Jun 19, 2015 at 08:13:45AM +, Guenter Milde wrote:

> On 2015-06-19, Scott Kostyshak wrote:
> > We have all of the information/patches needed to resolve the following
> > ticket: http://www.lyx.org/trac/ticket/2342
> 
> > What should we export for plain text for math? For example, if we have a
> > math inset with $\delta$ what should be exported?
> 
> > I see the following options:
> 
> > 1. \delta (current behavior)
> > 2. $\delta$ (Enrico's proposed behavior)
> > 3. delta
> 
> 4. δ 03B4 GREEK SMALL LETTER DELTA
> 5. 훥 1D6E5MATHEMATICAL ITALIC CAPITAL DELTA
> 
> Matching Unicode characters can be determined from the "mathcommand" in 
> "unicodesymbols". This would also work for many non-alphabetical symbols
> like arrows and operators.
> 
> > I have mixed opinions. The reason why I originally liked option (1) is
> > because $U$-shaped was exported as U-shaped. I could easily copy the
> > abstract of my paper and paste that into a text box for submission of an
> > abstract to a conference.
> 
> I would argue, that $U$-shaped is wrong use of a formula inset in the first
> place (unless this is not in the common sense of "shaped like a letter U" but
> you define a variable $U$ for the shape of an object earlier in your text
> and use it then).
> 
> There are many such cases of "formula for text styling", like "20 $\mu$m"
> (locigally and visually wrong, because the SI-prefix µ is a constant
> factor and (like any physical unit) must be written upright, not italic).
> 
> > However, for cases such as $\delta$, I am not so sure. Option (1) seems
> > strange because it is hybrid LaTeX.
> 
> > Any thoughts?
> 
> It really depends on the use case. Some examples:
> 
> * (1) is a simple, informal representation for humans familiar with LaTeX
>   syntax. Problematic for programmatic post-processing of the text.
> 
> * (2) Can be annoying/hard to read/, but is correct and predictable.
>   would fit nice when dropping the text into a text box of a page using 
>   MathJax or a reStructuredText text (rST would requqire to change the
>   $ $ into :math:` ` but otherwise uses LaTeX syntax for maths).
>   
>   Should formulas that can be easily expressed in text
>   like "2x" be wrapped in $$, too?
>   
> * (4) Is preferred if the text encoding is Unicode and there is a "normal"
>   international text font (with Greek but no mathematical alphanumerical
>   characters). 
> 
> * (5) Is preferred if the text encoding is Unicode and the target
>   device/program has access to a "mathematical" font that includes the
>   mathematical symbols.

What about the attached example? I fail to see how something different
than (2) can be used. It currently is pasted as

f(x)=\int_{0}^{x}f(y)dy
s   =(\begin{array}{cc}
a & b\end{array})\left(\begin{array}{c}
c\\
d
\end{array}\right)

-- 
Enrico
#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Formula 
\begin{align*}
f(x) & =\int_{0}^{x}f(y)dy\\
s & =(\begin{array}{cc}
a & b\end{array})\left(\begin{array}{c}
c\\
d
\end{array}\right)
\end{align*}

\end_inset


\end_layout

\end_body
\end_document

Re: Fix xe/lua compilation of our documentation that depends on babel

[Scott Kostyshak]

On Fri, Jun 19, 2015 at 08:26:22AM +, Guenter Milde wrote:
> On 2015-06-19, Jürgen Spitzmüller wrote:
> 
> > [-- Type: text/plain, Encoding: quoted-printable --]
> 
> > 2015-06-18 22:56 GMT+02:00 Scott Kostyshak:
> 
> >> Our documentation that depends on babel (meaning that there is preamble
> >> code that assumes that we are using babel and not polyglossia) does not
> >> compile with XeTeX or LuaTeX with system fonts. From what I understand,
> >> we can fix this by three ways:
> 
> >> 1. Remove the preamble code.
> >> 2. Complicate the preamble code even more by conditioning on if we are
> >> using babel (is this indeed possible?).
> 
> > Yes, via \@ifpackageloaded{babel}{}{}
> 
> >> 3. Setting "Always Babel" in Document Settings (under "Language").
> 
> >> My personal preference is (1), simply because I think that simplifying
> >> the preamble is always good (and is a good example to our users).
> 
> 
> > I agree. However, it might depend on the concrete case.
> 
> I also vote for a case-by-case consideration: 
> 
> * Simplyfying a document is good, but this should be seen in context of the
>   complete document, not just preamble.
>   
>   Preamble code with minimal effect or equivalent GUI-alternatives might go.
>   (Quite often, preamble code is taken over from times LyX was more
>   restricted than today.)
>   
>   Another task of the documentation is to show that LyX does not restrict
>   you to using the GUI for document configuration - if preamble code is "the
>   right thing", using it in our examples helps.  
> 
> * With some languages, there is no advantage of using Polyglossia over
>   Babel, Babel is actively maintained again.
> 
>   Setting "Always Babel" is the right thing here (a comment in the LaTeX
>   preamble should make this explicite to the user/editor).
>   
> * When demonstrating a clever trick that works with both, Polyglossia and
>   Babel but requires different code, conditioning is the way to go. This
>   should be the last option.
>   

Thanks for this breakdown of scenario -> action, Günter. Unless someone
beats me to it (please go ahead if anyone is interested) in a few days I
will do as you suggests.

Scott

Regression in lyx2lyx box alignment

[Scott Kostyshak]

The attached file produces a left-aligned box in 2.1.3 but a centered
box for 2.2dev.

Uwe I remember you've done a lot of work on boxes in master. Can you
take a look? I did not do a git bisect (let me know if this would be
useful).

Scott
#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Box Frameless
position "t"
hor_pos "c"
has_inner_box 1
inner_pos "t"
use_parbox 0
use_makebox 0
width "100col%"
special "none"
height "1in"
height_special "totalheight"
status open

\begin_layout Plain Layout
This figure shows estimates of age effects controlling for cohort effects
 but not for period effects when all three effects are present.
 Even though single age dummies and single birth-year dummies...
\end_layout

\end_inset


\end_layout

\end_body
\end_document