Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #141

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/141/

Re: Doxygen sourcedoc: Should there be a non-empty "main" page?

[Christian Ridderström]

On 6 April 2017 at 13:47, Jean-Marc Lasgouttes  wrote:

> Le 04/04/2017 à 22:08, Christian Ridderström a écrit :
>
>> Hi,
>>
>> Should the Doxygen docs have a "main page"? At
>> https://www.lyx.org/sourcedoc/latest/index.html
>> the main page is currently empty.
>>
>> I don't know if this is an error on my side, or if we simply haven't
>> created a main page.
>>
>
> I really know nothing about that.
>

Then maybe no one ever created a "main page". A "main page" is of course
not necessary.
/Christian

PS.
The "main page" is the default "tab" that you see when going to
https://www.lyx.org/sourcedoc/latest/index.html

Doxygen can take the content of e.g. a README or some other document and
use that as the main page.
The main page can be an introduction to developers, or simply a bunch of
links to other developer documents.
If anyone want's examples, here are some "main pages":

   - The KDE API Reference 
   - The Xerces-C++ Documentation
   
   - D-Bus documentation
   
   - Visualization Toolkit 
   - IBM's International Components for Unicode
   
   - CGAL 

(list above is copied form  https://www.stack.nl/~
dimitri/doxygen/results.html )




>
> JMarc
>
>

Re: Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #118

[Christian Ridderström]

On 6 April 2017 at 19:45, Jean-Marc Lasgouttes  wrote:

> I did that. Please remove your own patch.
>

I've modified the CI job to not apply _your_ patch ;-)
I've also started a new build, so in an hour or two we should see that it
works.
Thanks,
/C

Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #140

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/140/--
Started by an SCM change
Building remotely on lyx-linux3 (linux) in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
Cloning the remote Git repository
Using shallow clone
Avoid fetching tags
Honoring refspec on initial clone
Cloning repository git://git.lyx.org/lyx.git
 > git init 
 > 
 >  # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git --version # timeout=10
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/master^{commit} # timeout=10
Checking out Revision 74bcd5d26c558e5d540b2e3370d869a3f0469aff 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 74bcd5d26c558e5d540b2e3370d869a3f0469aff
 > git rev-list 8769c0fb750a8c46e6f053c5f73b3991393dcd73 # timeout=10
First time build. Skipping changelog.
[ubuntu-xenial-qt4-autotools-extended] $ /bin/sh -xe 
/tmp/hudson2495833187698955466.sh
+ patch -p1
patching file INSTALL
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file INSTALL.rej
patching file autogen.sh
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file autogen.sh.rej
patching file configure.ac
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file configure.ac.rej
patching file src/Makefile.am
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file src/Makefile.am.rej
The next patch would create the file src/tests/dummy_functions.cpp,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file src/tex2lyx/Makefile.am
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file src/tex2lyx/Makefile.am.rej
Build step 'Execute shell' marked build as failure

Re: [patch] support for \baselineskip

[Uwe Stöhr]

El 06.04.2017 a las 10:50, Jean-Marc Lasgouttes escribió:


Concerning the code in Length::inInch: the value normally needs to take
into account the line spacing setting of the document. I understand that
it is difficult to obtain here, but a minimal action would be to
document this shortcoming in the source until we can think of a good
strategy.


OK, what about this?:

// baselineskip is approx. 1.2 times the font size for the cmr fonts
// the exact value is defined in the document class and cannot obtained 
by LyX

result = val_ * em_width * 1.2 / 100;

thanks and regards
Uwe

Re: [patch] support for \baselineskip

[Uwe Stöhr]

El 06.04.2017 a las 09:41, Jean-Marc Lasgouttes escribió:


Le 06/04/2017 à 08:08, Pavel Sanda a écrit :

I don't have strong opinion whether BLS should or shouldn't be available
for both horizontal and vertical. I however dislike the code you posted.
The easy way how to 'fix' it is to drop all these removeUnits on various
places and thus effectively allow horizontal BLS as well.


I thought about it again and in the past my opinion was that it is not 
LyX's task to tell the user what is sensible. So yes, a unit is a unit, 
it is up to the user to decide. if he wants e.g. to use BLS for the box 
frame separation we should not forbid it.


So I opt to allow BLS for all lengths.

regards Uwe

Re: [patch] support for fontspec options

[Uwe Stöhr]

El 06.04.2017 a las 12:01, Jürgen Spitzmüller escribió:


I mean we need to think about a sensible UI instead of cluttering the
dialog with three more line widgets. And I think we should not attempt to
push in one feature after the other at this point, but rather focus on
stabilizing and finishing LyX 2.3.

More precisely, the dialog gets oversized by this addition, the widgets are
not lined up sensibly, and I also think they should go into some "Advanced
settings" sub-dialog that only shows up when fontspec is actually used and
that gives some sensible structure.


Boh.
OK, I calm down. I accept criticism if it is constructive. So let's be 
constructive.


Since many years LyX misses the feature to input options to the font 
loading commands \setmainfont etc. We did not act for 5 years because 
you said exactly the same as today that it is not the right time:

http://www.lyx.org/trac/ticket/8226#comment:2

There might perhaps never be the right time, so let's eventually do it! 
The feature is important for several languages:


\setmainfont[Script=Devanagari

is sometimes necessary. Inputting the Script option is currently almost 
impossible if you are not a LaTeX master. Therefore the right way to do 
this is to provide an input field for all options people might need. So 
we speak about adding simply 3 line edit fields.


I think the fields are at the right tab where I put them. Of course we 
can rearrange their position and size. Please make a proposal.


I implemented that the fields are only active when fontspec is actually 
used. If you see here mistakes in my patch, please tell me.


So again, please be constructive and help.

Concerning the features of LyX 2.3. Scott encouraged me to have a look 
for features I proposed to LyX 2.3. So I took some spare time after a 
long break with LyX and came up with some patches for new features.
Unless a feature freeze is announced one could work on features. If I am 
encouraged to look and decide what could be part of LyX 2.3 I think I 
should be treated fair and my patches should be reviewed in a normal manner.
I already skipped things I won't have time to implement or that would be 
too massive changes for LyX 2.3.


thanks and regards
Uwe

Re: Re-organizing templates and examples folders (#8715)

[Richard Heck]

On 04/06/2017 03:46 AM, Jean-Marc Lasgouttes wrote:
> Le 06/04/2017 à 05:44, Scott Kostyshak a écrit :
>> Dear all,
>>
>> There is a proposal to reorganize templates and examples folders. If we
>> do want to do it, I think that soon would be a good time.
>>
>> To take a look at the proposal, check out:
>>
>>   http://www.lyx.org/trac/ticket/8715
>
> I did take a look, but I do not have an opinion about it, sorry.

I have no objection.

Richard

Re: Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #118

[Jean-Marc Lasgouttes]

I did that. Please remove your own patch.

JMarc

Le 6 avril 2017 13:47:40 GMT+02:00, Jean-Marc Lasgouttes  a 
écrit :
>> I've forgotten the topic, but perhaps this patch should go into
>master
>> at some suitable point.
>
>I am going to do it right now.

Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #139

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/139/--
Started by an SCM change
Building remotely on lyx-linux3 (linux) in workspace 

[WS-CLEANUP] Deleting project workspace...
Cloning the remote Git repository
Using shallow clone
Avoid fetching tags
Honoring refspec on initial clone
Cloning repository git://git.lyx.org/lyx.git
 > git init 
 > 
 >  # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git --version # timeout=10
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/master^{commit} # timeout=10
Checking out Revision 8769c0fb750a8c46e6f053c5f73b3991393dcd73 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 8769c0fb750a8c46e6f053c5f73b3991393dcd73
 > git rev-list 22c4a24a360b4607551ff5275cf24ac5f5e5eb4a # timeout=10
First time build. Skipping changelog.
[ubuntu-xenial-qt4-autotools-extended] $ /bin/sh -xe 
/tmp/hudson7200593813416344583.sh
+ patch -p1
patching file INSTALL
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file INSTALL.rej
patching file autogen.sh
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file autogen.sh.rej
patching file configure.ac
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file configure.ac.rej
patching file src/Makefile.am
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file src/Makefile.am.rej
The next patch would create the file src/tests/dummy_functions.cpp,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file src/tex2lyx/Makefile.am
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file src/tex2lyx/Makefile.am.rej
Build step 'Execute shell' marked build as failure

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 5 April 2017 21.08.09 WEST Enrico Forestieri wrote:
> Most probably you have some non-ascii characters in a \DeclareLaTeXClass
> line in some of your layout files. Now those files are explicitly read as
> utf-8 encoded. If this is so, the attached patch should help.

It should be something like that since I do not get any error when running 
with python 2.7.13.

A conditional change based on what Enrico showed (open for python 2 and 
io.open) will make the code work for python 2 but the same problem then 
remains for python 3...

What needs to be done is to see if all the operations done on those files can 
be done as bytes (binary files) and not as strings (text files). For some of 
those cases the change should be easy.
-- 
José Abílio

Re: Doxygen sourcedoc: Should there be a non-empty "main" page?

[Jean-Marc Lasgouttes]

Le 04/04/2017 à 22:08, Christian Ridderström a écrit :

Hi,

Should the Doxygen docs have a "main page"? At
https://www.lyx.org/sourcedoc/latest/index.html
the main page is currently empty.

I don't know if this is an error on my side, or if we simply haven't
created a main page.


I really know nothing about that.

JMarc

Re: Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #118

[Jean-Marc Lasgouttes]

Le 04/04/2017 à 21:44, Christian Ridderström a écrit :

I modified the configuration of the CI job such that it applies your
patch before trying to build:
   0001-Require-automake-1.14-and-autoconf-2.65.patch

I've forgotten the topic, but perhaps this patch should go into master
at some suitable point.


I am going to do it right now.

JMarc

Re: [LyX/master] Work around bug in QTextLine::xToCursor

[Jean-Marc Lasgouttes]

Le 06/04/2017 à 05:05, Scott Kostyshak a écrit :

To make sure I understand, you are against the attached patch because
the changes are not as complicated as in the iconv case, right?


No, I would be against the attached because it is wrong: what should be 
in ifdef is the

  if(){} else{}
and the comment above it. The patch does some code cleanup that is good 
in any case.


What I meant earlier is that I was lazy to do it and what not sure it 
would worth the effort. But please have a go at it.


JMarc

Re: tex2lyx tests currently broken on master

[Kornel Benko]

Am Mittwoch, 5. April 2017 um 23:21:12, schrieb Scott Kostyshak 

> The tex2lyx tests are currently broken on master.
> 
> Scott

For me it looks like src/tex2lyx/test/runtests.py is not python3 ready yet.

The errors are
  File "/usr2/src/lyx/lyx-git/src/tex2lyx/test/runtests.py", line 100
 print 'Executing: ' + cmd + "\n"
  ^
SyntaxError: Missing parentheses in call to 'print'

Kornel


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

Re: [patch] support for fontspec options

[Jürgen Spitzmüller]

2017-04-06 9:31 GMT+02:00 Uwe Stöhr :

>
> *From: *Jürgen Spitzmüller
> *Sent: *Donnerstag, 6. April 2017 08:53‎
>
> > This looks rather ugly. I think we should integrate this properly for
> 2.4 and not hectically push something into 2.3.
>
> What do you mean? This is what I always wanted to do since 5 years. So
> this is not hectic. You argumented the same 5 years ago and nothing
> happened since then. So please what exactly do you want and what you don't
> like with my patch?
>

I mean we need to think about a sensible UI instead of cluttering the
dialog with three more line widgets. And I think we should not attempt to
push in one feature after the other at this point, but rather focus on
stabilizing and finishing LyX 2.3.

More precisely, the dialog gets oversized by this addition, the widgets are
not lined up sensibly, and I also think they should go into some "Advanced
settings" sub-dialog that only shows up when fontspec is actually used and
that gives some sensible structure.

But as I said, I do not think now is the right time, since this needs more
thought.

Jürgen


>
> Thanks and regards
>  Uwe
>
>

Re: [LyX/master] support to indent formulas

[Jean-Marc Lasgouttes]

Le 06/04/2017 à 11:03, "Uwe Stöhr" a écrit :

Gesendet: Donnerstag, 06. April 2017 um 04:03 Uhr
Von: "Scott Kostyshak" 

Please see my attached before/after screenshots. What are the
before/after screenshots you see on Windows?


Hi Scott,

what do you mean? I added 3 elements to the UI.
I cannot see anything strange here. (I will send screenshots later)
If you do please feel free to adjust the UI file accordingly.


Seen from here, it is pretty ugly :) Something is wrong with the 
vertical position of your new elements. What would be wrong with moving 
them to the 'text layout' pane? I think that they belong more there than 
in math options (which is really a LaTeX thing).


Regards,
JMarc

Re: [LyX/master] Add support to cross out characters

[Jean-Marc Lasgouttes]

Le 06/04/2017 à 10:59, "Uwe Stöhr" a écrit :

If you find a better solution to paint the strokes, please improve my drawing 
routine accordingly.


That is not how it works. Actually, I propose to add a rule to our 
coding rules that says that no code which does not take in account zoom 
and DPI when drawing should be accepted (with the usual exceptions, of 
course).


It is not as if we were still in 1995, we have retina screens now. A lot 
of work has been done recently to take dpi/zoom into account, we do not 
want that to degrade with new code.


As always, the right thing to do is "use the source, Luke".

You search for ulem.sty, which is full of horrible code. Then you search 
in there for the definition of \xout, which is admittedly still weird, 
but simpler:

\def\xout{\bgroup \markoverwith{\hbox to.35em{\hss/\hss}}\ULon}

What does it tell us? That the strike out is obtained with a `/' 
character, and that it is spaced with 0.35em. This should be enough to 
make an easy and good lookalike screen representation.


Is it enough information for you?

JMarc

Re: [LyX/master] support to indent formulas

[Uwe Stöhr]

> Gesendet: Donnerstag, 06. April 2017 um 04:03 Uhr
> Von: "Scott Kostyshak" 
> 
> Please see my attached before/after screenshots. What are the
> before/after screenshots you see on Windows?

Hi Scott,

what do you mean? I added 3 elements to the UI.
I cannot see anything strange here. (I will send screenshots later)
If you do please feel free to adjust the UI file accordingly.

thanks and regards
Uwe

Re: [LyX/master] Add support to cross out characters

[Uwe Stöhr]

Von: "Scott Kostyshak" 

> Uwe, I've tested but there are a lot of crosses. For example, see the
attached screenshot. It seems the number of crosses depends on the level
of zoom, which I don't think makes sense. Also, if you change the font
size, the number of crosses in the PDF output does not change.

It is impossible to draw in every case the same number of strokes. I 
experimented a bit with including the zoom level but then one could get no 
stroke for low zooms. I think my solution is a good compromise. LyX is WYSISYM 
not WYSIWYG.

In the output ulem draws as many strokes that will fit to the formatting 
length. But this length depends of course on the font, the document-wide font 
size (could also be different for each document class) and the surrounding 
local font size commands .

If you find a better solution to paint the strokes, please improve my drawing 
routine accordingly.

>> + if changed == True:
> 
> Also (comment for anyone), why not just the following?
> 
> if changed:

I don't know. I just stole some code from existing lyx2lyx routines to save 
time.

regards Uwe

Re: [patch] support for \baselineskip

[Jean-Marc Lasgouttes]

Le 02/04/2017 à 14:52, Uwe Stöhr a écrit :

After only 7 years ;-) I found time to finish a patch to support
\baselineskip, see attached. The patch is a fileformat change.

\baselineskip is the distance between the baseline of 2 subsequent text
lines in a paragraph. Therefore \vspace{\baselineskip} is a useful spacing.


Concerning the code in Length::inInch: the value normally needs to take 
into account the line spacing setting of the document. I understand that 
it is difficult to obtain here, but a minimal action would be to 
document this shortcoming in the source until we can think of a good 
strategy.


JMarc

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 5 April 2017 21.48.21 WEST Uwe Stöhr wrote:
> El 05.04.2017 a las 22:08, Enrico Forestieri escribió:
> > Most probably you have some non-ascii characters in a \DeclareLaTeXClass
> > line in some of your layout files. Now those files are explicitly read as
> > utf-8 encoded. If this is so, the attached patch should help.
> 
> Yes. This is necessary. Moreover all open() commands must replaced by
> io.open() to assure that we use the right encoding.

In the cases were we need to care. And with python3 the distinction is more 
present since the default strings have an encoding associated (they are 
unicode) while for python2 that is not true.
 
> However, I am not very familiar with Python. I only acted because after
> José's commits I could no longer even start LyX.

Actually my commits were unrelated to the problems you described. :-)

> > Another consequence of the recent changes is that if someone has old
> > layouts containing latin1 characters then configure will now misteriously
> > fail.
> 
> I thought layout2layout takes care of this. If not, then this is
> necessary to add this feature for LyX 2.3.

I agree. I would expect for our files to have the same encoding after lyx 1.6 
(utf-8).

> regards Uwe


-- 
José Abílio

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 5 April 2017 09.38.24 WEST Kornel Benko wrote:
> ATM cmake(lyx) checks for python >= 2.7.

I stand corrected then. :-)

Thank you Kornel.

-- 
José Abílio

Re: [LyX/master] Add support to cross out characters

[José Abílio Matos]

On Thursday, 6 April 2017 02.56.51 WEST Scott Kostyshak wrote:
> I see it's used in other places in lyx2lyx (grep for '== True'), so
> perhaps this is convention in Python?

Nope.

The convention is the former:

if changed:
...

-- 
José Abílio

Re: [LyX/master] support to indent formulas

[Jean-Marc Lasgouttes]

Le 05/04/2017 à 22:22, Uwe Stöhr a écrit :

commit 808339790c94b0bffa316efddc7e913bd83c91c7
Author: Uwe Stöhr 
Date:   Wed Apr 5 22:22:47 2017 +0200

support to indent formulas

- adds support for the general document class option fleqn
- adds support to specify the formula indentation
- fileformat change


Dear Uwe,

Once again, I am too slow for you. Here are my comments after the battle:


+2017-04-05 Uwe Stöhr 
+   * Format incremented to 538: support for document class option "fleqn"
+ and for length \mathindent.
+ New buffer parameters
+ - \is_formula_indent


The question is not whether the equation is indented, it is whether it 
is flushed left.
The paramter (and all it incarantion in the code) should be \fleqn or 
\flush_equation or \flush_math



+ - \formula_indentation


- (minor) although the term formula is used in the file format, it is a 
remnant of old times (like Style/Layout) that we should not encourage. 
In this case \math_indent is a much better choice, especially since this 
is the LaTeX term.


- I am really not sure that we need to expose a way to change the value 
of the indentation: this is something that is decided by the class 
author, and it is trivial to change in preamble for people who know what 
they are doing. The idea is "if you do not know how to change it, you 
probably do not need to change it. If you do know how to do it, think 
twice before doing it". Moreover, it makes the dialog scroll, as Scott 
pointed out.



> +def convert_mathindent(document):
> +" add the \\is_formula_indent tag "
> +k = find_token(document.header, "\\quotes_style", 0)
> +document.header.insert(k, "\\is_formula_indent 0")

How come that you do not need to add your formula_indentation parameter?

A nice touch here would be to detect fleqn in the document options, and 
change it to brand new support.



HSpace formula_indentation;


Should be named mathindent

> +  formula_indentation = string();

Please do not initialize a HSpace object with a string.


+HSpace const & BufferParams::getFormulaIndentation() const
+{
+   return pimpl_->formula_indentation;
+}


getMathIndent() (OK, I stop here, you see what I mean by now)


+   // only output something when it is not the default of 30pt
+   if (getFormulaIndentation().asLyXCommand() != "30pt") {
+   os << "\\setlength{\\mathindent}{"
+  << 
from_utf8(getFormulaIndentation().asLatexCommand())
+  << "}\n";


Where does this magic number of 30pt come from???

I have two issues with it:
- the default should be an empty length (remember I coded that to avoid 
ugly hardcoding)

  that lets the textclass do what it wants
- when trying to set such default length, please try to see what the 
length actually is, or ask for help


In such case, I follow the "Use the source, Luke" mantra. Let's see... 
We are looking for \mathindent. If I search this in LaTeX sources, I see 
(for example in fleqn.clo) that the consensus is

  \mathindent\leftmargini
which means that the margin is equal to the margin used for first-level 
itemize.


But what is this value, I hear you ask? Well, grep is my friend again, 
and I see in main class something like

\if@twocolumn
  \setlength\leftmargini  {2em}
\else
  \setlength\leftmargini  {2.5em}
\fi

Here we have our answer: the left margin is 2.5em in general, but not 
always. As you can imagine, document class authors are creative.


A good default value would also be to use
TL;DR: my advice is to use an empty value for default indentation (my 
real advice is to drop it, remember), and to use 2.5em (or the same as 
what we use for the itemize environment) if you need this default value 
for screen display uses (more on this at the end).



+   if (bp_.is_formula_indent) {
+   // fill value if empty to avoid LaTeX errors
+   if (mathsModule->FormulaIndentLE->text().isEmpty())
+   mathsModule->FormulaIndentLE->setText("0");


Don't we have length validator for this kind of things? (anyway you 
should allow empty values, see above).



Finally, I will comment on what I do not see:  there is no code to show 
to the user what the result is. So long for WYSIWYM. The math displayed 
equations should be flushed left (with the correct indentation) on 
screen. It is more work, but without it, the patch is just taking dialog 
screen real-estate for something that is just a few lines in a preamble.


Hope this helps (really)
JMarc

Re: Re-organizing templates and examples folders (#8715)

[Jean-Marc Lasgouttes]

Le 06/04/2017 à 05:44, Scott Kostyshak a écrit :

Dear all,

There is a proposal to reorganize templates and examples folders. If we
do want to do it, I think that soon would be a good time.

To take a look at the proposal, check out:

  http://www.lyx.org/trac/ticket/8715


I did take a look, but I do not have an opinion about it, sorry.

JMarc

Re: [patch] support for \baselineskip

[Jean-Marc Lasgouttes]

Le 06/04/2017 à 08:08, Pavel Sanda a écrit :

I don't have strong opinion whether BLS should or shouldn't be available
for both horizontal and vertical. I however dislike the code you posted.
The easy way how to 'fix' it is to drop all these removeUnits on various
places and thus effectively allow horizontal BLS as well.
The other and more painful way would be to write more generic code,
where you distinguish vertXhoriz type of spacings and allow them
only appropriate places _and_ use this distinction for all our defined spaces.


I agree too that this length stuff is getting out of hand. After some 
time one has to stop a bit and think about it.


JMarc

Re: [patch] support for fontspec options

[Uwe Stöhr]

 From: Jürgen SpitzmüllerSent: Donnerstag, 6. April 2017 08:53‎> This looks rather ugly. I think we should integrate this properly for 2.4 and not hectically push something into 2.3.What do you mean? This is what I always wanted to do since 5 years. So this is not hectic. You argumented the same 5 years ago and nothing happened since then. So please what exactly do you want and what you don't like with my patch?Thanks and regards Uwe

Re: [patch] support for fontspec options

[Jürgen Spitzmüller]

This looks rather ugly. I think we should integrate this properly for 2.4
and not hectically push something into 2.3.

Jürgen

2017-04-06 3:26 GMT+02:00 Uwe Stöhr :

> El 06.04.2017 a las 03:24, Uwe Stöhr escribió:
>
> Attached is the screenshot of the simple UI.
>>
>
> Now it is attached.
>
> regards Uwe
>

Re: [patch] support for \baselineskip

[Pavel Sanda]

Uwe Stöhr wrote:
>>> +   // remove baselineskip from width units
>>> +   columnWidthUnitLC->removeUnit(Length::BLS);
>>> +   tabularWidthUnitLC->removeUnit(Length::BLS);
>>
>> This is ugly.
>>

>> Unless you want to be consistent and do it for all 'senseless' combinations
>> of vert/horiz spacing used in opposite context drop these specific
>> conditions spilled all over the place.
>
> I don't understand. Do you want to have the BLS unit for all lengths, no
> matter if for vertical or horizontal? I asked for your opinion because I 

I don't have strong opinion whether BLS should or shouldn't be available
for both horizontal and vertical. I however dislike the code you posted.
The easy way how to 'fix' it is to drop all these removeUnits on various
places and thus effectively allow horizontal BLS as well.
The other and more painful way would be to write more generic code,
where you distinguish vertXhoriz type of spacings and allow them
only appropriate places _and_ use this distinction for all our defined spaces.

Pavel