Re: alternatives for dashes (please vote)
On 2017-08-26, Enrico Forestieri wrote: > On Fri, Aug 25, 2017 at 09:38:11PM +, Guenter Milde wrote: >> >> -* LyX now outputs en- and em-dashes as -- and --- ligatures when >> >> exporting to >> >> - latex using TeX fonts, as done in version 2.1 and earlier. In version >> >> 2.2 >> >> - they were instead output as the macros \textendash and \textemdash, >> >> causing >> >> - changed output with old documents and bugs. The 2.2 behavior can be >> >> restored >> >> - by don't allowing using dash ligatures in Document->Settings->Fonts. >> > I find the above a concise and to the point description of the issue. >> I disagree. The above is an incorrect description. > We go into semantics here. If you wanted an en- or em-dash you would have > typed -- or ---. The chance that you were copy/pasting them is very low. How do you come to this conclusion? Copy/paste is not the only way. On my Linux system, Alt-Gr+- inserts –, a literal en-dash (default German keyboard mappings). On Macs, both em- and en-dash have keyboard-shortcuts: ... the n-dash is entered with Option-hyphen and the m-dash with Shift-Option-hyphen; this has been the case since 1984 On several occasions, Mac users wrote that they prefer the direct insertion of Unicode characters via system-wide keybindings over LyX specific solutions. (This occured during the discussion about the quote inset and in a discussion about dashes on lyx-users three years ago https://marc.info/?l=lyx-users&m=140982011101908&w=2 > The fact that \texte?dash macros could be output was an unfortunate > consequence of the change you mention below. Not really, it was intended: >> LyX exported en- and em-dashes as literal characters or >> \textemdash \textendash since 10 years. See >> https://www.lyx.org/trac/changeset/18802/lyxsvn The changeset comment says: "use commands for the dashes for consistency reasons and to avoid potential problems with some LaTeX-packages" This follows the decision of the LaTeX authors/mainteners: The LaTeX team introduced \text* commands replacing the font ligatures already 23 years ago and gave the reasons in "LaTeX2ε for authors" (usrguide.pdf): \textemdash \textendash \textexclamdown \textquestiondown \textquotedblleft \textquotedblright \textquoteleft \textquoteright New feature 1994/12/01 These commands produce characters which would otherwise be accessed via ligatures ... The reason for making these characters directly accessible is so that they will work in encodings which do not have these characters. > [...] >> The concise description could be something in the line of: >> >> + The new setting >> >> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" forces >> >> + output of en- and em-dashes as -- and --- when exporting to LaTeX. >> >> + The setting is on by default, unselected when opening documents edited >> >> + with LyX 2.2, and ignored for documents using non-TeX fonts. >> See for details. >> >> + See also "Caveats when upgrading from earlier versions to 2.3.x". > This seems much better. >> The list of caveats and incompatibilities may be shortened if we fix them. >> >> +* If you used literal em- and en-dashes in pre-2.2 documents, you must >> >> + manually unselect >> >> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" to >> >> + ensure unchanged line break behaviour. >> This can be avoided when setting the setting based on document content. > And what when both types are present? This is unfeasible. > As regards all other suggestions, nobody can read your mind. You have > to provide working patches demonstrating what you mean. You cannot simply > provide abstract descriptions eluding all possible problems that can arise > when you actually try to implement them. I will provide a patch. Günter
Re: alternatives for dashes (please vote)
On Fri, Aug 25, 2017 at 09:38:11PM +, Guenter Milde wrote: > On 2017-08-25, Enrico Forestieri wrote: > > On Thu, Aug 24, 2017 at 09:29:15PM +, Guenter Milde wrote: > >> > >> -* LyX now outputs en- and em-dashes as -- and --- ligatures when > >> exporting to > >> - latex using TeX fonts, as done in version 2.1 and earlier. In version > >> 2.2 > >> - they were instead output as the macros \textendash and \textemdash, > >> causing > >> - changed output with old documents and bugs. The 2.2 behavior can be > >> restored > >> - by don't allowing using dash ligatures in Document->Settings->Fonts. > > > I find the above a concise and to the point description of the issue. > > I disagree. The above is an incorrect description. We go into semantics here. If you wanted an en- or em-dash you would have typed -- or ---. The chance that you were copy/pasting them is very low. The fact that \texte?dash macros could be output was an unfortunate consequence of the change you mention below. > LyX exported en- and em-dashes as literal characters or > \textemdash \textendash since 10 years. See > https://www.lyx.org/trac/changeset/18802/lyxsvn [...] > The concise description could be something in the line of: > > >> + The new setting > >> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" forces > >> + output of en- and em-dashes as -- and --- when exporting to LaTeX. > >> + The setting is on by default, unselected when opening documents edited > >> + with LyX 2.2, and ignored for documents using non-TeX fonts. > See for details. > >> + See also "Caveats when upgrading from earlier versions to 2.3.x". This seems much better. > The list of caveats and incompatibilities may be shortened if we fix them. > > > >> +* If you used literal em- and en-dashes in pre-2.2 documents, you must > >> + manually unselect > >> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" to > >> + ensure unchanged line break behaviour. > > This can be avoided when setting the setting based on document content. And what when both types are present? This is unfeasible. As regards all other suggestions, nobody can read your mind. You have to provide working patches demonstrating what you mean. You cannot simply provide abstract descriptions eluding all possible problems that can arise when you actually try to implement them. -- Enrico
Re: alternatives for dashes (please vote)
On Fri, Aug 25, 2017 at 09:38:11PM +, Guenter Milde wrote: > I agree that it may be better to put the details in the manuals, The > RELEASE_NOTES should contain a list of incompatibilities/caveats and > links to the detailled description in the manual. +1, or (perhaps in addition) a link to trac tickets is also reasonable. Scott signature.asc Description: PGP signature
Re: alternatives for dashes (please vote)
On 2017-08-25, Enrico Forestieri wrote: > On Thu, Aug 24, 2017 at 09:29:15PM +, Guenter Milde wrote: >> On 2017-08-23, Scott Kostyshak wrote: >> > On Fri, Jul 28, 2017 at 03:45:28PM +0200, Pavel Sanda wrote: >> >> I tend to agree with f). It's not nice that we have such option in >> >> the prefs, but since we screw the situation already we at least >> >> give user some power to fix things onwards from 2.3 in his own way. >> >> And some exclamation mark in RELEASE_NOTES. >> > Can someone who understands the consequences please add an appropriate >> > note to RELEASE-NOTES ? >> Suggested patch: >> diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES >> index 591fcae476..07f1831568 100644 >> --- a/lib/RELEASE-NOTES >> +++ b/lib/RELEASE-NOTES >> @@ -13,11 +13,34 @@ >>be safely dissolved, as it will be automatically inserted at export time >>if needed, as usual. >> -* LyX now outputs en- and em-dashes as -- and --- ligatures when exporting >> to >> - latex using TeX fonts, as done in version 2.1 and earlier. In version 2.2 >> - they were instead output as the macros \textendash and \textemdash, >> causing >> - changed output with old documents and bugs. The 2.2 behavior can be >> restored >> - by don't allowing using dash ligatures in Document->Settings->Fonts. > I find the above a concise and to the point description of the issue. I disagree. The above is an incorrect description. LyX exported en- and em-dashes as literal characters or \textemdash \textendash since 10 years. See https://www.lyx.org/trac/changeset/18802/lyxsvn > Instead, what follows is too much verbose and confusing for the average > user. I don't think that 50 or more lines of text are appropriate for > release notes, especially if only 10% of users are able to comprehend it. > If you really think that such detailed explanations are necessary, then > they have to go somewhere into the manuals. I agree that it may be better to put the details in the manuals, The RELEASE_NOTES should contain a list of incompatibilities/caveats and links to the detailled description in the manual. The concise description could be something in the line of: >> + The new setting >> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" forces >> + output of en- and em-dashes as -- and --- when exporting to LaTeX. >> + The setting is on by default, unselected when opening documents edited >> + with LyX 2.2, and ignored for documents using non-TeX fonts. See for details. >> + See also "Caveats when upgrading from earlier versions to 2.3.x". The list of caveats and incompatibilities may be shortened if we fix them. >> +* If you used literal em- and en-dashes in pre-2.2 documents, you must >> + manually unselect >> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" to >> + ensure unchanged line break behaviour. This can be avoided when setting the setting based on document content. >> + It is no longer possible to differentiate dashes with/without optional >> + line break using --- and -- vs. literal dashes. >> + Either convert one sort to ERT or insert optional line break characters. This may go to the details in the manual page. >> + lyx2lyx deletes ZWSP characters following literal em- and en-dashes when >> + converting to 2.3 format. If you used literal ZWSP characters (u200b) as >> + optional line breaks after dashes, convert them to 0dd wide space insets >> + before opening your document with LyX 2.3 or the optional line breaks will >> + be lost. This were not necessary if back-conversion used \twohyphens and \threehyphens for en- and emdash when use-ligature-dashes is true. Advantages: correct behaviour in versions up to 2.1 no errors with versions older than 2.1 This would also allow to get rid of the caveat: >> * If using TeX fonts and en- and em-dashes are output as font ligatures, >>when exporting documents containing en- and em-dashes to the format of >>LyX 2.0 or earlier, the following line has to be manually added to the ... Con:no workaround (ZWSP) for 2.2 (we could even keep this workaround in additon to conversion to \towhyphens rsp. \threehyphens. but restricted to 2.2 file versions and cases without whitespace following the dashes) >> I can provide a patch. Günter
Re: alternatives for dashes (please vote)
On Thu, Aug 24, 2017 at 09:29:15PM +, Guenter Milde wrote:
> On 2017-08-23, Scott Kostyshak wrote:
>
> > [-- Type: text/plain, Encoding: quoted-printable --]
>
> > On Fri, Jul 28, 2017 at 03:45:28PM +0200, Pavel Sanda wrote:
>
> >> I tend to agree with f). It's not nice that we have such option in the
> >> prefs,
> >> but since we screw the situation already we at least give user some power
> >> to
> >> fix things onwards from 2.3 in his own way.
>
> >> And some exclamation mark in RELEASE_NOTES.
>
> > Can someone who understands the consequences please add an appropriate
> > note to RELEASE-NOTES ?
>
> Suggested patch:
>
> diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES
> index 591fcae476..07f1831568 100644
> --- a/lib/RELEASE-NOTES
> +++ b/lib/RELEASE-NOTES
> @@ -13,11 +13,34 @@
>be safely dissolved, as it will be automatically inserted at export time
>if needed, as usual.
>
> -* LyX now outputs en- and em-dashes as -- and --- ligatures when exporting to
> - latex using TeX fonts, as done in version 2.1 and earlier. In version 2.2
> - they were instead output as the macros \textendash and \textemdash, causing
> - changed output with old documents and bugs. The 2.2 behavior can be
> restored
> - by don't allowing using dash ligatures in Document->Settings->Fonts.
I find the above a concise and to the point description of the issue.
Instead, what follows is too much verbose and confusing for the average
user. I don't think that 50 or more lines of text are appropriate for
release notes, especially if only 10% of users are able to comprehend it.
If you really think that such detailed explanations are necessary, then
they have to go somewhere into the manuals.
> +* Since version 2.2, -- and --- in the LyX source are output as -{}- and
> + -{}-{}- because otherwise some fonts ligate them to en- and em-dash.
> + Occurences in pre-2.2 documents are converted to literal Unicode dashes.
> + In some cases this leads to different line breaks:
> + + There is an optional line break after hyphens (also -- and ---) but not
> +after literal dashes.
> + + Hyphenation is suppressed in words following hyphens but allowed after
> +literal dashes.
> +
> + The new setting
> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" forces
> + output of en- and em-dashes as -- and --- when exporting to LaTeX.
> + The setting is on by default, unselected when opening documents edited
> + with LyX 2.2, and ignored for documents using non-TeX fonts.
> + As with all settings, the default for new documents can be
> + configured via templates.
> +
> + + Select it, if you want optional line breaks after all en- and em-dashes
> +
> + + Unselect it to prevent unwelcome line breaks in range specifications
> +using an en-dash (like 13–15) or between a dash and a non-breaking space
> +(e.g. opening "quotation dashes" in French) and to avoid conversion of
> +an em-dash into en-dash+hyphen or three hyphens in "typewriter"
> +(monospaced) fonts. If required, optional line breaks can be inserted
> +with Insert>Formatting>Optional line break.
> +
> + See also "Caveats when upgrading from earlier versions to 2.3.x".
> +
>
> * The following UI translations were dropped, because the lack of translation
>maintenance: Russian, Danish, Greek, Serbian, Galician, Catalan, Romanian,
> @@ -154,6 +177,22 @@
>the external_templates file, you will have to move the modifications to
>the respective *.xtemplate file manually.
>
> +* If you used literal em- and en-dashes in pre-2.2 documents, you must
> + manually unselect
> + "Document->Settings->Fonts->Output em- and en-dash as ligatures" to ensure
> + unchanged line break behaviour.
> +
> + It is no longer possible to differentiate dashes with/without optional
> + line break using --- and -- vs. literal dashes. Either convert one sort to
> + ERT or insert optional line break characters.
> +
> + lyx2lyx deletes ZWSP characters following literal em- and en-dashes when
> + converting to 2.3 format. If you used literal ZWSP characters (u200b) as
> + optional line breaks after dashes, convert them to 0dd wide space insets
> + before opening your document with LyX 2.3 or the optional line breaks will
> + be lost.
> +
> +
> * If using TeX fonts and en- and em-dashes are output as font ligatures,
>when exporting documents containing en- and em-dashes to the format of
>LyX 2.0 or earlier, the following line has to be manually added to the
>
>
> Some of the problems can be avoided with minor changes to lyx2lyx:
>
> * setting use-ligature-dashes according to content instead of file
> version
> * convert dashes to "\twohyphens" rsp. "\threehyphens" if
> use-ligature-dashes is true.
>
> I can provide a patch.
>
> Günter
>
--
Enrico
Re: alternatives for dashes (please vote)
On 2017-08-23, Scott Kostyshak wrote:
> [-- Type: text/plain, Encoding: quoted-printable --]
> On Fri, Jul 28, 2017 at 03:45:28PM +0200, Pavel Sanda wrote:
>> I tend to agree with f). It's not nice that we have such option in the prefs,
>> but since we screw the situation already we at least give user some power to
>> fix things onwards from 2.3 in his own way.
>> And some exclamation mark in RELEASE_NOTES.
> Can someone who understands the consequences please add an appropriate
> note to RELEASE-NOTES ?
Suggested patch:
diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES
index 591fcae476..07f1831568 100644
--- a/lib/RELEASE-NOTES
+++ b/lib/RELEASE-NOTES
@@ -13,11 +13,34 @@
be safely dissolved, as it will be automatically inserted at export time
if needed, as usual.
-* LyX now outputs en- and em-dashes as -- and --- ligatures when exporting to
- latex using TeX fonts, as done in version 2.1 and earlier. In version 2.2
- they were instead output as the macros \textendash and \textemdash, causing
- changed output with old documents and bugs. The 2.2 behavior can be restored
- by don't allowing using dash ligatures in Document->Settings->Fonts.
+* Since version 2.2, -- and --- in the LyX source are output as -{}- and
+ -{}-{}- because otherwise some fonts ligate them to en- and em-dash.
+ Occurences in pre-2.2 documents are converted to literal Unicode dashes.
+ In some cases this leads to different line breaks:
+ + There is an optional line break after hyphens (also -- and ---) but not
+after literal dashes.
+ + Hyphenation is suppressed in words following hyphens but allowed after
+literal dashes.
+
+ The new setting
+ "Document->Settings->Fonts->Output em- and en-dash as ligatures" forces
+ output of en- and em-dashes as -- and --- when exporting to LaTeX.
+ The setting is on by default, unselected when opening documents edited
+ with LyX 2.2, and ignored for documents using non-TeX fonts.
+ As with all settings, the default for new documents can be
+ configured via templates.
+
+ + Select it, if you want optional line breaks after all en- and em-dashes
+
+ + Unselect it to prevent unwelcome line breaks in range specifications
+using an en-dash (like 13–15) or between a dash and a non-breaking space
+(e.g. opening "quotation dashes" in French) and to avoid conversion of
+an em-dash into en-dash+hyphen or three hyphens in "typewriter"
+(monospaced) fonts. If required, optional line breaks can be inserted
+with Insert>Formatting>Optional line break.
+
+ See also "Caveats when upgrading from earlier versions to 2.3.x".
+
* The following UI translations were dropped, because the lack of translation
maintenance: Russian, Danish, Greek, Serbian, Galician, Catalan, Romanian,
@@ -154,6 +177,22 @@
the external_templates file, you will have to move the modifications to
the respective *.xtemplate file manually.
+* If you used literal em- and en-dashes in pre-2.2 documents, you must
+ manually unselect
+ "Document->Settings->Fonts->Output em- and en-dash as ligatures" to ensure
+ unchanged line break behaviour.
+
+ It is no longer possible to differentiate dashes with/without optional
+ line break using --- and -- vs. literal dashes. Either convert one sort to
+ ERT or insert optional line break characters.
+
+ lyx2lyx deletes ZWSP characters following literal em- and en-dashes when
+ converting to 2.3 format. If you used literal ZWSP characters (u200b) as
+ optional line breaks after dashes, convert them to 0dd wide space insets
+ before opening your document with LyX 2.3 or the optional line breaks will
+ be lost.
+
+
* If using TeX fonts and en- and em-dashes are output as font ligatures,
when exporting documents containing en- and em-dashes to the format of
LyX 2.0 or earlier, the following line has to be manually added to the
Some of the problems can be avoided with minor changes to lyx2lyx:
* setting use-ligature-dashes according to content instead of file
version
* convert dashes to "\twohyphens" rsp. "\threehyphens" if
use-ligature-dashes is true.
I can provide a patch.
Günter
Re: alternatives for dashes (please vote)
On Wed, Aug 23, 2017 at 12:42:56AM -0400, Scott Kostyshak wrote: > On Fri, Jul 28, 2017 at 03:45:28PM +0200, Pavel Sanda wrote: > > > I tend to agree with f). It's not nice that we have such option in the > > prefs, > > but since we screw the situation already we at least give user some power to > > fix things onwards from 2.3 in his own way. > > > > And some exclamation mark in RELEASE_NOTES. > > Can someone who understands the consequences please add an appropriate > note to RELEASE-NOTES ? This is already documented there, AFAIK. -- Enrico
Re: alternatives for dashes (please vote)
On Fri, Jul 28, 2017 at 03:45:28PM +0200, Pavel Sanda wrote: > I tend to agree with f). It's not nice that we have such option in the prefs, > but since we screw the situation already we at least give user some power to > fix things onwards from 2.3 in his own way. > > And some exclamation mark in RELEASE_NOTES. Can someone who understands the consequences please add an appropriate note to RELEASE-NOTES ? Scott signature.asc Description: PGP signature
Re: alternatives for dashes (please vote)
On 08/11/2017 04:32 AM, Scott Kostyshak wrote: > On Wed, Aug 09, 2017 at 09:26:23PM +, Guenter Milde wrote: > >> d) convert "ligature dashes" to ERT >> >>-1 Enrico2017-06-01, "I am fiercely opposed to … ERT …" >>-1 Jean-Marc 16 Jul 2017 "nobody wants to really use it" >>+1 Richard 04/26/2017 "This seems the simplest." >>+1 Günter2017-08-09 "simple, 100% backwards compatible" >> > Richard, I am currently not counting you as having voted. If you would like > to vote, please do so as soon as possible. I don't feel I really understand this enough to have a strong opinion. And, yes, that wasn't really a vote, just an initial response. Richard
Re: alternatives for dashes (please vote)
Indeed. JMarc Le 11 août 2017 13:11:27 GMT+02:00, Pavel Sanda a écrit : >Guenter Milde wrote: >> f) keep the current 2.3alpha behaviour (buffer setting) >> >>+1 Pavel 28 Jul 2017 "I tend to agree with f)" >>+1 Enrico28 Jul 2017 "IMO, f) is the best compromise" >>-1 Günter04/25/17"possible data loss and formatting >changes" > >I believe JMarc is missing in this box. P
Re: alternatives for dashes (please vote)
Guenter Milde wrote: > f) keep the current 2.3alpha behaviour (buffer setting) > >+1 Pavel 28 Jul 2017 "I tend to agree with f)" >+1 Enrico28 Jul 2017 "IMO, f) is the best compromise" >-1 Günter04/25/17"possible data loss and formatting changes" I believe JMarc is missing in this box. P
Re: alternatives for dashes (please vote)
Scott Kostyshak wrote: > Pavel, should this be counted as a vote in favor of f? Correct. Pavel
Re: alternatives for dashes (please vote)
I vote to keep the current 2.3 behavior. JMarc Le 11 août 2017 10:32:57 GMT+02:00, Scott Kostyshak a écrit : >On Fri, Jul 28, 2017 at 11:46:52AM +0200, Jean-Marc Lasgouttes wrote: > >> I think the 2.3 behavior, as I understand it (aka ``pick your >poison'') at >> least has the benefit of being predictable. > >JMarc, which option do you vote for? > >Scott
Re: alternatives for dashes (please vote)
On Fri, Jul 28, 2017 at 03:45:28PM +0200, Pavel Sanda wrote: > I tend to agree with f). Pavel, should this be counted as a vote in favor of f? I would like to double-check since you seem a little hesitant. Scott signature.asc Description: PGP signature
Re: alternatives for dashes (please vote)
On Fri, Jul 28, 2017 at 11:46:52AM +0200, Jean-Marc Lasgouttes wrote: > I think the 2.3 behavior, as I understand it (aka ``pick your poison'') at > least has the benefit of being predictable. JMarc, which option do you vote for? Scott signature.asc Description: PGP signature
Re: alternatives for dashes (please vote)
On Wed, Aug 09, 2017 at 09:26:23PM +, Guenter Milde wrote: > d) convert "ligature dashes" to ERT > >-1 Enrico2017-06-01, "I am fiercely opposed to … ERT …" >-1 Jean-Marc 16 Jul 2017 "nobody wants to really use it" >+1 Richard 04/26/2017 "This seems the simplest." >+1 Günter2017-08-09 "simple, 100% backwards compatible" > Richard, I am currently not counting you as having voted. If you would like to vote, please do so as soon as possible. Scott signature.asc Description: PGP signature
Re: alternatives for dashes (please vote)
On Wed, Aug 09, 2017 at 09:26:23PM +, Guenter Milde wrote: > On 2017-08-09, Scott Kostyshak wrote: > > ... > > > Right now, it seems there is more support for f, which I understand to > > mean "do nothing" with respect to the current behavior in master. If > > anyone else would like to vote, please do so as soon as possible. I hope > > to release beta1 next week. > > For me, it is a different picture without a clear winner: > > Totals: > > +1 a) "literal dash + allowbreak" > +1 b) "special char" > +1 f) "buffer setting" > 0 d) "ERT" > -1 c) "keep 2.2 (literal dash)" > -1 e) "preamble code" > -1 g) "revert to 2.1" > > > I agree that there is a margin of error and I may have misunderstood or > missed some of the feedback. So, please correct me in case I got it wrong. I see what you mean. Your translation of the comments into votes contains more information. In some sense, it is similar to the type of vote where each participant ranks the options. However, for the final vote and the outcome, do you agree that we must use the standard voting procedure where each participant chooses one and only one option (and does not vote for/against any other option)? I can see the disadvantages to that, but I'm guessing that is what everyone expected when the vote started, and that was the type of vote used in the previous vote, so we should not implement a more advanced voting procedure for this one. Further, we can only count votes of participants in this thread. For example, regarding option "d", I do not consider Richard as having voted. Hopefully the participants in this vote will make it clear which option they prefer so we do not have to make guesses. I will CC them directly. If anyone else would like to vote, please do so as soon as possible. As for a "_clear_ winner", one thing that I think many agreed with in the previous vote is that a winner is a winner. Whether it is 2 to 1, or 10 to 9, we should accept the outcome and move forward. Thanks, Scott signature.asc Description: PGP signature
Re: alternatives for dashes (please vote)
On 2017-08-09, Scott Kostyshak wrote: ... > Right now, it seems there is more support for f, which I understand to > mean "do nothing" with respect to the current behavior in master. If > anyone else would like to vote, please do so as soon as possible. I hope > to release beta1 next week. For me, it is a different picture without a clear winner: Totals: +1 a) "literal dash + allowbreak" +1 b) "special char" +1 f) "buffer setting" 0 d) "ERT" -1 c) "keep 2.2 (literal dash)" -1 e) "preamble code" -1 g) "revert to 2.1" I agree that there is a margin of error and I may have misunderstood or missed some of the feedback. So, please correct me in case I got it wrong. Details: a) convert ligature dashes to literal dash + allowbreak +1 Günter 13 Jun 2017 "simple and configurable" b) convert ligature dashes to special character insets +0 Günter "100% backwards compatible but complicated" +1 Jean-Marc 16 Jul 2017 "I … prefer … a special inset over … ERT" c) keep 2.2 behaviour (convert ligature dashes to literal dashes) -1 Enrico 2017-06-15 d) convert "ligature dashes" to ERT -1 Enrico2017-06-01, "I am fiercely opposed to … ERT …" -1 Jean-Marc 16 Jul 2017 "nobody wants to really use it" +1 Richard 04/26/2017 "This seems the simplest." +1 Günter2017-08-09 "simple, 100% backwards compatible" e) re-define \textemdash -1 Jean-Marc 28 Jul 2017 "bound to cause us trouble one day" f) keep the current 2.3alpha behaviour (buffer setting) +1 Pavel 28 Jul 2017 "I tend to agree with f)" +1 Enrico28 Jul 2017 "IMO, f) is the best compromise" -1 Günter04/25/17"possible data loss and formatting changes" g) revert to 2.1 behaviour -1 Günter Thanks, Günter
Re: alternatives for dashes (please vote)
On Thu, Jul 27, 2017 at 09:27:41PM +, Guenter Milde wrote: > Dear LyX developers, > > following Scotts suggestion, I prepared an overview of alternatives to > handle the problem with 2.2 breaking formatting of em- and en-dashes. > Comments and votes welcome. > > Unfortunately, the topic is emotionally loaded, as we did a mistake and > there is no solution that everyone will agree with. OTOH, it is complex, but > not very important. Thank you very much for your time on this, Günter, and for laying out all of the options and giving the pluses and minuses. Right now, it seems there is more support for f, which I understand to mean "do nothing" with respect to the current behavior in master. If anyone else would like to vote, please do so as soon as possible. I hope to release beta1 next week. Scott signature.asc Description: PGP signature
Re: alternatives for dashes (please vote)
Le 27/07/2017 à 23:27, Guenter Milde a écrit : Dear LyX developers, following Scotts suggestion, I prepared an overview of alternatives to handle the problem with 2.2 breaking formatting of em- and en-dashes. Comments and votes welcome. Unfortunately, the topic is emotionally loaded, as we did a mistake and there is no solution that everyone will agree with. OTOH, it is complex, but not very important. The Problem === Up to version 2.2, LyX used 2 representations for em- and en-dashes: "literal" dashes: literal Unicode or \textemdash rsp. \textendash macro, "ligature" dashes: "---" and "--" converted by the TeX font ligature mechanism. "Ligature" and "literal" dashes can coexist in <2.2-documents, e.g., when parts were copy-pasted from different sources. LyX 2.2 uses only one representation and converts "ligature dashes" to "literal dashes". This turned out to break formatting in some documents, because "literal" dashes suppress line breaks after the dash and allow hyphenation in adjacent words while "ligature dashes" allow line breaks after the dash and suppress hyphenation in adjacent words. There are use cases for both, dashes with and without optional line break **switching the representation either way can lead to broken output** (overfull lines or unwanted line breaks). For details and examples see http://www.lyx.org/trac/ticket/10543#comment:3 and http://www.lyx.org/trac/attachment/ticket/10543/emdash-line-breaks.lyx Alternatives for 2.3 a) convert ligature dashes to literal dash + allowbreak + keeps formatting in most cases - allows (possibly undesired) hyphenation in adjacent words - a redefinition of \text*dash would also affect former "ligature" dashes. + simple + configurable/editable (special char can easily be deleted) ± verbose (the "allowbreak" special-char is displayed as a small blue mark) b) convert ligature dashes to "special character" insets + no change to LaTeX output. - requires "special character" inset for ordinary printable character - does not scale well + precedence cases: curly quotes, text ellipsis c) keep 2.2 behaviour (convert ligature dashes to literal dashes) + simple + no change for 2.2 documents (the damage is already done) - breaks formatting for <2.2 documents using ligature dashes d) convert "ligature dashes" to ERT + no change to LaTeX output + simple - ERT for formerly supported feature e) re-define \textemdash + simple (except for LuaTeX) + already done by XeTeX (http://tex.stackexchange.com/questions/62800/lualatex-and-line-breaks-after-em-dashes) + configurable - hidden in the user preamble f) keep the current 2.3alpha behaviour + configurable - breaks formatting for <2.2 documents using literal dashes (these were not affected by the change in 2.2) - new document setting for LaTeX export of Unicode characters: - does not scale well, - unprecedented - Data loss (ZWSP following dashes are removed by lyx2lyx) - different line breaks of the same document with LuaTeX and non-TeX fonts g) revert to 2.1 behaviour - regression on bugs #3647 and #8561 - no WYSIWYM: "lyx --help" in the GUI becomes "lyx –help" in the output. Alternatives b there are two pairs of dashes ), c), d) and e) could also be applied to 2.2.x, a) and f) require a fileformat change. Open question: which representation to use with the -- and --- input conversion? * The simplest way is to keep 2.2 behaviour (insert literal dashes). * Maybe we can use a lyxfun with options that will be bound to the '-'-key? * Sensible defaults would be allow linebreak after em-dash prevent linebreak after en-dash. Rationale: en-dash around an ellipsis is used with spaces, no line break allowed in ranges. Günter So for each dash there are two variants, one with a line break opportunity and one without, and all have a use. Do I understand correctly? Then, one should first decide how/whether to (ideally) present the various combinations to the user in 2.3. The answer to the question of converting 2.2 to 2.3 will follow from there. Do you agree that the real question is what dashes one wants to propose to users in 2.3 and how? About e): redefining \textemdash is not nice, instead one could define a new \lyxemdash. What are the caveats?
Re: alternatives for dashes (please vote)
Guenter Milde wrote: Thanks Guenter for the summary. > Patch [72a488d7/lyxgit] introduced the new buffer setting > "use_dash_ligatures" that controls the latex output of dashes as either > font ligatures or Unicode/LICR. > The setting can be changed under Document>Settings>Fonts. > The "use_dash_ligatures" setting is set based on fileformat version, not > content. The default is "true". I tend to agree with f). It's not nice that we have such option in the prefs, but since we screw the situation already we at least give user some power to fix things onwards from 2.3 in his own way. And some exclamation mark in RELEASE_NOTES. I could even imagine some measure for the last 2.2 stable. It could still make it to debian stretch LTS; 2.2 did not make it fortunately to ubuntu LTS at all (sign that we are releasing way too fast :)). Such measure would preserve <2.2 docs to be safely saved without conversion to 2.2 literals and allow smooth transition to 2.3... Pavel
Re: alternatives for dashes (please vote)
Le 28/07/2017 à 11:09, Guenter Milde a écrit :
• allow line breaks after em- and en-dash with re-definition using
\allowbreak:
\let\origtextemdash\textemdash
\renewcommand{\textemdash}{\origtextemdash\allowbreak}
I would vote against such redefinitions, which are IMO bound to cause us
trouble one day (I used to be very fond of these clever tricks). We
should adapt to whatever LaTeX provides, and complain loudly when
different engines are not able to agree about what the strategy should be.
That leaves with only 6 solutions to consider.
However, I wonder whether a solution can always works. Consider the
case of French typography. Even though it is usual to use spacing, we
are supposed to do like this:
Les incises –~même si tout le monde ne les aime pas~– sont très utiles.
So the inner space has to be unbreakable, which is probably the case in
other languages too. My knowledge of typography is limited on this
point, but isn't it the case when there is no space?
I think the 2.3 behavior, as I understand it (aka ``pick your poison'')
at least has the benefit of being predictable.
JMarc
Re: alternatives for dashes (please vote)
On 2017-07-27, Pavel Sanda wrote:
> Could you expand little bit, what e) means
Examples:
• allow line breaks after em- and en-dash with re-definition using
\allowbreak:
\let\origtextemdash\textemdash
\renewcommand{\textemdash}{\origtextemdash\allowbreak}
• allow line breaks after em- and en-dash with re-definition using ligatures:
\renewcommand{\textemdash}{---}
* For LuaTeX with non-TeX fonts, you need to make the EM DASH character active
\catcode`\—=13
\protected\def—{\textemdash\allowbreak}
or
\catcode`\—=13
\protected\def—{---}
* In XeTeX with non-TeX fonts, the literal dash behaves like a ligature
dash by default.
(You can change this to \text*dash like behaviour with the preamble
setting \XeTeXdashbreakstate=0).
See http://www.lyx.org/trac/ticket/10543#comment:1
and the examples
http://www.lyx.org/trac/raw-attachment/ticket/10543/emdash-line-breaks.lyx
http://www.lyx.org/trac/raw-attachment/ticket/10543/emdash-line-breaks.2.lyx
> what f) the current 2.3alpha behavior is?
Patch [72a488d7/lyxgit] introduced the new buffer setting
"use_dash_ligatures" that controls the latex output of dashes as either
font ligatures or Unicode/LICR.
The setting can be changed under Document>Settings>Fonts.
The "use_dash_ligatures" setting is set based on fileformat version, not
content. The default is "true".
See http://www.lyx.org/trac/ticket/10543#comment:2 and
http://www.lyx.org/trac/ticket/10543#comment:3
Günter
Re: alternatives for dashes (please vote)
On Fri, Jul 28, 2017 at 12:51:39AM +0200, Pavel Sanda wrote: > Guenter Milde wrote: > > Comments and votes welcome. > ... > > e) re-define \textemdash > > f) keep the current 2.3alpha behaviour > > Could you expand little bit, what e) means and what f) the current 2.3alpha > behavior is? Thanks. Pavel IMO, f) is the best compromise. Only a small percentage of pre 2.2 documents using literal dashes may be affected, but the vast majority of documents not edited with 2.2 (i.e., old documents created with version 2.1 or previous) and those created with 2.2 are fine. So, I have no doubt that nothing has to be done as regard dashes. What matters is not that an issue may occur but the probability by which that issue will occur. All envisaged issues are low probability issues, so they are not really issues. -- Enrico
Re: alternatives for dashes (please vote)
Guenter Milde wrote: > Comments and votes welcome. ... > e) re-define \textemdash > f) keep the current 2.3alpha behaviour Could you expand little bit, what e) means and what f) the current 2.3alpha behavior is? Thanks. Pavel
