Re: [patch] Do not recenter screen on spelling-continuously

[Scott Kostyshak]

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

[Scott Kostyshak]

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

[Scott Kostyshak]

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

[Pavel Sanda]

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

[Pavel Sanda]

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

[Joel Kulesza]

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

[Scott Kostyshak]

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

[Uwe Stöhr]

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

[Jürgen Spitzmüller]

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

[Uwe Stöhr]

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

[Scott Kostyshak]

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

[Jürgen Spitzmüller]

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.

[Richard Heck]

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.

[Jürgen Spitzmüller]

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

[Jean-Marc Lasgouttes]

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

[Joel Kulesza]

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

[Michael Berger]

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