Re: [patch] Do not recenter screen on spelling-continuously
On Tue, Nov 01, 2016 at 08:26:04PM +0100, Jean-Marc Lasgouttes wrote: > Looks good. It's in master at ad65f609. Scott signature.asc Description: PGP signature
Re: Different LaTeX output when exporting than when previewing
On Wed, Nov 02, 2016 at 09:43:05PM +0100, Jürgen Spitzmüller wrote: > I would like to investigate, but if we cannot reproduce, there is not > much we can do. OK, I don't have an idea either. Scott signature.asc Description: PGP signature
Re: [patch] Do not open or close branches after doc settings
On Wed, Nov 02, 2016 at 05:22:57PM -0700, Pavel Sanda wrote: > Shrug. Opening branch insets I'm activating seems pretty intuitive to me. > Pavel OK let's keep that behavior then, especially since it's been in LyX for a long time. Scott signature.asc Description: PGP signature
Re: [patch] Do not open or close branches after doc settings
Scott Kostyshak wrote: > On Mon, Oct 31, 2016 at 09:39:01PM -0700, Pavel Sanda wrote: > > Scott Kostyshak wrote: > > > Even if the intention is to only do it when the user > > > activates/deactivates a branch in the branches tab of document settings, > > > > that's the point. if you have many branches it can be annoying > > change all of that manually. > > I see. But shouldn't activating a branch and opening the insets be two > different operations? To me bundling them assumes a certain workflow > that I'm not convinced is that common. Shrug. Opening branch insets I'm activating seems pretty intuitive to me. Pavel
Re: lyx.org is down again
Joel Kulesza wrote: > http://www.lyx.org/images/about/aqua.png from http://www.lyx.org/Screenshots If you send me how the mac screen looks nowadays, I can upload it. If you would like to rework the walk through we will need to give you access. Pavel
Re: lyx.org is down again
On Wed, Nov 2, 2016 at 7:25 AM, Jean-Marc Lasgouttes wrote: > > If you are interested in updating this part of the wiki, we can give you > the necessary passwords :) Indeed everything is really out of date. The > graphical tour shows proudly LyX 1.3.0pre2! I might be interested... At the risk of raising the ire of traditionalists, as part of reworking some of the parts of the site that have aged less-than-gracefully, I'd be interested to learn more about the infrastructure behind LyX development and distribution to see if moving to more-centralized and/or remotely-hosted solutions make sense. For example, hosting lyx.org from a redirected github.io (or similar) that would hopefully mitigate some of the administrative overhead and improve stability/availability. I wouldn't act without consent/consensus from this list; however, I would like to investigate other options and potentially make a staging site that could be evaluated as a demo of what I have in mind. > But how does the script find the offending IPs? > Parsing log entries to look for certain signatures (sorry for the intentional vagueness).
Re: [patch] Do not open or close branches after doc settings
On Mon, Oct 31, 2016 at 09:39:01PM -0700, Pavel Sanda wrote: > Scott Kostyshak wrote: > > Even if the intention is to only do it when the user > > activates/deactivates a branch in the branches tab of document settings, > > that's the point. if you have many branches it can be annoying > change all of that manually. I see. But shouldn't activating a branch and opening the insets be two different operations? To me bundling them assumes a certain workflow that I'm not convinced is that common. Scott signature.asc Description: PGP signature
[patch] remove unsupported encoding l7xenc
The last days I reviewed the Wiki pages for special languages. This way I found out that there were many improvements in babel. There is no need to load special packages anymore for many languages. In the past we of course had to support these packages but now they make problems. For Lithuanian we once added the encoding l7xenc a.k.a. iso 8859-13 This encoding is not supported by inputenc. inputenc uses latin4 as encoding for Baltic languages and this works well together with babel-lithuanian, babel-latvian etc. the l7xenc encoding was a special one provided by the package littex ( a special package for Lithuanian): http://www.vtex.lt/tex/littex/index.html This package is not only unnecessary since TeXLive 2014 but also no longer under development for 8 years now. Therefore we could and should remove the encoding l7xenc from our list. The attached makes this. OK? regards Uwe p.s. If a user would insist to use littex he already knows a lot of LaTeX and can easily turn off the encoding in LyX and add an appropriate preamble line. development/FORMAT | 4 lib/encodings | 4 lib/lyx2lyx/lyx_2_3.py | 12 +++- src/version.h | 4 ++-- 4 files changed, 17 insertions(+), 7 deletions(-) diff --git a/development/FORMAT b/development/FORMAT index d098516..04fea01 100644 --- a/development/FORMAT +++ b/development/FORMAT @@ -11,6 +11,10 @@ adjustments are made to tex2lyx and bugs are fixed in lyx2lyx. --- +2016-11-02 Uwe Stöhr + * Format incremented to 516: remove the iso8859-13 encoding: + \inputencoding iso8859-13 + 2016-10-28 Uwe Stöhr * Format incremented to 515: support for Urdu and Syriac: \lang urdu diff --git a/lib/encodings b/lib/encodings index 75ae8f3..50cadbf 100644 --- a/lib/encodings +++ b/lib/encodings @@ -69,10 +69,6 @@ End Encoding iso8859-9 latin5 "Turkish (ISO 8859-9)" ISO-8859-9 fixed inputenc End -# Not standard, see http://www.vtex.lt/tex/littex/index.html -Encoding iso8859-13 l7xenc "Baltic (ISO 8859-13)" ISO-8859-13 fixed inputenc -End - Encoding iso8859-15 latin9 "Western European (ISO 8859-15)" ISO-8859-15 fixed inputenc End diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py index 65b5188..b25df75 100644 --- a/lib/lyx2lyx/lyx_2_3.py +++ b/lib/lyx2lyx/lyx_2_3.py @@ -483,6 +483,14 @@ def revert_syriac(document): "\\end_layout", ""] +def convert_ISO885913(document): +"Set the encoding to latin4" + +i = find_token(document.header, "\\inputencoding iso8859-13", 0) +if i != -1: + document.header[i] = "\\inputencoding iso8859-4" + + ## # Conversion hub # @@ -495,10 +503,12 @@ convert = [ [512, [convert_beamer_article_styles]], [513, []], [514, []], - [515, []] + [515, []], + [516, [convert_ISO885913]] ] revert = [ + [515, []], [514, [revert_urdu, revert_syriac]], [513, [revert_amharic, revert_asturian, revert_kannada, revert_khmer]], [512, [revert_bosnian, revert_friulan, revert_macedonian, revert_piedmontese, revert_romansh]], diff --git a/src/version.h b/src/version.h index 46c2ebc..2be4187 100644 --- a/src/version.h +++ b/src/version.h @@ -32,8 +32,8 @@ extern char const * const lyx_version_info; // Do not remove the comment below, so we get merge conflict in // independent branches. Instead add your own. -#define LYX_FORMAT_LYX 515 // uwestoehr: support for Urdu and Syriac -#define LYX_FORMAT_TEX2LYX 515 +#define LYX_FORMAT_LYX 516 // uwestoehr: remove ISO8859-13 +#define LYX_FORMAT_TEX2LYX 516 #if LYX_FORMAT_TEX2LYX != LYX_FORMAT_LYX #ifndef _MSC_VER
Re: Different LaTeX output when exporting than when previewing
Am Mittwoch, den 02.11.2016, 15:08 -0400 schrieb Scott Kostyshak: > Thanks for taking a look and the fix. I also always get an error now. > Do > you think we should be concerned about the other bug? That is, do you > think there's a chance that the bug was serious and we were lucky to > have a way to reproduce it, and now for whatever reason (e.g. memory > is > stored slightly differently) we can no longer reproduce it but it > could > still be there lurking in the shadows? I would like to investigate, but if we cannot reproduce, there is not much we can do. Jürgen signature.asc Description: This is a digitally signed message part
new warning in 2.2.x branch
Compiling today's branch I get: RowPainter.cpp D:\LyXGit\2.2.x\src\RowPainter.cpp(698): warning C4244: 'argument': conversion from 'double' to 'int', possible loss of data [D:\LyXGit\2.2.x\compile-2015\src\LyX.vcxproj] JMarc, this slipped in form a commit from you to master. Could you please have look? thanks and regards Uwe
Re: Different LaTeX output when exporting than when previewing
On Wed, Nov 02, 2016 at 06:15:57PM +0100, Jürgen Spitzmüller wrote: > Am Dienstag, den 01.11.2016, 17:42 +0100 schrieb Jürgen Spitzmüller: > > Am Dienstag, den 01.11.2016, 13:43 +0100 schrieb Jürgen Spitzmüller: > > > The second bug is that OutputParams::LUATEX does not use > > > polyglossia's > > > language varieties in the \setotherlanguage macro. This is what > > > causes > > > the LaTeX errors. > > > > I've solved this part of the puzzle. > > I have fixed this both in master and stable. Now I seem unable to > reproduce the other issue. That is, the export now always triggers an > error, as expected. Thanks for taking a look and the fix. I also always get an error now. Do you think we should be concerned about the other bug? That is, do you think there's a chance that the bug was serious and we were lucky to have a way to reproduce it, and now for whatever reason (e.g. memory is stored slightly differently) we can no longer reproduce it but it could still be there lurking in the shadows? Scott signature.asc Description: PGP signature
Re: Different LaTeX output when exporting than when previewing
Am Dienstag, den 01.11.2016, 17:42 +0100 schrieb Jürgen Spitzmüller: > Am Dienstag, den 01.11.2016, 13:43 +0100 schrieb Jürgen Spitzmüller: > > The second bug is that OutputParams::LUATEX does not use > > polyglossia's > > language varieties in the \setotherlanguage macro. This is what > > causes > > the LaTeX errors. > > I've solved this part of the puzzle. I have fixed this both in master and stable. Now I seem unable to reproduce the other issue. That is, the export now always triggers an error, as expected. Jürgen signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Fix usage of multiple varieties of the same polyglossia language.
On 11/02/2016 12:17 PM, Jürgen Spitzmüller wrote: > Am Mittwoch, den 02.11.2016, 17:14 +0100 schrieb Juergen Spitzmueller: >> commit 3374b8548b2807def95904d81746fd027e06ebf4 >> Author: Juergen Spitzmueller >> Date: Wed Nov 2 17:07:49 2016 +0100 >> >> Fix usage of multiple varieties of the same polyglossia language. >> >> 1. We must always output all (diverging) options, including >>default options; if not, default options might get >> overwritten. >> >> 2. Do not output options in \setotherlanguage, since we might >> have >>multiple "other languages" varieties from the same language >> (such >>as naustrian, nswissgerman). And the options are output for >> the >>language switches anyway. >> >> Hence, LaTeXFeatures::getPolyglossiaLanguages() does not have to >> record >> varieties. This was not done correctly anyway, since the map >> allowed >> for one entry per language only. > Richard, this should also go to stable. OK. rh
Re: [LyX/master] Fix usage of multiple varieties of the same polyglossia language.
Am Mittwoch, den 02.11.2016, 17:14 +0100 schrieb Juergen Spitzmueller: > commit 3374b8548b2807def95904d81746fd027e06ebf4 > Author: Juergen Spitzmueller > Date: Wed Nov 2 17:07:49 2016 +0100 > > Fix usage of multiple varieties of the same polyglossia language. > > 1. We must always output all (diverging) options, including > default options; if not, default options might get > overwritten. > > 2. Do not output options in \setotherlanguage, since we might > have > multiple "other languages" varieties from the same language > (such > as naustrian, nswissgerman). And the options are output for > the > language switches anyway. > > Hence, LaTeXFeatures::getPolyglossiaLanguages() does not have to > record > varieties. This was not done correctly anyway, since the map > allowed > for one entry per language only. Richard, this should also go to stable. Jürgen signature.asc Description: This is a digitally signed message part
Re: lyx.org is down again
Le 02/11/2016 à 14:07, Joel Kulesza a écrit : If you're spending time on infrastructure this weekend, perhaps some site updates could be included in your work? http://www.lyx.org/images/about/aqua.png from http://www.lyx.org/Screenshots ;-) If you are interested in updating this part of the wiki, we can give you the necessary passwords :) Indeed everything is really out of date. The graphical tour shows proudly LyX 1.3.0pre2! On a more serious note, with respect to the IPTables work, are unauthorized access attempts an issue that is consuming undue system resources? If so, I have a script I've used before that parses logs for offending IPs and then adds them to a drop rule. But how does the script find the offending IPs? If Richard manages to limit the number of concurrent connections and it proves not to be sufficient, then we will have to resort to other tricks. JMarc
Re: lyx.org is down again
On Tue, Nov 1, 2016 at 7:29 PM, Richard Heck wrote: > > I can probably figure this out, but it will be the weekend before I can > spend the time. Richard, If you're spending time on infrastructure this weekend, perhaps some site updates could be included in your work? http://www.lyx.org/images/about/aqua.png from http://www.lyx.org/Screenshots ;-) On a more serious note, with respect to the IPTables work, are unauthorized access attempts an issue that is consuming undue system resources? If so, I have a script I've used before that parses logs for offending IPs and then adds them to a drop rule. - Joel
Re: Assertion from Insert>Special Character
On 11/01/2016 09:56 PM, Andrew Parsloe wrote: I tried out Insert>Special Character>Symbols in response to an email to the list from Michael Berger and triggered an assertion. (LyX 2.2.2 on Windows 7) Recipe: in a new document Insert>Special Character>Symbols>Mathematical Alphanumeric Symbols Insert any symbol from this group Select the symbol, copy, paste You may need to repeat the last step. Sometimes the assertion is triggered at the first attempt to copy, sometimes after pasting and then selecting to copy the now two symbols. The assertion message references Paragraph.cpp, line 1723. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus Thanks Andrew, Scott I tried as you suggested but it does not work here (LyX 2.2.2 Linux, Mageia5, KDE, TL2016) Each new symbol produced with copy and paste or cut and paste returns its own new inputenc error like before. Michael