Re: EmDash Problems (patch)
On 2017-01-29, Georg Baum wrote: > Guenter Milde wrote: >> ... There may be issues with documents containing literal Unicode >> dashes: these may now have different line breaks. > If this is an issue then it was already an issue when format 481 was > introduced (because we changed -- to U+2013 and --- to U+2014 in the > conversion). Unfortunatly, yes. It turns out the correct change would have been to change -- to U+2013,U+200B and --- to U+2014,U+200B (or to SpecialChars). Why? * --- is converted to EM DASH by TeX via font ligature. * TeX insert a line breaking opportunity (LBO) after each HYPHEN (-) and suppresses hyphenation in the preceding word, also if three HYPHENs become an EM DASH by ligating. * TeX does *not* insert an LBO afte a literal EM DASH or \textemdash macro while the Unicode standard recommends LBOs before and after EM DASH. Exception: XeTeX treats literal dashes and \textemdash macro like the ligatures - no hypenation in the word before, LBO after. This behaviour can be switched of by the preamble command * Unicode and LyX/LaTeX recommend/support the Zero Width Space U+200B (ZWSP) as representation of a line break opportunity that does not insert a hyphen (in contrast to the SOFT HYPHEN). As a result, the TeX input string "---" is functionally equivalent to EM DASH + ZWSP (except for missing hyphenation of the preceding word with "---"). For more "research", background and links, see http://www.lyx.org/trac/ticket/10543 > If native support for both versions of dashes (-- vs. \textendash in LaTeX) > is really needed then this should be done via a special char inset. The SpecialChar inset(s) could either be a) insets for "ligature dashes" -- and --- +1 full backwards compatibility with fileformat <481 b) inset for zero width space ZWSP +2 versatile: currently there is no LyX support for a line breaking opportunity that does not insert a hyphen (except for a literal ZWSP that is invisible in the GUI) +1 can be implemented as space inset instance +0 backwards compatible with fileformat <481 when replacing --- by EM DASH + SpecialChar(ZWSP) (Except for not suppressing hyphenation in the preceding word, but it may be argued that this is actually an improvement) >> It is not about "horrible look", but about WYSIWYM: >> Treat hyphens similar to other TeX ligatures (e.g. << and >>) and special >> characters: >> * show on screen what you will get in the output >> * escape in LaTeX export. >> If the LyX GUI shows "get the LyX version with `lyx --version`", I don't >> want a suprise `lyx –version` in the output. > This is the most important point IMO (and the very reason to introduce > format 481 which fixed https://www.lyx.org/trac/ticket/3647). Yes. > I have no strong opinion about the UI for entering en-dashes and em-dashes. > If there are better methods than the current one then the UI should change. I favour an LFUN for input. This can be bound to the - key by default. It could be extended to allow an optional argument "allowbreak" that would add (and care for) ZWSP after the DASHES. Günter
Re: EmDash Problems (patch)
On 2017-02-28, Enrico Forestieri wrote: > On Mon, Feb 27, 2017 at 10:39:25PM +, Guenter Milde wrote: >> On 2017-02-27, Enrico Forestieri wrote: >> >> > At this point we have two simple alternatives. Either the above one or >> >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198615.html >> >> Both have serious drawbacks. See #10543. >> > TL;DR >> Sorry, but forcing a simple but insufficient patch to a complex problem >> because the description is too long is not the right thing. > You make it complex. We output latex and thus should follow latex rules. ... > Since ever LyX was outputting -- and --- and nobody was complaining > (I am not speaking about text or html output, which are different). >From the lyx-users list 2014: >https://marc.info/?l=lyx-users=140982011101908=2 In LaTeX, and therefore also in LyX, there are two types of en dash (and also two types of em dash). In LaTeX the first is entered by -- and the second is entered with \textendash. In LyX the first is entered with -- and the second is entered by putting the unicode en dash in (in my reply to Rich I listed three ways to do this, and Jerry's Mac technique is doing the same thing). It's not quite clear to me which is the "correct" way to do this. -- is older, and \textendash was introduced so that it can work with more fonts (or something like that). But as Jerry has noticed, they also have different line breaking properties. It sounds like the ability of -- to create a line break was just a side effect of its implementation rather than intended. Maybe it was suppressed from \textendash because it's so easy to turn back on when needed. Unfortunately, during the 2.1->2.2 change the differences between the two representations were not taken into consideration. As a result, there is now only one representation in the LyX source files. > Now LyX outputs \textendash and \textemdash and this is causing problems. > What is the conclusion? Outputting -- and --- would solve some problems and create new ones: A literal EM DASH allows hyphenation in the word before the dash Three alkali metals are the usual sub- stituents—sodium, potassium, and lithium. while the ligature prevents hyphenation in the word before the dash: Three alkali metals are the usual substituents— sodium, potassium, and lithium. See also https://www.lyx.org/trac/raw-attachment/ticket/10543/dash-problems.lyx https://www.lyx.org/trac/raw-attachment/ticket/10543/dash-problems-non-tex-fonts.lyx You get the same problem -- overfull lines -- with both approaches. So while curing some documents you break others. OtOH, with EM DASH + ZWSP, hyphenation in the preceding word is allowed as are line breaks after the dash. Günter
Re: EmDash Problems (patch)
On Mon, Feb 27, 2017 at 10:39:25PM +, Guenter Milde wrote: > On 2017-02-27, Enrico Forestieri wrote: > > On Mon, Feb 27, 2017 at 09:18:50PM +, Guenter Milde wrote: > >> On 2017-02-27, Enrico Forestieri wrote: > > >> >> >> Then, a decision has to still be taken as regards the original > >> >> >> problem > >> >> >> in this thread. I think that the patch Günther proposed on Jan. 25 is > >> >> >> the less controversial one. > > >> >> > I think you mean > >> >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html > > >> >> However, this patch is obsolete. As Guillaume pointed out, there are use > >> >> cases for the dashes with and without line break opportunity. (See also > >> >> the attachments to https://www.lyx.org/trac/ticket/10543) > > >> > A patch that does not exist cannot obsolete anything ;) > > >> But it can be obsolete. Obsoleted by new findings during testing and > >> discussion of the problem. > > > This is a sophism. > > Can you explain this, please? https://www.merriam-webster.com/dictionary/sophism > >> > At this point we have two simple alternatives. Either the above one or > >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198615.html > > >> Both have serious drawbacks. See #10543. > > > TL;DR > > Sorry, but forcing a simple but insufficient patch to a complex problem > because the description is too long is not the right thing. You make it complex. We output latex and thus should follow latex rules. Since ever LyX was outputting -- and --- and nobody was complaining (I am not speaking about text or html output, which are different). Now LyX outputs \textendash and \textemdash and this is causing problems. What is the conclusion? -- Enrico
Re: EmDash Problems (patch)
On 2017-02-27, Enrico Forestieri wrote: > On Mon, Feb 27, 2017 at 09:18:50PM +, Guenter Milde wrote: >> On 2017-02-27, Enrico Forestieri wrote: >> >> >> Then, a decision has to still be taken as regards the original problem >> >> >> in this thread. I think that the patch Günther proposed on Jan. 25 is >> >> >> the less controversial one. >> >> > I think you mean >> >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html >> >> However, this patch is obsolete. As Guillaume pointed out, there are use >> >> cases for the dashes with and without line break opportunity. (See also >> >> the attachments to https://www.lyx.org/trac/ticket/10543) >> > A patch that does not exist cannot obsolete anything ;) >> But it can be obsolete. Obsoleted by new findings during testing and >> discussion of the problem. > This is a sophism. Can you explain this, please? >> > At this point we have two simple alternatives. Either the above one or >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198615.html >> Both have serious drawbacks. See #10543. > TL;DR Sorry, but forcing a simple but insufficient patch to a complex problem because the description is too long is not the right thing. Then, have at least a look at the exemples attached to #10543. >> > Then, I refuse to have a mess in the latex output only to obtain a simple >> > en(em)-dash when LaTeX already uses -- and --- for those dashes. >> LaTeX supports — for the em-dash (with inputenc utf8), so why don't use >> it? >> Using font ligatures as an input convention is seventies technology, >> obsoleted by LaTeX2e 20 years ago. > Another sophism. >> LyX supports — for the em-dash since 2007. >> I refuse a change where I need to put \textemdash in ERT to get rid of >> the drawbacks of the font ligatures. >> (The suggestion in msg198615 would convert all literal em-dashes into >> "---" without any way to bypass this conversion. This breaks documents >> that use direct Unicode char input.) > Then let's apply > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html This patch still misses the distinction between "dash with line break opportunity" and "dash without line break opportunity" that was possible in 2.1 documents but not in 2.2. Also, as you pointed out there would be different line-break behaviour in LuaTeX. There is no simple solution. An "auto-dash" LFUN could care for different preferences. Günter
Re: EmDash Problems (patch)
On Mon, Feb 27, 2017 at 09:18:50PM +, Guenter Milde wrote: > On 2017-02-27, Enrico Forestieri wrote: > > On Mon, Feb 27, 2017 at 04:55:43PM +, Guenter Milde wrote: > >> On 2017-02-26, Guillaume Munch wrote: > >> > Le 25/02/2017 à 21:09, Enrico Forestieri a écrit : > > >> >> Then, a decision has to still be taken as regards the original problem > >> >> in this thread. I think that the patch Günther proposed on Jan. 25 is > >> >> the less controversial one. > > >> > I think you mean > >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html > > >> However, this patch is obsolete. As Guillaume pointed out, there are use > >> cases for the dashes with and without line break opportunity. (See also > >> the attachments to https://www.lyx.org/trac/ticket/10543) > > > A patch that does not exist cannot obsolete anything ;) > > But it can be obsolete. Obsoleted by new findings during testing and > discussion of the problem. This is a sophism. > > At this point we have two simple alternatives. Either the above one or > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198615.html > > Both have serious drawbacks. See #10543. TL;DR > > Then, I refuse to have a mess in the latex output only to obtain a simple > > en(em)-dash when LaTeX already uses -- and --- for those dashes. > > LaTeX supports — for the em-dash (with inputenc utf8), so why don't use > it? > > Using font ligatures as an input convention is seventies technology, > obsoleted by LaTeX2e 20 years ago. Another sophism. > LyX supports — for the em-dash since 2007. > I refuse a change where I need to put \textemdash in ERT to get rid of > the drawbacks of the font ligatures. > (The suggestion in msg198615 would convert all literal em-dashes into > "---" without any way to bypass this conversion. This breaks documents > that use direct Unicode char input.) Then let's apply https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html -- Enrico
Re: EmDash Problems (patch)
On 2017-02-27, Enrico Forestieri wrote: > On Mon, Feb 27, 2017 at 04:55:43PM +, Guenter Milde wrote: >> On 2017-02-26, Guillaume Munch wrote: >> > Le 25/02/2017 à 21:09, Enrico Forestieri a écrit : >> >> Then, a decision has to still be taken as regards the original problem >> >> in this thread. I think that the patch Günther proposed on Jan. 25 is >> >> the less controversial one. >> > I think you mean >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html >> However, this patch is obsolete. As Guillaume pointed out, there are use >> cases for the dashes with and without line break opportunity. (See also >> the attachments to https://www.lyx.org/trac/ticket/10543) > A patch that does not exist cannot obsolete anything ;) But it can be obsolete. Obsoleted by new findings during testing and discussion of the problem. > At this point we have two simple alternatives. Either the above one or > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198615.html Both have serious drawbacks. See #10543. > Then, I refuse to have a mess in the latex output only to obtain a simple > en(em)-dash when LaTeX already uses -- and --- for those dashes. LaTeX supports — for the em-dash (with inputenc utf8), so why don't use it? Using font ligatures as an input convention is seventies technology, obsoleted by LaTeX2e 20 years ago. LyX supports — for the em-dash since 2007. I refuse a change where I need to put \textemdash in ERT to get rid of the drawbacks of the font ligatures. (The suggestion in msg198615 would convert all literal em-dashes into "---" without any way to bypass this conversion. This breaks documents that use direct Unicode char input.) There is no simple solution that covers all use cases. Günter
Re: EmDash Problems (patch)
On Mon, Feb 27, 2017 at 04:55:43PM +, Guenter Milde wrote: > On 2017-02-26, Guillaume Munch wrote: > > Le 25/02/2017 à 21:09, Enrico Forestieri a écrit : > > >> Then, a decision has to still be taken as regards the original problem > >> in this thread. I think that the patch Günther proposed on Jan. 25 is > >> the less controversial one. > > > I think you mean > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html > > However, this patch is obsolete. As Guillaume pointed out, there are use > cases for the dashes with and without line break opportunity. (See also > the attachments to https://www.lyx.org/trac/ticket/10543) A patch that does not exist cannot obsolete anything ;) At this point we have two simple alternatives. Either the above one or https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198615.html Then, I refuse to have a mess in the latex output only to obtain a simple en(em)-dash when LaTeX already uses -- and --- for those dashes. -- Enrico
Re: EmDash Problems (patch)
On 2017-02-26, Guillaume Munch wrote:
> Le 25/02/2017 à 21:09, Enrico Forestieri a écrit :
>> Then, a decision has to still be taken as regards the original problem
>> in this thread. I think that the patch Günther proposed on Jan. 25 is
>> the less controversial one.
> I think you mean
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html
However, this patch is obsolete. As Guillaume pointed out, there are use
cases for the dashes with and without line break opportunity. (See also
the attachments to https://www.lyx.org/trac/ticket/10543)
As inserting a breaking opportunity is far more easy than ovoiding a line
break and there are use cases for both, I prefer \textemdash over ---.
lyx2lyx could be fixed to convert --- to \textemdash\allowbreak{}
Unfortunately, this will not cure documents broken by the conversion to
2.2-format. However, there is no easy cure as with the EM-DASH in the
converted source, we cannot tell whether this was a literal EM-DASH
before or a ---.
> The idea of introducing a LFUN so that the behaviour of the - key is not
> hard-coded sounds good as well.
Volunteers?
Günter
Re: EmDash Problems (patch)
Le 25/02/2017 à 21:09, Enrico Forestieri a écrit : Then, a decision has to still be taken as regards the original problem in this thread. I think that the patch Günther proposed on Jan. 25 is the less controversial one. I think you mean https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198620.html From someone who does not have strong opinions about the dashes issues this looks good to me. The idea of introducing a LFUN so that the behaviour of the - key is not hard-coded sounds good as well. Guillaume
Re: EmDash Problems (patch)
On 02/25/2017 03:16 PM, Guillaume Munch wrote:
>
>>
>> ../../../../src/frontends/qt4/GuiViewSource.cpp: In member function
>> ‘void lyx::frontend::ViewSourceWidget::realUpdateView()’:
>> ../../../../src/frontends/qt4/GuiViewSource.cpp:229:14: error:
>> ambiguous overload for ‘operator!=’ (operand types are ‘const QChar’
>> and ‘char’)
>>while (*oc != '\0' && *nc != '\0' && *oc == *nc) {
>> ^
>
> I can backport 6d375dde to fix this.
Go ahead.
rh
Re: EmDash Problems (patch)
../../../../src/frontends/qt4/GuiViewSource.cpp: In member function ‘void
lyx::frontend::ViewSourceWidget::realUpdateView()’:
../../../../src/frontends/qt4/GuiViewSource.cpp:229:14: error: ambiguous
overload for ‘operator!=’ (operand types are ‘const QChar’ and ‘char’)
while (*oc != '\0' && *nc != '\0' && *oc == *nc) {
^
I can backport 6d375dde to fix this.
Re: EmDash Problems (patch)
On Sat, Feb 25, 2017 at 12:37:18PM -0500, Richard Heck wrote:
> On 02/25/2017 08:22 AM, Enrico Forestieri wrote:
> > On Thu, Jan 26, 2017 at 11:11:32AM +, Guenter Milde wrote:
> >> On 2017-01-25, Enrico Forestieri wrote:
> >>> On Wed, Jan 25, 2017 at 08:50:21PM +, Guenter Milde wrote:
> On 2017-01-25, Enrico Forestieri wrote:
> > 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:
> >> ...
> >>
> 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 "-"
> >> ...
> > 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.
> >> So this is reproducing the behaviour you get with LaTeX ligatures.
> >>
> >> +1 for this patch.
> > I committed it at 3c329db0.
> >
> > Richard, this is also needed in stable.
>
> OK.
Done at 857548d3.
Note that I need the attached patch to be able to compile stable with
Qt 5.8, otherwise I get the following error:
../../../../src/frontends/qt4/GuiViewSource.cpp: In member function ‘void
lyx::frontend::ViewSourceWidget::realUpdateView()’:
../../../../src/frontends/qt4/GuiViewSource.cpp:229:14: error: ambiguous
overload for ‘operator!=’ (operand types are ‘const QChar’ and ‘char’)
while (*oc != '\0' && *nc != '\0' && *oc == *nc) {
^
Then, a decision has to still be taken as regards the original problem
in this thread. I think that the patch Günther proposed on Jan. 25 is
the less controversial one.
--
Enrico
diff --git a/src/frontends/qt4/GuiViewSource.cpp
b/src/frontends/qt4/GuiViewSource.cpp
index 660da59..a4f67ed 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -226,7 +226,7 @@ void ViewSourceWidget::realUpdateView()
const QChar * oc = old.constData();
const QChar * nc = qcontent.constData();
int pos = 0;
- while (*oc != '\0' && *nc != '\0' && *oc == *nc) {
+ while (*oc != 0 && *nc != 0 && *oc == *nc) {
++oc;
++nc;
++pos;
Re: EmDash Problems (patch)
On 02/25/2017 08:22 AM, Enrico Forestieri wrote: > On Thu, Jan 26, 2017 at 11:11:32AM +, Guenter Milde wrote: >> On 2017-01-25, Enrico Forestieri wrote: >>> On Wed, Jan 25, 2017 at 08:50:21PM +, Guenter Milde wrote: On 2017-01-25, Enrico Forestieri wrote: > 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: >> ... >> 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 "-" >> ... > 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. >> So this is reproducing the behaviour you get with LaTeX ligatures. >> >> +1 for this patch. > I committed it at 3c329db0. > > Richard, this is also needed in stable. OK. rh
Re: EmDash Problems (patch)
On Thu, Jan 26, 2017 at 11:11:32AM +, Guenter Milde wrote: > On 2017-01-25, Enrico Forestieri wrote: > > On Wed, Jan 25, 2017 at 08:50:21PM +, Guenter Milde wrote: > >> On 2017-01-25, Enrico Forestieri wrote: > >> > 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: > > ... > > >> >> > > 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 "-" > ... > >> > 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. > > So this is reproducing the behaviour you get with LaTeX ligatures. > > +1 for this patch. I committed it at 3c329db0. Richard, this is also needed in stable. -- Enrico
Re: EmDash Problems (patch)
Guenter Milde wrote: > Not "perfect" (but maybe "satisfactory"): There may be issues with > documents containing literal Unicode dashes: these may now have different > line breaks. If this is an issue then it was already an issue when format 481 was introduced (because we changed -- to U+2013 and --- to U+2014 in the conversion). Does the unicode standard really say something about linebreaking, or does this rather come from the fact that we currently map U+2013 to \textendash and U+2014 to \textemdash? If native support for both versions of dashes (-- vs. \textendash in LaTeX) is really needed then this should be done via a special char inset. > It is not about "horrible look", but about WYSIWYM: > > Treat hyphens similar to other TeX ligatures (e.g. << and >>) and special > characters: > > * show on screen what you will get in the output > > * escape in LaTeX export. > > If the LyX GUI shows "get the LyX version with `lyx --version`", I don't > want a suprise `lyx –version` in the output. This is the most important point IMO (and the very reason to introduce format 481 which fixed https://www.lyx.org/trac/ticket/3647). I have no strong opinion about the UI for entering en-dashes and em-dashes. If there are better methods than the current one then the UI should change. Georg
Re: EmDash Problems (patch)
Enrico Forestieri wrote: > 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. This is part of the code that tried to make the input of en-dashes and em- dashes after format change 481 as easy as before. The idea (which was also discussed on the list IIRC) was to make the hyphen key toggle between hyphen, en-dash and em-dash (similar to spaces in mathed). If that behaviour is too confusing then the code should be removed or course. Georg
Re: EmDash Problems (patch)
Jean-Marc Lasgouttes wrote: > Le 24/01/2017 à 23:57, Richard Heck a écrit : >> I agree with Enrico that we should revert to the previous behavior. 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. > > It would be nice to have Georg's input on that, though. > > JMarc Thanks to Scott who made me aware of this thread. Lets see whether this message (2nd try) comes through, if yes I'll comment on some other messages as well. Georg
Re: EmDash Problems (patch)
Jean-Marc Lasgouttes wrote: > Le 24/01/2017 à 23:57, Richard Heck a écrit : >> I agree with Enrico that we should revert to the previous behavior. 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. > > It would be nice to have Georg's input on that, though. Thanks to Scott who made me aware of this thread. I am unfortunately not able currently to read the list regularly, however I'll follow this thread, so no need to CC me. I'll comment on other messages in a minute. Georg
Re: EmDash Problems (patch)
On 2017-01-25, Enrico Forestieri wrote: > On Wed, Jan 25, 2017 at 08:50:21PM +, Guenter Milde wrote: >> On 2017-01-25, Enrico Forestieri wrote: >> > 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: ... >> >> > > 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 "-" ... >> > 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. So this is reproducing the behaviour you get with LaTeX ligatures. +1 for this patch. === > With the other patch I posted, these become again a series > of dashes on output. In the LaTeX source, yes. In PDF output, it will be the same characters as in the LyX file. > Perfect compatibility with earlier versions Not "perfect" (but maybe "satisfactory"): There may be issues with documents containing literal Unicode dashes: these may now have different line breaks. The problem is that not even power users have a way to bypass the forced conversion of EM/EN DASH characters to hyphens on LaTeX export. > and visually satisfactory for those who want to see em-dashes instead > of those horrible looking three dashes. It is not about "horrible look", but about WYSIWYM: Treat hyphens similar to other TeX ligatures (e.g. << and >>) and special characters: * show on screen what you will get in the output * escape in LaTeX export. If the LyX GUI shows "get the LyX version with `lyx --version`", I don't want a suprise `lyx –version` in the output. Günter
Re: EmDash Problems (patch)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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: EmDash Problems (patch)
Le 24/01/2017 à 23:57, Richard Heck a écrit : I agree with Enrico that we should revert to the previous behavior. 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. It would be nice to have Georg's input on that, though. JMarc
Re: EmDash Problems (patch)
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. I agree with Enrico that we should revert to the previous behavior. 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. Richard
Re: EmDash Problems (patch)
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. -- Enrico
Re: EmDash Problems (patch)
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? JMarc
Re: EmDash Problems (patch)
Enrico Forestieri wrote: > 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. :(
Re: EmDash Problems (patch)
On Tue, Jan 24, 2017 at 09:35:27PM +0100, Jean-Marc Lasgouttes wrote: > Le 24/01/2017 à 21:11, Enrico Forestieri a écrit : > > But packages that expect to see two hyphens instead of \textendash > > are not broken... > > Out of curiosity: what packages are these? 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. Then, there can also be other side effects. See for example http://www.lyx.org/trac/ticket/10490 -- Enrico
Re: EmDash Problems (patch)
Le 24/01/2017 à 21:11, Enrico Forestieri a écrit : But packages that expect to see two hyphens instead of \textendash are not broken... Out of curiosity: what packages are these? JMarc
Re: EmDash Problems (patch)
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 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.
You have to use ERT to introduce four hyphens? How's that?
> 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)
>
> In LyX <2.2, both emdashes look completely identical, but one allows
> line breaks after the dash and the other not!
But packages that expect to see two hyphens instead of \textendash
are not broken...
--
Enrico
Re: EmDash Problems (patch)
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 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.) 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) In LyX <2.2, both emdashes look completely identical, but one allows line breaks after the dash and the other not! Günter
Re: EmDash Problems (patch)
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 means that I am not able to enter "-", for example. -- Enrico
Re: EmDash Problems (patch)
On 2017-01-17, Guenter Milde wrote:
> On 2017-01-17, Enrico Forestieri wrote:
>> On Tue, Jan 17, 2017 at 06:05:57PM +0100, Enrico Forestieri wrote:
>>> On Tue, Jan 17, 2017 at 09:41:03AM -0500, Richard Heck wrote:
>>> > On 01/17/2017 02:55 AM, Jürgen Spitzmüller wrote:
>>> > > Am Montag, den 16.01.2017, 22:17 + schrieb Guenter Milde:
>>> > >> Now we have 3 specs:
>>> > >>
>>> > >> 1. Unicode: Break Opportunity Before and After
>>> > >>
>>> > >> 2. --- ligature: Break opportunity after, no hyphenation of word
>>> > >> before
>>> > >>(also with literal EM DASH and \textemdash macro with non-TeX
>>> > >> fonts).
>>> > >>
>>> > >> 3. \textemdash macro (and literal EM DASH with inputenc-utf8) and TeX
>>> > >> fonts:
>>> > >>no break opportunity. Hyphenation of word before allowed.
>>> > >>
>>> > >> What should be the LyX behaviour?
>>> > > 2.
>>> >
>>> > I agree with Jürgen, mostly because this is the old and expected
>>> > behavior.
>>> That's also my opinion.
>> Meaning that we should output "---".
Below is an incomplete patch (see FIXME).
Could someone with more C++ knowledge complete and test, please?
Günter
Exec: git 'diff' 'LaTeXFeatures.cpp' 2>&1
Dir: /usr/local/src/lyx/src/
diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
index 08e1470561..332a49556e 100644
--- a/src/LaTeXFeatures.cpp
+++ b/src/LaTeXFeatures.cpp
@@ -374,7 +374,21 @@ static docstring const lyxref_def = from_ascii(
" {\\def\\RSlemtxt{lemma~}\\newref{lem}{name = \\RSlemtxt}}\n"
" {}\n");
-// Make sure the columns are also outputed as rtl
+// Allow line wrapping after em- and en-dash
+static docstring const textdashes_utf8_def = from_ascii(
+ "\\DeclareUnicodeCharacter{2013}{--}\n"
+ "\\DeclareUnicodeCharacter{2014}{---}n");
+static docstring const textdashes_cp_def = from_ascii(
+ "\\DeclareInputText{150}{--}\n"
+ "\\DeclareInputText{151}{---}\n");
+static docstring const textdashes_next_def = from_ascii(
+ "\\DeclareInputText{177}{--}\n"
+ "\\DeclareInputText{208}{---}\n");
+static docstring const textdashes_mac_def = from_ascii(
+ "\\DeclareInputText{208}{--}\n"
+ "\\DeclareInputText{209}{---}\n");
+
+// Make sure the columns are also put out as rtl
static docstring const rtloutputdblcol_def = from_ascii(
"\\def\\@outputdblcol{%\n"
" \\if@firstcolumn\n"
@@ -1346,6 +1360,28 @@ TexString LaTeXFeatures::getMacros() const
if (mustProvide("textbaltic"))
macros << textbaltic_def << '\n';
+ // em- and en-dash
+// * \textemdash/\textendash prevents wraps before and after the dash
+// inptenc uses textemdash/textendash.
+// * The Unicode standard allows wraps before and after the dash.
+// * LaTeX ligatures "---" and "--" allow wraps after the dash.
+// lib/unicodesymbols inserts ligatures, for utf8 and utf8x we
+// override the inputenc definitions for consistency. Power users
+// may override this in the LaTeX preamble.
+ // FIXME:
+ // replace "encoding" by a variable containing the document input
encoding
+ if (mustProvide("textdashes")) {
+ if (encoding == "utf8" || encoding == "utf8x")
+ macros << textdashes_utf8_def << '\n';
+ else if (encoding == "ansinew" || encoding == "cp1250" ||
+encoding == "cp1252" || encoding == "cp1257")
+ macros << textdashes_cp_def << '\n';
+ else if (encoding == "next")
+ macros << textdashes_next_def << '\n';
+ else if (encoding == "applemac" || encoding == "macce")
+ macros << textdashes_mac_def << '\n';
+ }
+
// split-level fractions
if (mustProvide("xfrac") || mustProvide("smallLetterFrac"))
macros << xfrac_def << '\n';
Exec: git 'diff' 'unicodesymbols' 2>&1
Dir: /usr/local/src/lyx/lib/
diff --git a/lib/unicodesymbols b/lib/unicodesymbols
index d894a8e720..3bc28af7dd 100644
--- 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 "--" "textdashes" "notermination=text" # EN DASH
+0x2014 "---" "textdashes"
"force=armscii8,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"
