Re: dash patch for stable
Le 14/06/2017 à 20:08, Scott Kostyshak a écrit : OK. So we are stuck. I want to come to a decision before beta1. I'm not sure what to suggest. I get the feeling that we've had enough discussion and further discussion will not lead to a unanimous agreement. In this case, I suppose we need to take a vote. Can I get a +1 from someone else that thinks a vote would be a good idea in this situation? OK, now that I have gambled one of my feet on the minted debate, it is time to put my second foot onto the hyphen mindfield (the trick is to keep your foot firmly on the ground after hearing the 'click' of the mine [1]). I would really prefer a solution based on a special inset over another one using ERT. Seriously, ERT is the theoretical solution, nobody wants to really use it. This is the point where we see that Unicode is not the solution to all of our problems... So I see two solutions: 1/ we decide that our dedication to keeping the format of documents is of the "best effort" kind and we do nothing (what about that for best effort?) 2/ we introduce in 2.3 a special character that does whatever it needs to do to preserve formatting JMarc [1] As demonstrated in the short novel "The Ants", by Boris Vian. OK OK, this is not really relevant to non-French-speaking people, and probably not relevant either to French-speaking people born after 1980.
Re: dash patch for stable
On Wed, Jun 14, 2017 at 11:48:13PM -0400, Richard Heck wrote: > On 06/14/2017 02:08 PM, Scott Kostyshak wrote: > > On Tue, Jun 13, 2017 at 09:30:03PM +, Guenter Milde wrote: > >> On 2017-06-09, Scott Kostyshak wrote: > >> > >>> [-- Type: text/plain, Encoding: --] > >>> On Mon, Jun 05, 2017 at 07:41:21AM +, Guenter Milde wrote: > I don't have a preference regarding the two alternative patches for > stable. > >>> And what is the status of this discussion for 2.3.0? Did we come to an > >>> agreement on what should be done? > >> Unfortunately, there is no agreement. > > OK. So we are stuck. I want to come to a decision before beta1. I'm not > > sure what to suggest. I get the feeling that we've had enough discussion > > and further discussion will not lead to a unanimous agreement. In this > > case, I suppose we need to take a vote. Can I get a +1 from someone else > > that thinks a vote would be a good idea in this situation? > > Yes, that's the way we have proceeded in the past when there were such > disagreements. > > > (if indeed I get a +1 on the above) to proceed with a vote, anyone who > > would like to make a proposal would need to write a self-contained > > description of the problem and their proposed solution. A critique of > > other available solutions is encouraged as well, so that we get a > > feeling of the advantages/disadvantages of each proposed solution. I > > emphasize self-contained because the discussion has been spread out and > > we want people to participate in the vote who have not followed the > > discussion so far. In addition to the essence of the proposal being > > self-contained, you are welcome to make references to previous > > discussion if you want to give the reader the option of reading a > > particular issue more in detail. But don't waste time on this until we > > get a +1 to proceed with a vote. > > + a lot. We defintely need a summary of what the issue is. Günter, are you planning to make a proposal so that we can vote? I'm sorry to ask you to do this when you have already spent a lot of time on the topic, but I am hoping that this round will be the last one and that we can vote and come to a conclusion, and that we can decide this before 2.3.0beta1. Thanks for all of your time on this topic. I regret not taking the time to fully understand all of the discussion before (I was secretly hoping unanimous agreement would be achieved), but I look forward to spending time to understand the advantages/disadvantages of your self-contained proposal. Scott signature.asc Description: PGP signature
Re: dash patch for stable
On Tue, Jun 20, 2017 at 02:59:00AM +0200, Guillaume MM wrote: > > Enrico, I also have to criticise this sort of comment of yours. I am > sorry to say that to me it looks disconnected with the understanding of > the problem at the time and gratuitous. Guillame, I have also to criticize this hypocritical comment of yours. You are simply trying to giving back the same criticism you received in the past. Sorry, but this shows your real attitude. -- Enrico
Re: dash patch for stable
On Tue, Jun 20, 2017 at 02:59:00AM +0200, Guillaume MM wrote: > Le 03/06/2017 à 01:08, Enrico Forestieri a écrit : > > On Fri, Jun 02, 2017 at 07:30:34PM +, Guenter Milde wrote: > > > > > > Note that the "ERT patch" is only for *stable*, i.e. 2.2.x. > > > For 2.2, ERT is the only way to ensure full backwards compatibility. > > > > A solution should have been thought and done before 2.2.0 was released. > > Now it's too late. > > > > Enrico, I also have to criticise this sort of comment of yours. I am > sorry to say that to me it looks disconnected with the understanding of > the problem at the time and gratuitous. Yes, you are right. -- Enrico
Re: dash patch for stable
Le 03/06/2017 à 01:08, Enrico Forestieri a écrit : On Fri, Jun 02, 2017 at 07:30:34PM +, Guenter Milde wrote: Note that the "ERT patch" is only for *stable*, i.e. 2.2.x. For 2.2, ERT is the only way to ensure full backwards compatibility. A solution should have been thought and done before 2.2.0 was released. Now it's too late. Enrico, I also have to criticise this sort of comment of yours. I am sorry to say that to me it looks disconnected with the understanding of the problem at the time and gratuitous. Guillaume
Re: dash patch for stable
On Thu, Jun 15, 2017 at 07:29:35PM +0200, Enrico Forestieri wrote: > On Thu, Jun 15, 2017 at 03:06:28PM +0200, Pavel Sanda wrote: > > Richard Heck wrote: > > > We defintely need a summary of what the issue is. > > > > Yes, if both parties could provide summary from their POV that would be > > helpful. > > I don't know who are the parties, but if something has to be improved > I am not opposed. Here, improvement is not meant as changing it as it > was previously or mangling it so that to satisfy the needs of 1% of > users. So, I will comment after seeing a proposal Makes sense. "Doing nothing" is a fair proposal as well. Scott
Re: dash patch for stable
On Thu, Jun 15, 2017 at 03:06:28PM +0200, Pavel Sanda wrote: > Richard Heck wrote: > > We defintely need a summary of what the issue is. > > Yes, if both parties could provide summary from their POV that would be > helpful. I don't know who are the parties, but if something has to be improved I am not opposed. Here, improvement is not meant as changing it as it was previously or mangling it so that to satisfy the needs of 1% of users. So, I will comment after seeing a proposal, possibly explained in less than 183 lines of text. -- Enrico
Re: dash patch for stable
Richard Heck wrote: > We defintely need a summary of what the issue is. Yes, if both parties could provide summary from their POV that would be helpful. Pavel
Re: dash patch for stable
On 06/14/2017 02:08 PM, Scott Kostyshak wrote: > On Tue, Jun 13, 2017 at 09:30:03PM +, Guenter Milde wrote: >> On 2017-06-09, Scott Kostyshak wrote: >> >>> [-- Type: text/plain, Encoding: --] >>> On Mon, Jun 05, 2017 at 07:41:21AM +, Guenter Milde wrote: I don't have a preference regarding the two alternative patches for stable. >>> And what is the status of this discussion for 2.3.0? Did we come to an >>> agreement on what should be done? >> Unfortunately, there is no agreement. > OK. So we are stuck. I want to come to a decision before beta1. I'm not > sure what to suggest. I get the feeling that we've had enough discussion > and further discussion will not lead to a unanimous agreement. In this > case, I suppose we need to take a vote. Can I get a +1 from someone else > that thinks a vote would be a good idea in this situation? Yes, that's the way we have proceeded in the past when there were such disagreements. > (if indeed I get a +1 on the above) to proceed with a vote, anyone who > would like to make a proposal would need to write a self-contained > description of the problem and their proposed solution. A critique of > other available solutions is encouraged as well, so that we get a > feeling of the advantages/disadvantages of each proposed solution. I > emphasize self-contained because the discussion has been spread out and > we want people to participate in the vote who have not followed the > discussion so far. In addition to the essence of the proposal being > self-contained, you are welcome to make references to previous > discussion if you want to give the reader the option of reading a > particular issue more in detail. But don't waste time on this until we > get a +1 to proceed with a vote. + a lot. We defintely need a summary of what the issue is. rh
Re: dash patch for stable
On Tue, Jun 13, 2017 at 09:30:03PM +, Guenter Milde wrote: > On 2017-06-09, Scott Kostyshak wrote: > > > [-- Type: text/plain, Encoding: --] > > > On Mon, Jun 05, 2017 at 07:41:21AM +, Guenter Milde wrote: > > >> I don't have a preference regarding the two alternative patches for stable. > > > And what is the status of this discussion for 2.3.0? Did we come to an > > agreement on what should be done? > > Unfortunately, there is no agreement. OK. So we are stuck. I want to come to a decision before beta1. I'm not sure what to suggest. I get the feeling that we've had enough discussion and further discussion will not lead to a unanimous agreement. In this case, I suppose we need to take a vote. Can I get a +1 from someone else that thinks a vote would be a good idea in this situation? (if indeed I get a +1 on the above) to proceed with a vote, anyone who would like to make a proposal would need to write a self-contained description of the problem and their proposed solution. A critique of other available solutions is encouraged as well, so that we get a feeling of the advantages/disadvantages of each proposed solution. I emphasize self-contained because the discussion has been spread out and we want people to participate in the vote who have not followed the discussion so far. In addition to the essence of the proposal being self-contained, you are welcome to make references to previous discussion if you want to give the reader the option of reading a particular issue more in detail. But don't waste time on this until we get a +1 to proceed with a vote. Scott signature.asc Description: PGP signature
Re: dash patch for stable
On 2017-06-09, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: --] > On Mon, Jun 05, 2017 at 07:41:21AM +, Guenter Milde wrote: >> I don't have a preference regarding the two alternative patches for stable. > And what is the status of this discussion for 2.3.0? Did we come to an > agreement on what should be done? Unfortunately, there is no agreement. I prefer the "allowbreak" special character after "former ligature dashes" (\twohyphen, \threehyphen), ideally * for \threehyphen (em-dash) only if no space follows, * for \twohyphen (en-dash) only if no space or digit follows (to prevent unwanted line-breaks in ranges like "12--99"). I could provide a patch for the "specialchar inset", but would need help with the test for the next character. Günter
Re: dash patch for stable
On Mon, Jun 05, 2017 at 07:41:21AM +, Guenter Milde wrote: > I don't have a preference regarding the two alternative patches for stable. And what is the status of this discussion for 2.3.0? Did we come to an agreement on what should be done? Scott signature.asc Description: PGP signature
Re: dash patch for stable
On 2017-06-03, Enrico Forestieri wrote: > [-- Type: text/plain, Encoding: --] > On Sat, Jun 03, 2017 at 01:08:07AM +0200, Enrico Forestieri wrote: >> On Fri, Jun 02, 2017 at 07:30:34PM +, Guenter Milde wrote: >> > >> > Note that the "ERT patch" is only for *stable*, i.e. 2.2.x. >> > For 2.2, ERT is the only way to ensure full backwards compatibility. >> A solution should have been thought and done before 2.2.0 was released. >> Now it's too late. > Anyway, the attached patch should ensure backwards compatibility > in stable without resorting to ERT. This is the "90% compatible" workaround also suggested in >> http://www.lyx.org/trac/ticket/10543 as a possible alternative. Mind, that it does not prevent all line-break changes: with ---, hyphenation in adjacent words is suppressed, with \textemdash+ZWSP, hyphenation in adjacent words is allowed. See the attachments to http://www.lyx.org/trac/ticket/10543 for examples where this leads to different output. I don't have a preference regarding the two alternative patches for stable. Günter
Re: dash patch for stable
On Sat, Jun 03, 2017 at 01:08:07AM +0200, Enrico Forestieri wrote:
> On Fri, Jun 02, 2017 at 07:30:34PM +, Guenter Milde wrote:
> >
> > Note that the "ERT patch" is only for *stable*, i.e. 2.2.x.
> > For 2.2, ERT is the only way to ensure full backwards compatibility.
>
> A solution should have been thought and done before 2.2.0 was released.
> Now it's too late.
Anyway, the attached patch should ensure backwards compatibility
in stable without resorting to ERT.
--
Enrico
diff --git a/src/Text.cpp b/src/Text.cpp
index 4e593ddf23..5d00ba7117 100644
--- a/src/Text.cpp
+++ b/src/Text.cpp
@@ -520,6 +520,7 @@ void Text::readParToken(Paragraph & par, Lexer & lex,
par.insertChar(par.size(), 0x2013, font,
change);
else
par.insertChar(par.size(), 0x2014, font,
change);
+ par.insertChar(par.size(), 0x200B, font, change);
}
} else if (token == "\\backslash") {
par.appendChar('\\', font, change);
Re: dash patch for stable
On Fri, Jun 02, 2017 at 07:30:34PM +, Guenter Milde wrote: > > Note that the "ERT patch" is only for *stable*, i.e. 2.2.x. > For 2.2, ERT is the only way to ensure full backwards compatibility. A solution should have been thought and done before 2.2.0 was released. Now it's too late. -- Enrico
Re: dash patch for stable
On 2017-06-01, Enrico Forestieri wrote: > On Thu, Jun 01, 2017 at 09:12:53PM +, Guenter Milde wrote: >> On 2017-05-26, Scott Kostyshak wrote: >> > On Fri, May 19, 2017 at 09:12:27AM -0400, Scott Kostyshak wrote: >> >> Günter has written a lot about what to do regarding em- and en-dashes. >> >> For more information, see: >> >> http://www.lyx.org/trac/ticket/10543 >> >> Does anyone else have feedback on what should be done on this for 2.3.0? >> There is now a patch for stable attached to the ticket. >> Thanks to Enrico for the inset code. >> http://www.lyx.org/trac/raw-attachment/ticket/10543/0001-Keep-distinction-of-literal-dashes-vs-ligature-dashes-in-2-2.patch >> OK to commit? > Sorry, but I am opposed to this patch. You really mean to have all > en/em-dashes become ERT!!! So we have a conflict: When I asked >> How important is backwards compatibility for documents generated with LyX >> 2.1 or older? >>a) no need to restore after it's broken by 2.2. >>b) good but not required >>c) small changes tolerable as long as documents >> open and compile >>d) 100% backwards compatibility whenever possible. On 2017-05-31, Richard Heck wrote: > I believe the rule is (d). The reasoning is, that it is most annoying, if existing documents show different layout (line or page-breaks etc.) when compiled with a new LyX version, as this can easily go unnoticed until it is too late (document printed and submitted...). Note that the "ERT patch" is only for *stable*, i.e. 2.2.x. For 2.2, ERT is the only way to ensure full backwards compatibility. I am fine if the decision is not to restore full backwards compatibility in the last release in the 2.2 series. (Considering that in most cases the damage is already done.) I leave the decision to the release manager. Günter
Re: dash patch for stable
On Thu, Jun 01, 2017 at 09:12:53PM +, Guenter Milde wrote: > On 2017-05-26, Scott Kostyshak wrote: > > On Fri, May 19, 2017 at 09:12:27AM -0400, Scott Kostyshak wrote: > >> Günter has written a lot about what to do regarding em- and en-dashes. > >> For more information, see: > > >> http://www.lyx.org/trac/ticket/10543 > > >> Does anyone else have feedback on what should be done on this for 2.3.0? > > There is now a patch for stable attached to the ticket. > Thanks to Enrico for the inset code. > > http://www.lyx.org/trac/raw-attachment/ticket/10543/0001-Keep-distinction-of-literal-dashes-vs-ligature-dashes-in-2-2.patch > > OK to commit? Sorry, but I am opposed to this patch. You really mean to have all en/em-dashes become ERT!!! -- Enrico
