Re: Beta1 is slow on undo

2017-10-16 Thread Jürgen Spitzmüller 
Am Montag, den 16.10.2017, 14:58 -0400 schrieb Richard Heck:
> Without profiling, it would be hard to know for sure, but I'd guess
> it
> was worth it. Certainly
> re-reading huge files over a high-latency connection could slow
> things down.

By subjective measure, it is noticeable with several insets that
include the same (big) BibTeX file.

Jürgen

> 
> Richard
> 
> 

signature.asc
Description: This is a digitally signed message part

Re: LyX very slow to end (master)

2017-10-16 Thread Scott Kostyshak 
On Mon, Oct 16, 2017 at 03:07:28PM +, Jean-Marc Lasgouttes wrote:
> Le 16/10/2017 à 16:08, Pavel Sanda a écrit :
> > Just trying dirty patch for caching settings inside GuiToolbar::saveSession
> > instead of creating new local var for each fun entry shows that I get quit
> > time around 1s.
> > Quick check shows that most of remaining time is spent in DialogPtr 
> > saveSession
> > loop again in saveUISettings; likely the same issue.
> > 
> > The cache idea might need some refinement because I do not know what all
> > entry points to saveSession() are and if having single instance throughout
> > the whole session is correct or needs refresh. I won't have time to 
> > investigate
> > more ATM.
> 
> Good catch. A solution is porbably to instantiate a QSettings in
> saveUISettings and pass it as parameter of the various saveSession()
> methods.

I wonoder if this is related to #9734. Enrico noted there [1] that with
Qt 5.5.0, LyX is slower to quit.

Scott


[1] http://www.lyx.org/trac/ticket/9734#comment:5


signature.asc
Description: PGP signature

Re: Windows: bring window to front

2017-10-16 Thread Scott Kostyshak 
On Mon, Oct 16, 2017 at 01:09:34PM +, racoon wrote:
> Hi,
> 
> Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? If
> so, it seems not to work. If not, maybe it can make it to rc1?

The patch is in beta1. If the feature doesn't work, then that means the
fix didn't work for you.

Scott


signature.asc
Description: PGP signature

Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #435

2017-10-16 Thread ci-lyx 
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/435/--
[...truncated 172 lines...]
-- Looking for _getpid - not found
-- Looking for gettext
-- Looking for gettext - found
-- Looking for getuid
-- Looking for getuid - found
-- Looking for lstat
-- Looking for lstat - found
-- Looking for lockf
-- Looking for lockf - found
-- Looking for mempcpy
-- Looking for mempcpy - found
-- Looking for mkdir
-- Looking for mkdir - found
-- Looking for _mkdir
-- Looking for _mkdir - not found
-- Looking for mkfifo
-- Looking for mkfifo - found
-- Looking for open
-- Looking for open - found
-- Looking for _open
-- Looking for _open - not found
-- Looking for pclose
-- Looking for pclose - found
-- Looking for _pclose
-- Looking for _pclose - not found
-- Looking for popen
-- Looking for popen - found
-- Looking for _popen
-- Looking for _popen - not found
-- Looking for putenv
-- Looking for putenv - found
-- Looking for readlink
-- Looking for readlink - found
-- Looking for setenv
-- Looking for setenv - found
-- Looking for setlocale
-- Looking for setlocale - found
-- Looking for strcasecmp
-- Looking for strcasecmp - found
-- Looking for stpcpy
-- Looking for stpcpy - found
-- Looking for strdup
-- Looking for strdup - found
-- Looking for strerror
-- Looking for strerror - found
-- Looking for strtoul
-- Looking for strtoul - found
-- Looking for tsearch
-- Looking for tsearch - found
-- Looking for unsetenv
-- Looking for unsetenv - found
-- Looking for wcslen
-- Looking for wcslen - found
-- Looking for alloca
-- Looking for alloca - not found
-- Looking for asprintf
-- Looking for asprintf - not found
-- Looking for wprintf
-- Looking for wprintf - not found
-- Looking for snprintf
-- Looking for snprintf - found
-- Looking for printf
-- Looking for printf - found
-- Looking for pid_t
-- Looking for pid_t - not found
-- Looking for intmax_t
-- Looking for intmax_t - not found
-- Looking for uintmax_t
-- Looking for uintmax_t - not found
-- Looking for LC_MESSAGES
-- Looking for LC_MESSAGES - found
-- Looking for PATH_MAX
-- Looking for PATH_MAX - found
-- Check size of intmax_t
-- Check size of intmax_t - done
-- Check size of long double
-- Check size of long double - done
-- Check size of long long
-- Check size of long long - done
-- Check size of wchar_t
-- Check size of wchar_t - done
-- Check size of wint_t
-- Check size of wint_t - failed
-- Performing Test HAVE_ICONV_CONST
-- Performing Test HAVE_ICONV_CONST - Failed
-- Performing Test SIZEOF_WCHAR_T_IS_2
-- Performing Test SIZEOF_WCHAR_T_IS_2 - Failed
-- Performing Test SIZEOF_WCHAR_T_IS_4
-- Performing Test SIZEOF_WCHAR_T_IS_4 - Success
-- Performing Test SIZEOF_LONG_LONG_GREATER_THAN_SIZEOF_LONG
-- Performing Test SIZEOF_LONG_LONG_GREATER_THAN_SIZEOF_LONG - Failed
-- Performing Test LYX_CALLSTACK_PRINTING
-- Performing Test LYX_CALLSTACK_PRINTING - Success
-- Performing Test lyx_cv_lib_stdcxx
-- Performing Test lyx_cv_lib_stdcxx - Success
-- Performing Test USE_GLIBCXX_CXX11_ABI
-- Performing Test USE_GLIBCXX_CXX11_ABI - Success
-- Performing Test lyx_cv_prog_clang
-- Performing Test lyx_cv_prog_clang - Failed
-- Performing Test HAVE_DEF_MAKE_UNIQUE
-- Performing Test HAVE_DEF_MAKE_UNIQUE - Success
-- Performing Test LYX_USE_STD_CALL_ONCE
-- Performing Test LYX_USE_STD_CALL_ONCE - Success
-- Looking for C++ include QtGui/qtgui-config.h
-- Looking for C++ include QtGui/qtgui-config.h - not found
-- Performing Test QT_USES_X11
-- Performing Test QT_USES_X11 - Success
-- Looking for XOpenDisplay in 
/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
-- Looking for XOpenDisplay in 
/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- doxygen not found, ==> no doxygen creation
-- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE) 
-- Missing Libraries or programs to create xvkbd: 
pcregrep;wmctrl;Xaw7;Xmu;Xt;XTest
-- cmake build is therefore omitting keytests
-- Missing xvkbd, omitting keytests
-- 
-- Build params, switch LYX_* options by -DLYX_*=ON or OFF, LYX_* combos by 
-DLYX_*=value:
-- 
-- LYX_CPACK= ON : Use the CPack management (Implies 
LYX_INSTALL option)
-- LYX_LOCALVERSIONING  = OFF: Add version info to created package name 
(only used if LYX_CPACK option set)
-- LYX_INSTALL  = ON : Build install projects/rules (implies a 
bunch of other options)
-- LYX_NLS  = ON : Enable Native Language Support (NLS)
-- LYX_REQUIRE_SPELLCHECK   = OFF: Abort if no spellchecker available
-- LYX_ASPELL   = OFF: Require aspell
-- LYX_ENCHANT  = OFF: Require Enchant
--

Re: compilation of LyX 2.3 fails with Python 3.6.2

2017-10-16 Thread Uwe Stöhr 

El 16.10.2017 a las 23:38, Kornel Benko escribió:


This leads to following output for e.g. Additional.lyx
b'#LyX 2.3 created this file. For more info see http://www.lyx.org/'


Hmm, but why do we need to modify the doc files? I mean why can't we 
just use them as they are and omit ReplaceValues.py with Python 3?



When playing ping pong like

testa = SubstituteDataInLine(line[:-1]).encode("utf-8")
testb = testa.decode("utf-8")
sys.stdout.write(testb)

I get
UnicodeEncodeError: 'charmap' codec can't encode character '\u014d'

so the SubstituteDataInLine routine does actually not only replace but 
changes the encoding.


I don't have ideas.

regards Uwe

Re: compilation of LyX 2.3 fails with Python 3.6.2

2017-10-16 Thread Kornel Benko 
Am Montag, 16. Oktober 2017 um 23:28:13, schrieb Uwe Stöhr 
> El 16.10.2017 a las 11:17, Kornel Benko escribió:
> 
> > Please replace the print statement
> > print(SubstituteDataInLine(line[:-1]))
> > with
> > sys.stdout.write(SubstituteDataInLine(line[:-1])+'\n')
> 
> This lead to
> "python UnicodeEncodeError: 'charmap' codec can't encode character"
> 
> However, I found now the solution, see attached. I just put it into master.
> 
> Please give it a +1 for 2.3.x if you agree.
> 
> many thanks for all your help and best regards
> Uwe

This leads to following output for e.g. Additional.lyx
b'#LyX 2.3 created this file. For more info see http://www.lyx.org/'
b'\\lyxformat 544'
b'\\begin_document'
b'\\begin_header'
b'\\save_transient_properties true'
b'\\origin /systemlyxdir/doc/'
b'\\textclass scrbook'
b'\\begin_preamble'

and so on. This is with python 3.4.3, so sorry, no +1.

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: compilation of LyX 2.3 fails with Python 3.6.2

2017-10-16 Thread Uwe Stöhr 

El 16.10.2017 a las 11:17, Kornel Benko escribió:


Please replace the print statement
print(SubstituteDataInLine(line[:-1]))
with
sys.stdout.write(SubstituteDataInLine(line[:-1])+'\n')


This lead to
"python UnicodeEncodeError: 'charmap' codec can't encode character"

However, I found now the solution, see attached. I just put it into master.

Please give it a +1 for 2.3.x if you agree.

many thanks for all your help and best regards
Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\ReplaceValues-cd5e2d5.001.py"
 "b/D:\\LyXGit\\2.3.x\\development\\cmake\\doc\\ReplaceValues.py"
index f07ce80bc9..41ed6e212c 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\ReplaceValues-cd5e2d5.001.py"
+++ "b/D:\\LyXGit\\2.3.x\\development\\cmake\\doc\\ReplaceValues.py"
@@ -13,6 +13,7 @@ from __future__ import print_function
 
 import sys
 import re
+import codecs
 
 Subst = {}  # map of desired substitutions
 prog = re.compile("")
@@ -33,8 +34,8 @@ def SubstituteDataInLine(line):
 
 
 def SubstituteDataInFile(InFile):
-for line in open(InFile):
-print(SubstituteDataInLine(line[:-1]))
+for line in codecs.open(InFile, 'r', 'utf-8'):
+print(SubstituteDataInLine(line[:-1]).encode("utf-8"))
 
 ##

Re: Beta1 is slow on undo

2017-10-16 Thread Richard Heck 
On 10/16/2017 02:04 AM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 15.10.2017, 18:41 -0400 schrieb Richard Heck:
>> No, it comes whenever a document contains a BibTeX inset. A better
>> patch
>> would make it happen
>> only when a BibTeX inset was involved. Then the delay is no surprise:
>> Of
>> course we have to reread
>> the files.
> The attached patch does not address this very bug, but I have noted
> that we unnecessarily read bibtex files multiple time (e.g. with
> multiple bibtex insets in master/child constellations or with
> subdivided bibliographies/chapterbib).
>
> The attached patch assures each file is only parsed once within a
> single collectBibkey() process. It will slightly speed up the process
> in some circumstances.
>
> Is it worth it?

Without profiling, it would be hard to know for sure, but I'd guess it
was worth it. Certainly
re-reading huge files over a high-latency connection could slow things down.

Richard

Re: LyX very slow to end (master)

2017-10-16 Thread Jean-Marc Lasgouttes 

Le 16/10/2017 à 16:08, Pavel Sanda a écrit :

Just trying dirty patch for caching settings inside GuiToolbar::saveSession
instead of creating new local var for each fun entry shows that I get quit
time around 1s.
Quick check shows that most of remaining time is spent in DialogPtr saveSession
loop again in saveUISettings; likely the same issue.

The cache idea might need some refinement because I do not know what all
entry points to saveSession() are and if having single instance throughout
the whole session is correct or needs refresh. I won't have time to investigate
more ATM.


Good catch. A solution is porbably to instantiate a QSettings in 
saveUISettings and pass it as parameter of the various saveSession() 
methods.


JMarc

Re: Update on the 2.3.0rc1 situation

2017-10-16 Thread Guenter Milde 
On 2017-10-14, Scott Kostyshak wrote:
> On Mon, Oct 09, 2017 at 11:56:12AM +, Guenter Milde wrote:

>> The current default behaviour for dash export is a regression on
>> changeset 798ad9755a1ff43a06d2b from 16.06.2007

...

> Note that from what I understand, this is a different topic than the one
> that was voted on [1], which focused on possible conversion options, not
> on the default of the setting.

> As for the potential patch to RELEASE-NOTES, do I understand correctly
> that the reason that the text we currently have is incorrect is because
> in some cases (e.g. the document uses non-TeX fonts) the change is not
> "needed"? 

The intention is to warn users about the consequences of the changed dash
export. The change also affects new documents: the new default allows
undesired line-breaks (e.g. in range indications like "1975–78" or after
the "opening" dash around French and Spanish incisions) that are
prevented in 2.2 documents.

I agree that mentioning the different handling of TeX- vs. no-TeX fonts
in the caveats section distracts from the intention and propose a
revised patch (see below).

Thanks,

Günter


diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES
index c605cb4850..abc1002ca2 100644
--- a/lib/RELEASE-NOTES
+++ b/lib/RELEASE-NOTES
@@ -212,10 +212,12 @@
   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 behaviour.
+* By default, LyX 2.3 forces output of all en and em dashes as -- and ---
+  when exporting to LaTeX. This can lead to incorrect line breaks, wrong
+  characters in typewriter fonts, and problems with some LaTeX packages.
+  Unselect "Document->Settings->Fonts->Output em- and en-dash as ligatures"
+  to ensure unchanged behaviour. See chapter 3.9.1.1 "Dashes and line
+  breaks" of the User Guide for details.
 
 * ZWSP characters (u200b) following literal em- and en-dashes are deleted by
   lyx2lyx when converting to 2.3 format. If you used them as optional line

Equation tracked changes and slight paint issues

2017-10-16 Thread racoon 

Hi

Open the attached file.

First, it seems that the underline for tracked inserts on display 
equations is at the correct position now. However, the hook that marks 
the end of a paragraph did not move with it.


Second, to the slight paint issues:

- Select the z below the display equation.

Now, part of the hook disappears. I guess this would be fixed by moving 
the hook to the right bottom corner as suggested above.


- Press and hold behind the z and move up slightly with the mouse cursor 
without selecting anything.


Now, not only disappears part of the hook but also the underline.

Best,
Daniel





tracked changes paint issue.lyx
Description: application/lyx

Re: LyX very slow to end (master)

2017-10-16 Thread Pavel Sanda 
Pavel Sanda wrote:
> Single instance of QSettings in pimp might help this.

Just trying dirty patch for caching settings inside GuiToolbar::saveSession
instead of creating new local var for each fun entry shows that I get quit
time around 1s.
Quick check shows that most of remaining time is spent in DialogPtr saveSession
loop again in saveUISettings; likely the same issue.

The cache idea might need some refinement because I do not know what all
entry points to saveSession() are and if having single instance throughout
the whole session is correct or needs refresh. I won't have time to investigate
more ATM.

Pavel
diff --git a/src/frontends/qt4/GuiToolbar.cpp b/src/frontends/qt4/GuiToolbar.cpp
index d519548e07..50953576a8 100644
--- a/src/frontends/qt4/GuiToolbar.cpp
+++ b/src/frontends/qt4/GuiToolbar.cpp
@@ -350,12 +350,15 @@ QString GuiToolbar::sessionKey() const
return "views/" + QString::number(owner_.id()) + "/" + objectName();
 }
 
+QSettings *exitsettings=0;
 
 void GuiToolbar::saveSession() const
 {
-   QSettings settings;
-   settings.setValue(sessionKey() + "/visibility", visibility_);
-   settings.setValue(sessionKey() + "/movability", isMovable());
+   if (!exitsettings)
+   exitsettings=new QSettings;
+
+   exitsettings->setValue(sessionKey() + "/visibility", visibility_);
+   exitsettings->setValue(sessionKey() + "/movability", isMovable());
 }

Re: LyX very slow to end (master)

2017-10-16 Thread Pavel Sanda 
Pavel Sanda wrote:
> with current master I have to wait ~3s before the window

And the winner for almost all of 3s goes to saveUISettings
and its ToolbarMap saveSession loop.

Each GuiToolbar::saveSession() takes ~80ms, guess what happens
when we call it 40x...

This is qt5 so it might be that lyx 2.0 speed goes to qt4
qsettings implementation...

When I launch strace on lyx binary I see gazilion of ERR
access to various /home & /etc & ../xgd/ guesses where
LyX.conf actually is, so most likely each QSettings init
triggers repeated file search for LyX.conf, that's where
we get high IO and 80ms per query.
Single instance of QSettings in pimp might help this.

Another funny observation, I see we(qt?) stat /etc/localtime
about 60x times each sec when LyX just idles with no document
open.

Pavel

Re: LyX very slow to end (master)

2017-10-16 Thread Jean-Marc Lasgouttes 

Le 16/10/2017 à 14:49, Pavel Sanda a écrit :

Hi,

when I quit lyx 2.0 the app terminates instantaneously,
with current master I have to wait ~3s before the window
disappears (emarasingly slower than launching it - 0.5s).

The time is spent on I/O, not cpu. Anyone can confirm?


Qt4 or Qt5? master only or 2.3 too?

JMarc

Windows: bring window to front

2017-10-16 Thread racoon 

Hi,

Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? 
If so, it seems not to work. If not, maybe it can make it to rc1?


Daniel

LyX very slow to end (master)

2017-10-16 Thread Pavel Sanda 
Hi,

when I quit lyx 2.0 the app terminates instantaneously,
with current master I have to wait ~3s before the window
disappears (emarasingly slower than launching it - 0.5s).

The time is spent on I/O, not cpu. Anyone can confirm?

Pavel

Re: LyX-Workarea: Background not shown correctly

2017-10-16 Thread Patrick De Visschere 

> On 16 Oct 2017, at 11:41, Jean-Marc Lasgouttes  wrote:
> 
> Le 13/10/2017 à 11:00, Patrick De Visschere a écrit :
>> But I see your point;
>> When I remove the line setting WA_OpaquePaintEvent the problem remains but 
>> (most of) the view turns white instead of black;
>> When I set WA_NoSystemBackground instead the problem remains the same.
>> When I insert viewport()->update(0,0,500,500) then everything outside this 
>> square remains untouched but the problem persists within that square.
> 
> Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground?

It doesn’t make a difference.

> 
> Does it make a difference to set them on GuiWorkarea too (additionally to the 
> viewport)?

No. I didn’t try all combinations but adding WA_OpaquePaintEvent and then also 
WA_NoSystemBackground does not make a difference.

pdv

> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: Archaeology: LyX c.2000

2017-10-16 Thread Pavel Sanda 
Andrew Parsloe wrote:
> its 'under the hood' machinery." Last updated, alas, in 2009. I wonder if 
> these links should be added?
>
> http://compsoc.man.ac.uk/~moz/www-user/news/archive.php3 (LyX Development 
> News archive, 2000/02/17 -- 2003/03/03)
>
> http://compsoc.man.ac.uk/~moz/www-user/news.php3 (LyX News 1999/02/01-- 
> 2002/12/03; the earliest ref. here is to the release of LyX 1.0)
>
> http://compsoc.man.ac.uk/~moz/www-user/about/lgt-1.0/lgt.html (A graphical 
> tour of LyX, 1999/02/02. It looks very different. The menu bar has three 
> items: File Options Help)

Linking does not make much sense, because they will be dead sooner or later,
but I can mirror the graphical tour.

The news stuff still lives somewhere in our archives I think.

Pavel

Re: LyX-Workarea: Background not shown correctly

2017-10-16 Thread Jean-Marc Lasgouttes 

Le 13/10/2017 à 11:00, Patrick De Visschere a écrit :

But I see your point;
When I remove the line setting WA_OpaquePaintEvent the problem remains but 
(most of) the view turns white instead of black;
When I set WA_NoSystemBackground instead the problem remains the same.
When I insert viewport()->update(0,0,500,500) then everything outside this 
square remains untouched but the problem persists within that square.


Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground?

Does it make a difference to set them on GuiWorkarea too (additionally 
to the viewport)?


JMarc

Re: LyX-Workarea: Background not shown correctly

2017-10-16 Thread Jean-Marc Lasgouttes 

Le 15/10/2017 à 10:30, Patrick De Visschere a écrit :

I’ve done some more debugging and I believe I’ve found the Qt code that turns 
the background black or white.
Om macos (and probably also on windows) Qt uses a QBackingStore for painting. I 
couldn’t find a QPlatformBackingStore for linux so I assume the implementation 
is different on linux, which would explain the different behaviour.

When issuing an viewport()->update() the region (the complete viewport if no 
smaller area is specified) is marked as dirty and at paint time is then repainted, 
via QWidgetBackingStore::doSync().
In QRasterBackingStore::beginPaint() the region is initially filled with a 
color Qt::transparent which has alpha=r=g=b=0 which will leave the screen black 
if not overwritten.


Very good finding Patrick! Where is the relevant code?

What I would like to know now is:
1. when is invalidation triggered? There are paint events that manage to 
update the existing screen, so invalidation has to depend on something else

2. can we avoid invalidation by setting some flag?
3. if we cannot avoid it, cn we predict that it happened and do a full 
screen repaint in this case?



When WA_OpaquePaintEvent is not set this is followed by a paintBackground() 
call which fills the region with the autoFillBrush-color which has all ones. 
This will leave the screen white if not overwritten.

Depending on the update_strategy_ only a part of the screen is overwritten by 
lyx, leaving the rest black or white.
I assume that in the tests I’ve described previously all actions restoring the 
normal view somehow trigger a FullScreenUpdate.


I agree with this analysis.

JMarc

Re: Bad Math Display Regression in 2.3.x

2017-10-16 Thread Jean-Marc Lasgouttes 

Le 13/10/2017 à 20:38, Richard Heck a écrit :

On 10/12/2017 04:08 PM, Jean-Marc Lasgouttes wrote:

Le 08/10/2017 à 08:56, Jean-Marc Lasgouttes a écrit :

The bisect is probably enough for me to find the bug (he said
confidently).


Here is a tentative patch that I will not be able to test and push
until Monday. I will be interesting by some feedback, though.


I don't really know this part of the code, so I can't really comment on
that. But I can confirm that the patch fixes the problem.


I pushed an updated version (only documentation) to master and properpaint.

JMarc

Re: compilation of LyX 2.3 fails with Python 3.6.2

2017-10-16 Thread Kornel Benko 
Am Montag, 16. Oktober 2017 um 01:43:48, schrieb Uwe Stöhr 
> El 15.10.2017 a las 23:07, Kornel Benko escribió:
> 
> > As I think I proposed in the attached part in other mail.
> > 
> > Essentially, there is the change of
> > open(file)
> > to
> > codecs.open(file, 'r', 'UTF-8')
> 
> Thanks Kornel,
> 
> unfortunately this does not work. Changing in ReplaceValues.py
> 
> for line in open(InFile)
> 
> into
> 
> for line in codecs.open(InFile, 'r', 'UTF-8'):
> 
> still gives me:
> 
>  File "C:\Program Files (x86)\Python35-32\lib\encodings\cp1252.py", 
> line 19, in encode return 
> codecs.charmap_encode(input,self.errors,encoding_table)[0]
>UnicodeEncodeError: 'charmap' codec can't encode character '\u014d' 
> in position 1: character maps to 
> 
> regards Uwe
> 

Ok, we are a step further. Input is now OK, but on output
(the following print statement) the conversion from UTF-8 to cp1252 makes 
problems.

Please replace the print statement
print(SubstituteDataInLine(line[:-1]))
with
sys.stdout.write(SubstituteDataInLine(line[:-1])+'\n')

Kornel

signature.asc
Description: This is a digitally signed message part.

Archaeology: LyX c.2000

2017-10-16 Thread Andrew Parsloe 
As a side-effect of something else I stumbled across these links to LyX 
1999--2003 including a graphical tour of LyX, 1999. Last year (I think) 
a binary for LyX 0.10.7 was found and Jean-Marc mentioned in relation to 
that the material at http://www.lyx.org/misc/archaeology/.  I read 
there, "Goal: provide a single repository for information about LyX's 
evolution, enabling the archaeologist to examine changes to both its 
visual appearance and to its 'under the hood' machinery." Last updated, 
alas, in 2009. I wonder if these links should be added?


http://compsoc.man.ac.uk/~moz/www-user/news/archive.php3 (LyX 
Development News archive, 2000/02/17 -- 2003/03/03)


http://compsoc.man.ac.uk/~moz/www-user/news.php3 (LyX News 1999/02/01-- 
2002/12/03; the earliest ref. here is to the release of LyX 1.0)


http://compsoc.man.ac.uk/~moz/www-user/about/lgt-1.0/lgt.html (A 
graphical tour of LyX, 1999/02/02. It looks very different. The menu bar 
has three items: File Options Help)


Andrew



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Fix How Buffers are Set After Undo/Redo

2017-10-16 Thread Jean-Marc Lasgouttes 

Le 16/10/2017 à 05:21, Richard Heck a écrit :

OK, this one is better. I'm not sure I understand why I need to reset
first this way, but it seems I do.


I am not sure what is the difference between the two patches, but it 
looks fine.


BTW, is ``setInsetBuffers'' really correct grammatically? Just asking.

JMarc

Re: Beta1 is slow on undo

2017-10-16 Thread Jürgen Spitzmüller 
Am Sonntag, den 15.10.2017, 18:41 -0400 schrieb Richard Heck:
> No, it comes whenever a document contains a BibTeX inset. A better
> patch
> would make it happen
> only when a BibTeX inset was involved. Then the delay is no surprise:
> Of
> course we have to reread
> the files.

The attached patch does not address this very bug, but I have noted
that we unnecessarily read bibtex files multiple time (e.g. with
multiple bibtex insets in master/child constellations or with
subdivided bibliographies/chapterbib).

The attached patch assures each file is only parsed once within a
single collectBibkey() process. It will slightly speed up the process
in some circumstances.

Is it worth it?

Jürgen

> 
> Richard
> diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 9c42b07e7f..8182893a1a 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2446,15 +2446,16 @@ void Buffer::reloadBibInfoCache() const
 		return;
 
 	d->bibinfo_.clear();
-	collectBibKeys();
+	FileNameList checkedFiles;
+	collectBibKeys(checkedFiles);
 	d->bibinfo_cache_valid_ = true;
 }
 
 
-void Buffer::collectBibKeys() const
+void Buffer::collectBibKeys(FileNameList & checkedFiles) const
 {
 	for (InsetIterator it = inset_iterator_begin(inset()); it; ++it)
-		it->collectBibKeys(it);
+		it->collectBibKeys(it, checkedFiles);
 }
 
 
diff --git a/src/Buffer.h b/src/Buffer.h
index 165f5d8795..35e7632973 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -17,6 +17,7 @@
 #include "support/unique_ptr.h"
 #include "support/strfwd.h"
 #include "support/types.h"
+#include "support/FileNameList.h"
 
 #include 
 #include 
@@ -520,7 +521,7 @@ public:
 	/// or just for it, if it isn't a child.
 	BiblioInfo const & masterBibInfo() const;
 	/// collect bibliography info from the various insets in this buffer.
-	void collectBibKeys() const;
+	void collectBibKeys(support::FileNameList &) const;
 	/// add some BiblioInfo to our cache
 	void addBiblioInfo(BiblioInfo const & bi) const;
 	/// add a single piece of bibliography info to our cache
diff --git a/src/insets/Inset.h b/src/insets/Inset.h
index f10ab3f883..ce17c8193a 100644
--- a/src/insets/Inset.h
+++ b/src/insets/Inset.h
@@ -23,6 +23,7 @@
 
 #include "support/strfwd.h"
 #include "support/types.h"
+#include "support/FileNameList.h"
 
 #include 
 
@@ -529,7 +530,7 @@ public:
 	  UpdateType /* utype*/,
 	  TocBackend & /* tocbackend */) const {}
 	/// Collect BibTeX information
-	virtual void collectBibKeys(InsetIterator const &) const {}
+	virtual void collectBibKeys(InsetIterator const &, support::FileNameList &) const {}
 	/// Update the counters of this inset and of its contents.
 	/// The boolean indicates whether we are preparing for output, e.g.,
 	/// of XHTML.
diff --git a/src/insets/InsetBibitem.cpp b/src/insets/InsetBibitem.cpp
index afc30ae37d..d5ebaf7640 100644
--- a/src/insets/InsetBibitem.cpp
+++ b/src/insets/InsetBibitem.cpp
@@ -285,7 +285,7 @@ docstring bibitemWidest(Buffer const & buffer, OutputParams const & runparams)
 }
 
 
-void InsetBibitem::collectBibKeys(InsetIterator const & it) const
+void InsetBibitem::collectBibKeys(InsetIterator const & it, FileNameList & /*checkedFiles*/) const
 {
 	docstring const key = getParam("key");
 	docstring const label = getParam("label");
diff --git a/src/insets/InsetBibitem.h b/src/insets/InsetBibitem.h
index 41497e1849..ba33732ad0 100644
--- a/src/insets/InsetBibitem.h
+++ b/src/insets/InsetBibitem.h
@@ -60,7 +60,7 @@ public:
 	///
 	docstring xhtml(XHTMLStream &, OutputParams const &) const;
 	///
-	void collectBibKeys(InsetIterator const &) const;
+	void collectBibKeys(InsetIterator const &, support::FileNameList &) const;
 	/// update the counter of this inset
 	void updateBuffer(ParIterator const &, UpdateType);
 	///@}
diff --git a/src/insets/InsetBibtex.cpp b/src/insets/InsetBibtex.cpp
index a905110773..30b169acb0 100644
--- a/src/insets/InsetBibtex.cpp
+++ b/src/insets/InsetBibtex.cpp
@@ -645,13 +645,13 @@ namespace {
 } // namespace
 
 
-void InsetBibtex::collectBibKeys(InsetIterator const & /*di*/) const
+void InsetBibtex::collectBibKeys(InsetIterator const & /*di*/, FileNameList & checkedFiles) const
 {
-	parseBibTeXFiles();
+	parseBibTeXFiles(checkedFiles);
 }
 
 
-void InsetBibtex::parseBibTeXFiles() const
+void InsetBibtex::parseBibTeXFiles(FileNameList & checkedFiles) const
 {
 	// This bibtex parser is a first step to parse bibtex files
 	// more precisely.
@@ -678,7 +678,14 @@ void InsetBibtex::parseBibTeXFiles() const
 	support::FileNamePairList::const_iterator it = files.begin();
 	support::FileNamePairList::const_iterator en = files.end();
 	for (; it != en; ++ it) {
-		ifdocstream ifs(it->second.toFilesystemEncoding().c_str(),
+		FileName const bibfile = it->second;
+		if (find(checkedFiles.begin(), checkedFiles.end(), bibfile) != checkedFiles.end())
+			// already checked this one. Skip.
+			continue;
+		else
+			// record that we check this.
+			checkedFiles.push_back(bibfile);
+		ifdocstream