Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
On Sat, Feb 24, 2018 at 12:23:52AM +, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > Haha! Yeah, we should announce that users shouldn't be surprised if LyX > > > gets some lengths wrongs because its allowed to drink now! > > > > Yeah, it might occassionally black out as well. > > :)) Especially with new painting stuff on Mac (Apple Vodka flavors). P Well, I don't know if it will be any better after drinking Window cleaner. Scott signature.asc Description: PGP signature
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
Scott Kostyshak wrote: > > Haha! Yeah, we should announce that users shouldn't be surprised if LyX > > gets some lengths wrongs because its allowed to drink now! > > Yeah, it might occassionally black out as well. :)) Especially with new painting stuff on Mac (Apple Vodka flavors). P
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
On Fri, Feb 23, 2018 at 10:48:59PM +, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > Aren't we supposed to celebrate rounded years or something like that? > > > > Try to go into a bar in the U.S. when you are 20.51 years old and order > > a drink :) > > Haha! Yeah, we should announce that users shouldn't be surprised if LyX > gets some lengths wrongs because its allowed to drink now! Yeah, it might occassionally black out as well. > > If I open > > > > https://www.mail-archive.com/search?l=mid&q=20180131063641.otaji7vmdbqehima%40steph > > > > all of the links work fine for me on Firefox and Chromium. For you, the > > period after the "BugTrackerHome" URL causes a problem on Firefox? > > If you look meticulously mail-archive filters '.' out from url. But if you > copy paste the whole string I believe even your firefox will have problems. Ah I see now what you mean. You're talking about copy/pasting. I thought you were talking about clicking on the URL. OK it sounds like the current ANNOUNCE is OK then. Scott signature.asc Description: PGP signature
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
Scott Kostyshak wrote: > > Aren't we supposed to celebrate rounded years or something like that? > > Try to go into a bar in the U.S. when you are 20.51 years old and order > a drink :) Haha! Yeah, we should announce that users shouldn't be surprised if LyX gets some lengths wrongs because its allowed to drink now! > If I open > > https://www.mail-archive.com/search?l=mid&q=20180131063641.otaji7vmdbqehima%40steph > > all of the links work fine for me on Firefox and Chromium. For you, the > period after the "BugTrackerHome" URL causes a problem on Firefox? If you look meticulously mail-archive filters '.' out from url. But if you copy paste the whole string I believe even your firefox will have problems. Pavel
Re: Applying LFUN_MATH_MODE to big help docs causes memory problems
On 2018-02-23, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > On Fri, Feb 23, 2018 at 09:42:07AM +, Jean-Marc Lasgouttes wrote: >> Le 12/01/2018 à 23:28, Scott Kostyshak a écrit : >> > I'm not sure what the desired behavior is. Perhaps if the selection >> > contains insets of a certain type (e.g. a float), the LFUN should just >> > abort with a relevant message in the message pain. Any other ideas on >> > what the desired behavior is? >> What refusing to do something if the selection is longer than, say, 50 >> paragraphs? We could count characters too, of course, but do we want to >> transform a full document to a docstring just to be able to decide that it >> is too long? > Is the problem the length or is the problem that the selection contains > insets of a type that have no natural conversion to math? Checking for insets that cannot be converted to math should also solve most real-life cases where this behaviour may matter. If it is not too costly or difficult to implement, I'd prefer this. Günter
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
On Fri, Feb 23, 2018 at 09:32:24AM +, José Abílio Matos wrote: > On Friday, 23 February 2018 03.34.52 WET Joel Kulesza wrote: > > Minor wording question here and on the website: is "down" potentially > > confusing for a non-native English speaker? Would "unavailable" be more > > clear? > > In the case of (European) Portuguese the equivalent of down is the word that > we use > for those cases so it is not confusing. :-) > > OTHO I agree that "unavailable" is more correct since the problems come > because the > server is unavailable even if it is not down (e.g. a problem with the local > network, ...). Since we say "slow or down" isn't no movement an extreme case of "slow", in which case we can just simplify the entire phrase to "slow"? Or does "slow" imply strictly positive movement? On a more serious note, I agree that "unavailable" is more clear, and have changed it on the website. > Now personally I understand the idea of down in a physical sense, when we > shutdown a > server the fans stop and it really seems as if a plane just landed. ;-) > > PS: Sorry for wasting everyone a few seconds reading this message. :-) To get you back, I made you waste time with thinking about my above proposal :) Scott signature.asc Description: PGP signature
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
On Fri, Feb 23, 2018 at 10:10:38AM +, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > -The 2.3 series has a rich set of new features compared to the current > > > stable > > > -series. An overview of the new features can be found here: > > > +With this release, LyX celebrates 22 years of existence. The 2.3 series > > > > How many years of existence are we celebrating? According to this > > Aren't we supposed to celebrate rounded years or something like that? Try to go into a bar in the U.S. when you are 20.51 years old and order a drink :) > But quite frankly, who cares :) Well, it would be nice to just figure it out so that it is one less thing to think through each time when editing the ANNOUNCE. I don't care in which way we determine it, but it would be nice to know if anyone else cares. Or we can just remove the part about the years. I don't have a preference between rounding, flooring, or excluding. > > Pavel, you added a space in-between a URL and a period at ca7aae8d, but you > > did > > not add a space for the others. Should we add a space for the others as > > well? > > I tested only with firefox. If I open https://www.mail-archive.com/search?l=mid&q=20180131063641.otaji7vmdbqehima%40steph all of the links work fine for me on Firefox and Chromium. For you, the period after the "BugTrackerHome" URL causes a problem on Firefox? > It does well if "." is just behind domain name, it > breaks if you made it part of filename, which makes sense. So basically, if the last part of the link is a slash, there is no problem if a period follows. Otherwise there is a problem. OK, so in this case the current ANNOUNCE is fine. Good to know. Scott signature.asc Description: PGP signature
Re: 2.3 new behaviour wrt external changes of .lyx file
On Fri, Feb 23, 2018 at 01:03:52PM +, Kornel Benko wrote: > > I propose that we drop the '*' modification flag and let only the warning > > about external modification. That way one can easily see whether there is > > merge problem because file got edited meanwhile or just reload is enough. > > > > Opinions? > > > > Pavel > > +1 That makes sense. I think I encountered this exact same confusion before, but did not realize that the * is always added. Scott signature.asc Description: PGP signature
Re: Applying LFUN_MATH_MODE to big help docs causes memory problems
On Fri, Feb 23, 2018 at 09:42:07AM +, Jean-Marc Lasgouttes wrote: > Le 12/01/2018 à 23:28, Scott Kostyshak a écrit : > > I'm not sure what the desired behavior is. Perhaps if the selection > > contains insets of a certain type (e.g. a float), the LFUN should just > > abort with a relevant message in the message pain. Any other ideas on > > what the desired behavior is? > > What refusing to do something if the selection is longer than, say, 50 > paragraphs? We could count characters too, of course, but do we want to > transform a full document to a docstring just to be able to decide that it > is too long? Is the problem the length or is the problem that the selection contains insets of a type that have no natural conversion to math? Scott signature.asc Description: PGP signature
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
On Fri, Feb 23, 2018 at 10:21:19AM +, Uwe Stöhr wrote: > Am 23.02.2018 um 04:03 schrieb Scott Kostyshak: > > > Uwe, I included the same note that we did for 2.2.0, mentioning that if you > > installed a pre-release, you should uninstall those versions. Is this > > still the correct note? > > Yes, this is still correct. > My experience is that some users e.g. only tested beta1 but not an RC or RC1 > but not RC2. This caused often troubles. A reinstall is the clean solution > and only takes a minute -much less than writing an email when experiencing > troubles. Makes sense. Thanks for confirming. Scott signature.asc Description: PGP signature
Re: 2.3 new behaviour wrt external changes of .lyx file
Am Freitag, 23. Februar 2018 13:48:26 CET schrieb Pavel Sanda : > Hi, > > I see new behaviour when .lyx is externally modified while being loaded in > lyx. It is automatically flagged as modified no matter whether the file was > modified inside lyx before external modification. > > This typically happens when (r)syncing file between computers. I used to > know when sync happen and would close the file or reload it. > The new behaviour is somewhat confusing because I'm not capable to > distinguish whether I mistakenly edited the file meanwhile (and really need > to pay attention) or whether no change was actualy done and just external > change happened. > > I propose that we drop the '*' modification flag and let only the warning > about external modification. That way one can easily see whether there is > merge problem because file got edited meanwhile or just reload is enough. > > Opinions? > > Pavel +1 Kornel
Re: [LyX/2.3.x] README.localization: layouttranslations1 on Linux
Kornel Benko wrote: > > There are corner cases which I do not understand either and I always > > thought that is has smt to do with the unusual .in.in -> .in > > makefile cascade. But this particular case does not seem mysterious > > to me. Clean tree does not have lyx.pot and makefile wants to have it. > > That does still not explain the recreation of .po files. I thought it was conscious decision to have automatic recreation when you get new tree so .po files are in sync... Anyway I'm not the one who coded it, so who knows :) I got so used to it that I remerge strings by rm lyx.pot && make ;) Pavel
2.3 new behaviour wrt external changes of .lyx file
Hi, I see new behaviour when .lyx is externally modified while being loaded in lyx. It is automatically flagged as modified no matter whether the file was modified inside lyx before external modification. This typically happens when (r)syncing file between computers. I used to know when sync happen and would close the file or reload it. The new behaviour is somewhat confusing because I'm not capable to distinguish whether I mistakenly edited the file meanwhile (and really need to pay attention) or whether no change was actualy done and just external change happened. I propose that we drop the '*' modification flag and let only the warning about external modification. That way one can easily see whether there is merge problem because file got edited meanwhile or just reload is enough. Opinions? Pavel
Re: [LyX/2.3.x] README.localization: layouttranslations1 on Linux
Le 23/02/2018 à 12:00, Kornel Benko a écrit : That does still not explain the recreation of .po files. Cmake build creates everything in the build-tree only. Only if desired (e.g. with targets 'layouttranslation1' or 'update-gmo') also the source tree is affected. And here only the really changed files. Agreed. I'd like to get rid of this horrible Makefile and write my own, but I always have more interesting things to do. JMarc
Re: [LyX/2.3.x] README.localization: layouttranslations1 on Linux
Am Freitag, 23. Februar 2018 11:24:17 CET schrieb Pavel Sanda : > Jean-Marc Lasgouttes wrote: > > There is something mysterious and really annoying in the reasons why > > autotools decide that po/gmo files should be rebuilt. Sometimes it does > > not > > make sense. > > > > Do you have hints? > > There are corner cases which I do not understand either and I always > thought that is has smt to do with the unusual .in.in -> .in > makefile cascade. But this particular case does not seem mysterious > to me. Clean tree does not have lyx.pot and makefile wants to have it. > > Pavel That does still not explain the recreation of .po files. Cmake build creates everything in the build-tree only. Only if desired (e.g. with targets 'layouttranslation1' or 'update-gmo') also the source tree is affected. And here only the really changed files. Kornel
Re: [LyX/2.3.x] README.localization: layouttranslations1 on Linux
Jean-Marc Lasgouttes wrote: > There is something mysterious and really annoying in the reasons why > autotools decide that po/gmo files should be rebuilt. Sometimes it does not > make sense. > > Do you have hints? There are corner cases which I do not understand either and I always thought that is has smt to do with the unusual .in.in -> .in makefile cascade. But this particular case does not seem mysterious to me. Clean tree does not have lyx.pot and makefile wants to have it. Pavel
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
Am 23.02.2018 um 04:03 schrieb Scott Kostyshak: Uwe, I included the same note that we did for 2.2.0, mentioning that if you installed a pre-release, you should uninstall those versions. Is this still the correct note? Yes, this is still correct. My experience is that some users e.g. only tested beta1 but not an RC or RC1 but not RC2. This caused often troubles. A reinstall is the clean solution and only takes a minute -much less than writing an email when experiencing troubles. regards Uwe
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
Scott Kostyshak wrote: > > -The 2.3 series has a rich set of new features compared to the current > > stable > > -series. An overview of the new features can be found here: > > +With this release, LyX celebrates 22 years of existence. The 2.3 series > > How many years of existence are we celebrating? According to this Aren't we supposed to celebrate rounded years or something like that? But quite frankly, who cares :) > Pavel, you added a space in-between a URL and a period at ca7aae8d, but you > did > not add a space for the others. Should we add a space for the others as well? I tested only with firefox. It does well if "." is just behind domain name, it breaks if you made it part of filename, which makes sense. Pavel
Re: [LyX/2.3.x] README.localization: layouttranslations1 on Linux
Le 23/02/2018 à 10:39, Pavel Sanda a écrit : Scott Kostyshak wrote: Yes, it is from a clean tree. That's why :) There is something mysterious and really annoying in the reasons why autotools decide that po/gmo files should be rebuilt. Sometimes it does not make sense. Do you have hints? JMarc
Re: Applying LFUN_MATH_MODE to big help docs causes memory problems
Le 12/01/2018 à 23:28, Scott Kostyshak a écrit : I don't imagine any user actually does this, but if I select all and do ctrl+m, LyX often has problems (e.g. my RAM goes from 1GB to my max of 8GB). I've found this with Embedded Objects and with User Guide. Yes, I can imagine that the result is pretty bad. If I do the above with LyX 2.1.0, there are no memory problems. Instead, LyX just replaces everything with "\invalidmathmacro". I would say that it is just by chance, maybe because there is some \newcommand in the text. I'm not sure what the desired behavior is. Perhaps if the selection contains insets of a certain type (e.g. a float), the LFUN should just abort with a relevant message in the message pain. Any other ideas on what the desired behavior is? What refusing to do something if the selection is longer than, say, 50 paragraphs? We could count characters too, of course, but do we want to transform a full document to a docstring just to be able to decide that it is too long? JMarc
Re: [LyX/2.3.x] README.localization: layouttranslations1 on Linux
Scott Kostyshak wrote: > Yes, it is from a clean tree. That's why :) Pavel
Re: integral upper limit adjacent to integral sign
Le 15/02/2018 à 16:54, Pavel Sanda a écrit : Jean-Marc Lasgouttes wrote: Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes a écrit : I can try to prepare that. What character you want me to paste there? I can't take 'f' from esint, there is no 'f' included. Pavel The integral at position 1. And glyph number 4, I think. Try this one: 195.113.26.193/~sanda/junk/DejaVuSerif-Italic.ttf At f position you have esint glyph 1, at 'g' position you have glyph 4. Pavel I tried to see what to do with it, but this is beyond the time I am ready to spend on this issue :) The learning curve is a bit too steep for the reward. JMarc
Re: [LyX/2.3.x] Update ANNOUNCE for 2.3.0
On Friday, 23 February 2018 03.34.52 WET Joel Kulesza wrote: > Minor wording question here and on the website: is "down" potentially > confusing for a non-native English speaker? Would "unavailable" be more > clear? In the case of (European) Portuguese the equivalent of down is the word that we use for those cases so it is not confusing. :-) OTHO I agree that "unavailable" is more correct since the problems come because the server is unavailable even if it is not down (e.g. a problem with the local network, ...). Now personally I understand the idea of down in a physical sense, when we shutdown a server the fans stop and it really seems as if a plane just landed. ;-) PS: Sorry for wasting everyone a few seconds reading this message. :-) Regards, -- José Abílio
Re: Running ctests on 2.3.x branch
Am Donnerstag, 22. Februar 2018 18:49:42 CET schrieb Scott Kostyshak : > On Thu, Feb 22, 2018 at 10:13:17PM +, Kornel Benko wrote: > > Which one? Free* does not work here. And Scott uses TL2016. > > It works for me also on my system with TL 2017 (but it is not > up-to-date). I will update that TL 2017 at some point after 2.3.0 is > o > Scott Found it. I had __old__ (from 2007) ivritex installed in texmf-local. Removing all traces of ivritex there made the use of OmegaHebrew in TL17 working. Kornel
