Re: Again: New Win installer for LyX 2.2.2 available

[Richard Heck]

PS I'll let you do the announcement, if you can, or else send me what
you want it to say and I will do it.

On 01/25/2017 08:15 PM, Uwe Stöhr wrote:
> Hello Richard,
>
> could you please put this new installer version 4 to ftp.lyx.org?:
> http://ftp.lyx.de/LyX%202.2.2/
>
> MiKTeX had a bug that prevents LaTeX packages from being downloaded
> and installed. Therefore new users did not get a fully functional LyX.
> This is now fixed and therefore released a new installer version -
> that also fixes 2 installer bugs and updates all third party libraries
> for Windows.
>
> When it is at ftp.lyx.org I would announce it on lyx-users with an
> explanation.
>
> many thanks and regards
> Uwe

Re: Again: New Win installer for LyX 2.2.2 available

[Richard Heck]

DONE.

On 01/25/2017 08:15 PM, Uwe Stöhr wrote:
> Hello Richard,
>
> could you please put this new installer version 4 to ftp.lyx.org?:
> http://ftp.lyx.de/LyX%202.2.2/
>
> MiKTeX had a bug that prevents LaTeX packages from being downloaded
> and installed. Therefore new users did not get a fully functional LyX.
> This is now fixed and therefore released a new installer version -
> that also fixes 2 installer bugs and updates all third party libraries
> for Windows.
>
> When it is at ftp.lyx.org I would announce it on lyx-users with an
> explanation.
>
> many thanks and regards
> Uwe

Again: New Win installer for LyX 2.2.2 available

[Uwe Stöhr]

Hello Richard,

could you please put this new installer version 4 to ftp.lyx.org?:
http://ftp.lyx.de/LyX%202.2.2/

MiKTeX had a bug that prevents LaTeX packages from being downloaded and 
installed. Therefore new users did not get a fully functional LyX.
This is now fixed and therefore released a new installer version - that 
also fixes 2 installer bugs and updates all third party libraries for 
Windows.


When it is at ftp.lyx.org I would announce it on lyx-users with an
explanation.

many thanks and regards
Uwe

Re: [LyX/master] Collect the outliner names for the children's tocs

[Guillaume Munch]

Le 21/01/2017 à 04:23, Scott Kostyshak a écrit :

On Sat, Jan 14, 2017 at 11:16:29PM +0100, Guillaume Munch wrote:

commit 461fda9ca9a8079f235fe6d26031aa6b9c5ff36e
Author: Guillaume Munch 
Date:   Sat Jan 14 18:40:58 2017 +0100

Collect the outliner names for the children's tocs

Fixes missing outliner names in various situations. Now if the warning 
"Missing
outliner name" appears in the console, this correctly hints at an actual 
issue
with the layout.


I think this commit caused a change in behavior that I'm not sure was
intended.


Rather, it is the fault of 3391fed3




Can you reproduce?


Yes



I imagine you will have higher priority issues to look at when you come back
before this one, so no worries if you don't get to it for a while.



Indeed, not today. Thanks for your patience.

Re: row-breaking question

[Guillaume Munch]

Le 21/01/2017 à 20:22, Jean-Marc Lasgouttes a écrit :

Le 21/01/2017 à 19:33, Scott Kostyshak a écrit :

The attached sequence of screenshots show the phases of row-breaking
that happens as I keep typing " abc" in the footnote. The word "OLS"
seems to jump around a lot and I find that (mildly) annoying.

Are all six phases of the row breaking desired?


They are mostly not desired.
* 3 is clearly a bug
* 2 and 5 should be avoidable, but it requires to have some knowledge
that breaking before the inset is more desirable than in the middle of
the text. It might be doable. I have code somewhere to allow each inset
to declare whether it allows breaking before/after.



This is the sort of behaviour which is fixed (IIRC) by the improvement
to row breaking described in
.

Re: [CONFIRMED] Display Problem in Stable with \notin, etc.

[Guillaume Munch]

Le 19/01/2017 à 16:04, Jean-Marc Lasgouttes a écrit :


Here is what happened
1/ I change randomly (!) the spacing of math equations in the MathRow work
2/ as a consequence the formulas in lib/symbols are often wrong
3/ I fix the problem with arabic test at  e832d2e90f
4/ I do a new round of modifications of lib/symbols at  7335ee8e,
without realizing that what I am fixing is a consequence of the commit
3/ and not of the ongoing work 1/

Does this make sense to you? The fact that the right value now is
without explicit kern is a proof that all this work on math formula
spacing has been done correctly (almost!)


Makes sense to me. Lots of changes to spacing, and lib/symbols that lags
behind. A bug slips by the new features.

Nice that this odd kern is not needed after all. The value has been
found by trial-and-error. However may I suggest: what's good for display
is not necessarily the best for structural interaction—can we
reintroduce a kern to make it slightly imperfect, so that there is
feedback during selection (as you did in current master for \Arrownot)?

Another thing I would have mentioned is indeed that \{A,a}rrownot works
on the same principle, but I saw that you already took care of it.

(speaking about master, did not try stable)

Re: EmDash Problems (patch)

[Guillaume Munch]

Le 25/01/2017 à 22:51, Guenter Milde a écrit :

On 2017-01-25, Enrico Forestieri wrote:


The appearance on screen is the same but we always output "--" and
"---", except on text exports where the unicode characters are output.
This should ensure maximum compatibility without cluttering the
preamble with strange constructs. After all, what matters is the
final pdf output and I very much prefer to have "--" and "---" in
the latex code rather than \textendash and \textemdash.


...
I recommend the lib/unicodesymbols patch below as simple fix for the line
wrapping problem.

This would still not enable input of a line of hyphen characters in
"normal" text, though but maybe pressing CTRL-M (or CTRL-P C) *before*
the input is an acceptable workaround.

With an LFUN instead of the hard-coded binding to "-" for the input
convention, a user can turn off the auto-dash feature without need for
an new special setting. Then, also the input of - becomes
easy --- at the expense of more complicated input of the dashes.


+1 for the idea of a LFUN set up as a default. In addition it would be
nice if EM-dash + dash = 4 dashes... if only it was clear that EM-dash =
---.

A problem seems to be, in LyX 2.1 there was a use for both
\texte(n/m)dash and --(-) according to
https://marc.info/?l=lyx-users=140982011101908=2 because of the
different line breaking behaviour. By assigning U+2014 to --- it
regresses wrt 2.1 for ease of insertion of \textemdash (resp. endash) 
which was done by inserting —.


Also it seems that \textemdash + break point has advantages wrt ---, 
e.g. hyphenation 
https://tex.stackexchange.com/questions/56657/hyphenation-problem-with-versus-textemdash


So, a LFUN for - → – → — → ... is nice; one has to take seriously these 
line breaking issues (e.g. introduce blue dashes vs red dashes... this 
is getting complicated); and even with this distinction, --- is not 
without flaws...


No strong opinions. Looks like a difficult situation :)

Re: EmDash Problems (patch)

[Guenter Milde]

On 2017-01-25, Enrico Forestieri wrote:
> On Wed, Jan 25, 2017 at 09:51:33PM +, Guenter Milde wrote:

>> I recommend the lib/unicodesymbols patch below as simple fix for the line
>> wrapping problem.

> Does not work with xetex as lib/unicodesymbols seems to be ignored.

However, the line wrapping in xetex is OK for the literal Unicode character.

Günter

Re: EmDash Problems (patch)

[Enrico Forestieri]

On Wed, Jan 25, 2017 at 09:51:33PM +, Guenter Milde wrote:
> 
> I recommend the lib/unicodesymbols patch below as simple fix for the line
> wrapping problem.

Does not work with xetex as lib/unicodesymbols seems to be ignored.

-- 
Enrico

Re: EmDash Problems (patch)

[Guenter Milde]

On 2017-01-25, Enrico Forestieri wrote:

> I think the attached is all is needed here to please everyone.
> The appearance on screen is the same but we always output "--" and
> "---", except on text exports where the unicode characters are output.
> This should ensure maximum compatibility without cluttering the
> preamble with strange constructs. After all, what matters is the
> final pdf output and I very much prefer to have "--" and "---" in
> the latex code rather than \textendash and \textemdash.

The effect of this patch is the same as "forcing" the conversion to the
ligatures in lib/unicodesymbols (see below).

+2 traditional TeX constructs for em- and en-dash in the *.tex file
   * familiar look
   * no change to line breaking behaviour

+1 simple, no preamble code required

-1 hard to configure (a macro can be redefined, a font ligature not).

-0 inserting - stays as difficult as inserting 5 spaces in a row
   (needs a "literal" layout).

+1 index sorting problem solved (Ticket #10490)


with the differences

-1 additional code vs. 2 changed lines.
-2 hard-coded replacements:
* inconsistent handling of Unicode characters
  (Paragraph.cpp vs. lib/unicodesymbols)
* not configurable (not even by a power user).

I recommend the lib/unicodesymbols patch below as simple fix for the line
wrapping problem.

This would still not enable input of a line of hyphen characters in
"normal" text, though but maybe pressing CTRL-M (or CTRL-P C) *before*
the input is an acceptable workaround.

With an LFUN instead of the hard-coded binding to "-" for the input
convention, a user can turn off the auto-dash feature without need for
an new special setting. Then, also the input of - becomes
easy --- at the expense of more complicated input of the dashes.


Günter


--- a/lib/unicodesymbols
+++ b/lib/unicodesymbols
@@ -1737,8 +1737,8 @@
 0x2010 "-""" "force=utf8x,notermination=text" "" "" # 
HYPHEN # identic in LaTeX to FIGURE DASH
 0x2011 "\\nobreakdash-"   "amsmath" "notermination=text" "" "" # 
NON-BREAKING HYPHEN
 0x2012 "-""" "force=utf8x,notermination=text" "" "" # 
FIGURE DASH
-0x2013 "\\textendash" "" "" # EN DASH
-0x2014 "\\textemdash" "" "force=armscii8" # EM DASH
+0x2013 "--"   "" "force,notermination=text" # EN DASH
+0x2014 "---"  "" "force,notermination=text" # EM DASH
 # use the following macro for the character HORIZONTAL BAR
 0x2015 "\\LyXbar" "\\newcommand*\\LyXbar{\\rule[0.585ex]{1.2em}{0.25pt}}" 
"force"
 0x2016 "\\textbardbl" "textcomp" 
"force=utf8x,notermination=math,tipashortcut=\\textdoublevertline{}" "\\|" "" # 
DOUBLE VERTICAL LINE

Re: EmDash Problems (patch)

[Enrico Forestieri]

On Wed, Jan 25, 2017 at 08:50:21PM +, Guenter Milde wrote:
> On 2017-01-25, Enrico Forestieri wrote:
> 
> > [-- Type: text/plain, Encoding:  --]
> 
> > On Tue, Jan 24, 2017 at 09:11:12PM +0100, Enrico Forestieri wrote:
> >> On Tue, Jan 24, 2017 at 12:00:02PM +, Guenter Milde wrote:
> >> > On 2017-01-24, Enrico Forestieri wrote:
> >> > > On Mon, Jan 23, 2017 at 10:14:39PM +, Guenter Milde wrote:
> >> > 
> >> > >> Below is an incomplete patch (see FIXME).
> >> > >> Could someone with more C++ knowledge complete and test, please?
> >> > 
> >> > > This would be a step forward. However, I am more radical and would like
> >> > > that the automatic transformation of -- and --- to \textendash and
> >> > > \textemdash be removed. If I enter -- I want to get --, otherwise
> >> > > strange things and obscure bugs can happen. For example:
> >> > > 1) start a new document and input "--" and you get \textendash
> >> > > 2) now enter another "-" and you get \textemdash
> >> > > 3) now enter another "-" and everything gets replaced by "-"
> >> > 
> >> > This could be changed to gets replaced by ""
> ...
> > This seems to have been done on purpose. But I don't understand why.
> 
> The idea seems to be to cycle between hyphen, en-, and em-dash with
> subsequent keypresses. This makes sense under the assumption, that in normal
> text you will never need an em-dash followed by a hyphen, an en-dash, or
> another em-dash.

This does not make sense. In latex you can write how many dashes you want
and they count.

> > The attached patch corrects this glitch and I am going to commit it
> > because I really don't see any rationale behind this behavior.
> 
> With your patch, would pressing the [-]-Key 4 times become 
> EM DASH + HYPHEN or ?

   becomes EM DASH + HYPHEN
-  becomes EM DASH + EN DASH
-- becomes EM DASH + EM DASH

and so on. With the other patch I posted, these become again a series
of dashes on output. Perfect compatibility with earlier versions and
visually satisfactory for those who want to see em-dashes instead of
those horrible looking three dashes.

-- 
Enrico

Re: EmDash Problems (patch)

[Guenter Milde]

On 2017-01-25, Enrico Forestieri wrote:

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

> On Tue, Jan 24, 2017 at 09:11:12PM +0100, Enrico Forestieri wrote:
>> On Tue, Jan 24, 2017 at 12:00:02PM +, Guenter Milde wrote:
>> > On 2017-01-24, Enrico Forestieri wrote:
>> > > On Mon, Jan 23, 2017 at 10:14:39PM +, Guenter Milde wrote:
>> > 
>> > >> Below is an incomplete patch (see FIXME).
>> > >> Could someone with more C++ knowledge complete and test, please?
>> > 
>> > > This would be a step forward. However, I am more radical and would like
>> > > that the automatic transformation of -- and --- to \textendash and
>> > > \textemdash be removed. If I enter -- I want to get --, otherwise
>> > > strange things and obscure bugs can happen. For example:
>> > > 1) start a new document and input "--" and you get \textendash
>> > > 2) now enter another "-" and you get \textemdash
>> > > 3) now enter another "-" and everything gets replaced by "-"
>> > 
>> > This could be changed to gets replaced by ""
...
> This seems to have been done on purpose. But I don't understand why.

The idea seems to be to cycle between hyphen, en-, and em-dash with
subsequent keypresses. This makes sense under the assumption, that in normal
text you will never need an em-dash followed by a hyphen, an en-dash, or
another em-dash.

> The attached patch corrects this glitch and I am going to commit it
> because I really don't see any rationale behind this behavior.

With your patch, would pressing the [-]-Key 4 times become 
EM DASH + HYPHEN or ?

Günter

Re: EmDash Problems (patch)

[Enrico Forestieri]

On Wed, Jan 25, 2017 at 05:07:47PM +, Guenter Milde wrote:
> On 2017-01-24, Enrico Forestieri wrote:
> > On Tue, Jan 24, 2017 at 12:00:02PM +, Guenter Milde wrote:
> >> On 2017-01-24, Enrico Forestieri wrote:
> >> > On Mon, Jan 23, 2017 at 10:14:39PM +, Guenter Milde wrote:
> 
> >> > ... However, I am more radical and would like that the automatic
> >> > transformation of -- and --- to \textendash and \textemdash be
> >> > removed. If I enter -- I want to get --, otherwise strange things
> >> > and obscure bugs can happen.
> 
> However, with LaTeX font ligatures, similar strange things happen:

Nonetheless, always outputting -- and --- we avoid introducing bugs
such as http://www.lyx.org/trac/ticket/10490

-- 
Enrico

Re: EmDash Problems (patch)

[Enrico Forestieri]

On Tue, Jan 24, 2017 at 09:11:12PM +0100, Enrico Forestieri wrote:
> On Tue, Jan 24, 2017 at 12:00:02PM +, Guenter Milde wrote:
> > On 2017-01-24, Enrico Forestieri wrote:
> > > On Mon, Jan 23, 2017 at 10:14:39PM +, Guenter Milde wrote:
> > 
> > >> Below is an incomplete patch (see FIXME).
> > >> Could someone with more C++ knowledge complete and test, please?
> > 
> > > This would be a step forward. However, I am more radical and would like
> > > that the automatic transformation of -- and --- to \textendash and
> > > \textemdash be removed. If I enter -- I want to get --, otherwise
> > > strange things and obscure bugs can happen. For example:
> > > 1) start a new document and input "--" and you get \textendash
> > > 2) now enter another "-" and you get \textemdash
> > > 3) now enter another "-" and everything gets replaced by "-"
> > 
> > This could be changed to gets replaced by ""
> 
> I don't know how easily, didn't have a look at the sources.

This seems to have been done on purpose. But I don't understand why.
The attached patch corrects this glitch and I am going to commit it
because I really don't see any rationale behind this behavior.

-- 
Enrico
diff --git a/src/Text.cpp b/src/Text.cpp
index 8d08baa..77bface 100644
--- a/src/Text.cpp
+++ b/src/Text.cpp
@@ -1057,11 +1057,6 @@ void Text::insertChar(Cursor & cur, char_type c)
par.eraseChar(pos - 1, 
cur.buffer()->params().track_changes);
c = 0x2014;
pos--;
-   } else if (par.getChar(pos - 1) == 0x2014) {
-   // convert "" to "-"
-   par.eraseChar(pos - 1, 
cur.buffer()->params().track_changes);
-   c = '-';
-   pos--;
}
}
 

Re: EmDash Problems (patch)

[Enrico Forestieri]

On Wed, Jan 25, 2017 at 12:33:41PM -0500, Richard Heck wrote:
> On 01/25/2017 12:25 PM, Guenter Milde wrote:
> > On 2017-01-24, Richard Heck wrote:
> >> On 01/24/2017 05:50 PM, Enrico Forestieri wrote:
> >>> On Tue, Jan 24, 2017 at 11:31:11PM +0100, Jean-Marc Lasgouttes wrote:
>  Le 24/01/2017 à 23:07, Enrico Forestieri a écrit :
> > The first two that come to mind are xypic and tikz. As regards xypic,
> > in lyx 2.1 you could write a code fragment, select it and then hit
> > Ctrl-M to have it nicely previewed. Now no more.
>  You mean that hitting Ctrl-M before writing the code fragment does not 
>  work?
> >>>
> >> I agree with Enrico that we should revert to the previous behavior.
> > However, the previous behavior was changed for a reason (inconsistency 
> > between LyX GUI and generated output due to the TeX ligatures). I don't 
> > want this back.
> 
> Yes, but when it was changed, I and others raised exactly these sorts of
> concerns---I specifically raised concerns about line-breaking---and we
> were told it wouldn't be a problem. It turns out it is a problem. To be
> more precise, the conversion from 2.1 to 2.2 breaks some documents
> (i.e., they do not give the same output). Some of mine, in particular,
> from which I took the original example.
> 
> If the issue is with the display---personally, I don't see the issue,
> but if others do---then let's fix the display. There are all kinds of
> things that can be done here, e.g., with InsetSpecialChar without
> messing up the output.
> 
> I take one of LyX's core principles to be: Don't try to outsmart the
> user. That's being violated here.

I think the attached is all is needed here to please everyone.
The appearance on screen is the same but we always output "--" and
"---", except on text exports where the unicode characters are output.
This should ensure maximum compatibility without cluttering the
preamble with strange constructs. After all, what matters is the
final pdf output and I very much prefer to have "--" and "---" in
the latex code rather than \textendash and \textemdash.

-- 
Enrico
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index c1aa2b9..bad4214 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1222,6 +1222,16 @@ void Paragraph::Private::latexSpecialChar(otexstream & 
os,
column += 2;
}
break;
+   case 0x2013:
+   // en-dash
+   os << "--";
+   column +=2;
+   break;
+   case 0x2014:
+   // em-dash
+   os << "---";
+   column +=3;
+   break;
case '\"':
os << "\\char`\\\"" << termcmd;
column += 9;

Re: EmDash Problems (patch)

[Richard Heck]

On 01/25/2017 12:25 PM, Guenter Milde wrote:
> On 2017-01-24, Richard Heck wrote:
>> On 01/24/2017 05:50 PM, Enrico Forestieri wrote:
>>> On Tue, Jan 24, 2017 at 11:31:11PM +0100, Jean-Marc Lasgouttes wrote:
 Le 24/01/2017 à 23:07, Enrico Forestieri a écrit :
> The first two that come to mind are xypic and tikz. As regards xypic,
> in lyx 2.1 you could write a code fragment, select it and then hit
> Ctrl-M to have it nicely previewed. Now no more.
 You mean that hitting Ctrl-M before writing the code fragment does not 
 work?
>>>
>> I agree with Enrico that we should revert to the previous behavior.
> However, the previous behavior was changed for a reason (inconsistency 
> between LyX GUI and generated output due to the TeX ligatures). I don't want 
> this back.

Yes, but when it was changed, I and others raised exactly these sorts of
concerns---I specifically raised concerns about line-breaking---and we
were told it wouldn't be a problem. It turns out it is a problem. To be
more precise, the conversion from 2.1 to 2.2 breaks some documents
(i.e., they do not give the same output). Some of mine, in particular,
from which I took the original example.

If the issue is with the display---personally, I don't see the issue,
but if others do---then let's fix the display. There are all kinds of
things that can be done here, e.g., with InsetSpecialChar without
messing up the output.

I take one of LyX's core principles to be: Don't try to outsmart the
user. That's being violated here.

Richard

>
> For "standard" LaTeX text, -- and --- are a special constructs just like
> <<, >>, ``, '', \, $, ^, or _. All of them are "escaped" by LyX's LaTeX
> output, so why not -- and ---?
>
> For direct input of them into the source, we need wrapping (ERT, mathed,
> LyX-Code, "font teletype", listings).
>
>
>> What we could also do, though, is provide SOME easy way (a shortcut?)
>> for people to insert \textemdash, if that is what they want to do.
>> Alternatively (yes, I know it is a terrible idea), we could have a
>> preference for this.
> My preference would be an LFUN "auto-dash", that converts
>  * a preceding - into an en-dash
>  * a preceding en-dash into an em-dash 
> if not inside LyX-code, ERT, mathed, listings, index, label, or "font
> teletype". 
>
> This should then be bound to "-" by default (similar to the "-key for
> quote-insert).
>
>
> In addition, we need fixes for "overcompensating": no need for -{}- in LyX
> code and if the font family is teletype.
>
> Günter
>

Re: EmDash Problems (patch)

[Guenter Milde]

On 2017-01-24, Richard Heck wrote:
> On 01/24/2017 05:50 PM, Enrico Forestieri wrote:
>> On Tue, Jan 24, 2017 at 11:31:11PM +0100, Jean-Marc Lasgouttes wrote:
>>> Le 24/01/2017 à 23:07, Enrico Forestieri a écrit :
 The first two that come to mind are xypic and tikz. As regards xypic,
 in lyx 2.1 you could write a code fragment, select it and then hit
 Ctrl-M to have it nicely previewed. Now no more.
>>> You mean that hitting Ctrl-M before writing the code fragment does not work?
>> I mean that what was working now does not anymore.

Of course, changed behaviour can have side-effects or affect a workflow
relying on some now removed side-effect.

> I agree with Enrico that we should revert to the previous behavior.

However, the previous behavior was changed for a reason (inconsistency
between LyX GUI and generated output due to the TeX ligatures).
I don't want this back.

For "standard" LaTeX text, -- and --- are a special constructs just like
<<, >>, ``, '', \, $, ^, or _. All of them are "escaped" by LyX's LaTeX
output, so why not -- and ---?

For direct input of them into the source, we need wrapping (ERT, mathed,
LyX-Code, "font teletype", listings).


> What we could also do, though, is provide SOME easy way (a shortcut?)
> for people to insert \textemdash, if that is what they want to do.
> Alternatively (yes, I know it is a terrible idea), we could have a
> preference for this.

My preference would be an LFUN "auto-dash", that converts
 * a preceding - into an en-dash
 * a preceding en-dash into an em-dash 
if not inside LyX-code, ERT, mathed, listings, index, label, or "font
teletype". 

This should then be bound to "-" by default (similar to the "-key for
quote-insert).


In addition, we need fixes for "overcompensating": no need for -{}- in LyX
code and if the font family is teletype.

Günter

Re: EmDash Problems (patch)

[Guenter Milde]

On 2017-01-24, Enrico Forestieri wrote:
> On Tue, Jan 24, 2017 at 12:00:02PM +, Guenter Milde wrote:
>> On 2017-01-24, Enrico Forestieri wrote:
>> > On Mon, Jan 23, 2017 at 10:14:39PM +, Guenter Milde wrote:

>> > ... However, I am more radical and would like that the automatic
>> > transformation of -- and --- to \textendash and \textemdash be
>> > removed. If I enter -- I want to get --, otherwise strange things
>> > and obscure bugs can happen.

However, with LaTeX font ligatures, similar strange things happen:

>> For example:
>> > 1) start a new document and input "--" and you get \textendash

In LaTeX and LyX 2.1, you get an EN DASH in the output.

>> > 2) now enter another "-" and you get \textemdash

In LaTeX and LyX 2.1, you get an EM DASH in the output.

>> > 3) now enter another "-" and everything gets replaced by "-"

In LaTeX and LyX 2.1, you get an EM DASH followed by - in the output.


>> > This means that I am not able to enter "-", for example.

>> At least not easily. (It works if you insert with spaces and delete them
>> later.)

> Not at all. You get -{}-{}-{}-{}-{}-{}-{}-{}- which is worse.

This is to ensure you get --- in the output (for normal
text fonts).

> You have to use ERT to introduce four hyphens? How's that?

There are alternatives: LyX-Code, set the font to \texttt, mathed

>> OTOH, with the old behaviour strange things happen on export:

>> 1) start a new document and insert this---foo
>> 2) copy from another source bar—bar (with Unicode emdash literal)

Sorry, I did not check. The following statement has to be corrected:

- In LyX <2.2, both emdashes look completely identical, but one allows
- line breaks after the dash and the other not!

+ In LyX <2.2, the GUI shows "--", but the output contains an en-dash,
+ the GUI shows "---" but the output has and em-dash!

This is in contrast to, e.g. handling of >>: in the LaTeX output the > are
separated to prevent ligating to ».


> But packages that expect to see two hyphens instead of \textendash
> are not broken...

They are not broken but they are also not intended to be fed with "standard"
text.

Günter

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 24/01/2017 ? 10:25, Pavel Sanda a écrit :
>> which has to obviously fail because we deleted tests/.deps already.
>>
>> JMarc, do you have idea about the fix?
>
> I suspect this is related to our SUBDIRS variable
>
> SUBDIRS = support frontends . $(CLIENT) tex2lyx

My guess is that the solution might be separate makefile for test subdir.

> I am not sure why . is added explicitly here. What happens if we remove it?

bilions of
...
make[3]: Entering directory '/home/paf/lyx/devel/lyx-2.3.0dev/_build/sub/src'
.deps/AppleSpellChecker.Po: No such file or directory
...
Makefile:2455: support/tests/.deps/check_layout-dummy_functions.Po: No such 
file or directory
make[3]: *** No rule to make target 
'support/tests/.deps/check_layout-dummy_functions.Po'.  Stop.
make[3]: Leaving directory '/home/paf/lyx/devel/lyx-2.3.0dev/_build/sub/src'
Makefile:2908: recipe for target 'distclean-recursive' failed
...

Pavel

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Pavel Sanda]

Christian Ridderström wrote:
> Using automake (GNU automake) 1.14.1
> 
> Using autoconf (GNU Autoconf) 2.69
> 
> but it still fails at the same place.
> 
> Do you know a version of automake for which it works?

automake (GNU automake) 1.11.3
autoconf (GNU Autoconf) 2.68

P