Re: Fix Problem With Background Export Cancellation

[Scott Kostyshak]

On Wed, Feb 21, 2018 at 03:28:50AM +, Scott Kostyshak wrote:
> On Wed, Feb 21, 2018 at 01:57:36AM +, Richard Heck wrote:
> > On 02/19/2018 11:30 PM, Scott Kostyshak wrote:
> > > On Tue, Feb 20, 2018 at 03:51:50AM +, Richard Heck wrote:
> > >> Please see attached patch.
> > > I will test this when I have time. Is there any known problem? The last
> > > time I tested, I just compiled the Embedded Objects manual and canceled
> > > it at various times (e.g. after 0.5 seconds, 1, second, 5 seconds).
> > > There were a lot of problems but this patch sounds like it addresses
> > > them.
> > 
> > The only problem I know if is the one mentioned: Failure actually to
> > abort the export, as opposed just to whatever part of it is happening at
> > the moment.
> 
> OK good to know.

Note that this patch is related to #7900.

The patch does still apply to current master.

I have the following comments:

1. The patch has whitespace at the end of lines in several places.

2. When testing on knitr.lyx, at some point I canceled the process, but the
PDF was still shown. This was shown in the message pane:

  support/Systemcall.cpp (417): Export Canceled!!
  support/Systemcall.cpp (294): Killed: pdflatex  "knitr.tex"
  23:03:35.426: Successful preview of format: PDF (pdflatex)

Perhaps the document was finished before it could be canceled? Should we
give that feedback?

3. At some point I received the following message:

  The running converter
   Rscript --verbose --no-save --no-restore $$s/scripts/lyxknitr.R 
"/tmp/lyx_tmpdir.LASJCzI14377/lyx_tmpbuf0/""knitr.Rnw" 
"/tmp/lyx_tmpdir.LASJCzI14377/lyx_tmpbuf0/""knitr.tex" ISO-8859-15 
"/home/scott/lyxbuilds/master/repo/lib/examples/"
  was killed by the user.

It might be slightly more readable if we inserted a couple of empty lines:

  The running converter

   Rscript --verbose --no-save --no-restore $$s/scripts/lyxknitr.R 
"/tmp/lyx_tmpdir.LASJCzI14377/lyx_tmpbuf0/""knitr.Rnw" 
"/tmp/lyx_tmpdir.LASJCzI14377/lyx_tmpbuf0/""knitr.tex" ISO-8859-15 
"/home/scott/lyxbuilds/master/repo/lib/examples/"

  was killed by the user.

Actually, perhaps instead of splitting "The running converter" and "was
killed", perhaps the following would be better:

  The following converter was killed by the user:

   Rscript --verbose --no-save --no-restore $$s/scripts/lyxknitr.R 
"/tmp/lyx_tmpdir.LASJCzI14377/lyx_tmpbuf0/""knitr.Rnw" 
"/tmp/lyx_tmpdir.LASJCzI14377/lyx_tmpbuf0/""knitr.tex" ISO-8859-15 
"/home/scott/lyxbuilds/master/repo/lib/examples/"

4. When testing with examples/spreadsheet.lyx, if I export and then
cancel, I get the following message:

  The running converter
  ssconvert --export-type=Gnumeric_html:latex 
"0_home_scott_lyxbuilds_master_repo_lib_examples_sheet1.gnumeric" 
"0_home_scott_lyxbuilds_master_repo_lib_examples_sheet1.tex"
  was killed by the user.

But then LyX continues the export without stopping.

Thanks for your work on this feature, Richard. I am looking forward to
it!

Scott


signature.asc
Description: PGP signature

Re: Opening single quotation marks, and biblatex

[Scott Kostyshak]

On Sun, Mar 18, 2018 at 02:53:22PM +, Jürgen Spitzmüller wrote:
> Am Sonntag, den 18.03.2018, 14:47 +0100 schrieb R H van der Gaag:

> > Also, I found that simply switching from natbib to biblatex or
> > biblatex (natbib style) doesn’t work out of the box. Parsing errors
> > abound.
> 
> Please provide an example file for those errors.

R H, can you provide an example file for what you mentioned above?

Thanks,

Scott


signature.asc
Description: PGP signature

Re: Applying LFUN_MATH_MODE to big help docs causes memory problems

[Scott Kostyshak]

On Fri, Feb 23, 2018 at 09:42:07AM +, Jean-Marc Lasgouttes wrote:

> 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?

Based on one of your emails in this thread, isn't converting to plain
text part of the process of converting to math? In which case, it is not
an extra step.

Scott


signature.asc
Description: PGP signature

Re: Fwd: Fwd: Re: Publication de LyX version 2.3.0rc1

[Scott Kostyshak]

On Mon, Jan 01, 2018 at 10:02:49AM +, Scott Kostyshak wrote:
> On Sun, Dec 31, 2017 at 10:25:34PM +, Emile Lunardon wrote:
> > -- Forwarded message --
> > From: Emile Lunardon 
> > Date: 2017-12-31 9:22 GMT+01:00
> > Subject: Re: Fwd: Re: Publication de LyX version 2.3.0rc1
> > To: Jean-Pierre Chrétien , LyX-Devel <
> > lyx-devel@lists.lyx.org>, "emile.lunardon" 
> > 
> > 
> > I have observed this wrong replacement behavior on LyX for Windows (bundle
> > install package).
> > I join a LyX file which shows the phenomena when I ask to replace the LaTeX
> > inset {} by the letter C.
> 
> Thanks for the test file, Emile. I cannot reproduce on Linux. I don't
> think this is too surprising considering it seems to be a regular
> expression engine issue.
> 
> I attach again the test file and am sending it to the lyx-devel list to
> see if anyone else can reproduce.

Emile, can you reproduce also with the 2.3.0 binary?

Best,

Scott


signature.asc
Description: PGP signature

Re: outline pane selection across files in tabs

[Scott Kostyshak]

On Sun, Dec 24, 2017 at 05:22:46PM +, john kennan wrote:
> When two files are open in tabs, with Tables selected in the outline pane
> in the first file, the selection doesn't hold after switching to the other
> file and back if the other file has no tables -- the selection reverts to
> Table of Contents. This seems undesirable (OSX, 2.3rc1).

I suggest filing a bug report on lyx.org/trac so we do not forget about
this. If you open a bug report, please give exact steps to reproduce.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: [PATCH] to avoid crash in misspelled marker painting while deleting table rows fast

[Scott Kostyshak]

On Thu, Dec 28, 2017 at 08:40:31AM +, Scott Kostyshak wrote:
> On Fri, Oct 27, 2017 at 10:52:02AM +, Jean-Marc Lasgouttes wrote:
> > Le 13/10/2017 à 07:24, Stephan Witt a écrit :
> > > > A question: is the 'quickly' important to get the crash? From what I 
> > > > see, Cursor::newWord() is not updated to the changes in the document 
> > > > structure. Why does this happen?
> > > 
> > > Sorry for the delay. I tried to reproduce and cannot anymore ATM. I had 
> > > the impression 'quickly‘ was important to get the crash. It didn’t happen 
> > > on the first or second deletion.
> > > 
> > > I don’t understand your statement regarding the change in document 
> > > structure and the following question.
> > 
> > Sorry, I failed to answer this. My remark is that you have to check whether
> > newword does point to a correct text and I thought it was because sometimes
> > it is not pointing to what it should. I wonder whether this is related to
> > the places where these things are computed.
> 
> Stephan can you reproduce the crash on recent 2.3.x?

I didn't follow the discussion. Is the patch not necessary then?

Scott


signature.asc
Description: PGP signature

Re: SVG figure wrong preview size

[racoon]

On 03.04.2018 17:57, racoon wrote:

Hi,

I still get some strange previews with SVG figure (external material), 
see "wrong size.png".


It looks like the svg content and the text are applied in different 
sizes. This happens with ps output but not with pdflatex, see "wrong 
size output with ps2pdf.png" and "right size with pdflatex.png", 
respectively.


I have also attached the svg if you want to try it yourself.


ps. It might look a bit different for you since I realized that I have 
an '--export-area-page' in my svg2pstex.py. However, even without it the 
preview and output with ps is way off.

SVG figure wrong preview size

[racoon]

Hi,

I still get some strange previews with SVG figure (external material), 
see "wrong size.png".


It looks like the svg content and the text are applied in different 
sizes. This happens with ps output but not with pdflatex, see "wrong 
size output with ps2pdf.png" and "right size with pdflatex.png", 
respectively.


I have also attached the svg if you want to try it yourself.

Best,
Daniel

Re: [LyX/master] Improve metrics of equations. More work remains to be done.

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
>>> Can you confirm that these go away when preview are disabled?
>> No, I get the assertion even with preview off.
>> I also found recipy to reproduce:
>> 1. open math manual, go to section 3.1
>> 2. enter with cursor the large math inset showing nested fractions with 
>> cfrac
>> 3. scroll down via mouse wheel so the inset gets out of the screen
>> 4. assertion
>
> The following patch should be OK then. If it is, I'll push it to master and 
> we'll figure out what to do from there.

Sweet, I can confirm that the crash is gone. Pavel

Re: [LyX/master] Upstreaming compilation patch needed for Gentoo.

[Scott Kostyshak]

On Tue, Apr 03, 2018 at 12:28:00PM +, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > Why does e.g. excluding  can cause a compilation error on
> > one system and not on others. Why don't I get a compilation error
> > without this patch?
> 
> I just forwarded the patch from downstream without seeing the problem myself 
> to
> give more info, but different qt versions can have slightly different
> dependency tree and I wouldn't be surprised that even different packaging
> options (like what exact qt module is installed on your system) could lead to
> slightly different headers,

I see. I was thinking it was a compilation flag that e.g. requires
direct dependencies to be stated explicitly, and not loaded by chance by
other dependencies.

> qt became such a monster nowadays...

True.

> Anyway, we do use QButtonGroup in that unit,

> so the patch is appropriate.

I didn't doubt it :)

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Improve metrics of equations. More work remains to be done.

[Jean-Marc Lasgouttes]

Le 21/03/2018 à 13:09, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Le 20/03/2018 ?? 17:39, Pavel Sanda a écrit :

Unf I also am getting assertion when navigating through complex fractions
and scrolling with mouse wheel at the same time.
Not sure whether your patch is involved.


Can you confirm that these go away when preview are disabled?


No, I get the assertion even with preview off.

I also found recipy to reproduce:
1. open math manual, go to section 3.1
2. enter with cursor the large math inset showing nested fractions with cfrac
3. scroll down via mouse wheel so the inset gets out of the screen
4. assertion


The following patch should be OK then. If it is, I'll push it to master 
and we'll figure out what to do from there.


JMarc


From 3d64ace4f2a301e14ca5cef8ee33f9343c9bcc8e Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Tue, 20 Mar 2018 16:41:59 +0100
Subject: [PATCH] Set current cursor font in MathData::metrics()

Also make sure that caret dimension in mathed is not larger than inset
height.

This makes size of the cursor closer to current font in mathed.
---
 src/BufferView.cpp  | 12 ++--
 src/mathed/MathData.cpp |  9 +
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 0e30cc7..dafcc9d 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -2965,8 +2965,16 @@ void BufferView::caretPosAndHeight(Point & p, int & h) const
 	Cursor const & cur = cursor();
 	Font const font = cur.real_current_font;
 	frontend::FontMetrics const & fm = theFontMetrics(font);
-	int const asc = fm.maxAscent();
-	int const des = fm.maxDescent();
+	int asc = fm.maxAscent();
+	int des = fm.maxDescent();
+	// If the cursor is in mathed and it has cached metrics, reduce
+	// the height to fit the inner cell (mathed cells are tight
+	// vertically).
+	if (cur.inMathed() && coordCache().getArrays().hasDim(&cur.cell())) {
+		Dimension const dim = cur.cell().dimension(*this);
+		asc = min(asc, dim.asc);
+		des = min(des, dim.des);
+	}
 	h = asc + des;
 	p = getPos(cur);
 	p.y_ -= asc;
diff --git a/src/mathed/MathData.cpp b/src/mathed/MathData.cpp
index d242a86..96aef29 100644
--- a/src/mathed/MathData.cpp
+++ b/src/mathed/MathData.cpp
@@ -261,6 +261,15 @@ bool isInside(DocIterator const & it, MathData const & ar,
 
 void MathData::metrics(MetricsInfo & mi, Dimension & dim) const
 {
+	// This is the only point where the drawing font is known.
+	// We set cursor current font so that the blinking caret height
+	// adapts to math font.
+	Cursor & cur = mi.base.bv->cursor();
+	if (cur.inMathed() && &cur.cell() == this) {
+		cur.current_font.fontInfo() = mi.base.font;
+		cur.real_current_font.fontInfo() = mi.base.font;
+	}
+
 	frontend::FontMetrics const & fm = theFontMetrics(mi.base.font);
 	dim = fm.dimension('I');
 	int xascent = fm.dimension('x').ascent();
-- 
2.7.4

Re: Bug 11101: Document with xfig figures fail with python3

[José Abílio Matos]

On Tuesday, 3 April 2018 12.55.20 WEST Helge Hafting wrote:
> Existing documents with xfig figures cannot be opened, because LyX then
> invokes /usr/share/lyx/scripts/fig_copy.py which python3 does not
> understand. In other words, backward compatibility seems broken.
> 
> On arch linux, "python" is now python3.  Python version 2 is available,
> but is called "python2".
> 
> I can work around this by creating a /usr/local/bin/python script that does:
> 
> exec python2 "$@"
> 
> This is a bit heavy-handed, as other sw may want python3.
> 
> 
> python2 has no problems with fig_copy.py, but LyX 2.3.0 does not seem to
> take advantage of python2.
> 
> 
> Helge Hafting

Here follows the complete patch after a cursory test. The difference now is 
that this patch 
should work for files that have a non utf-8 enconding if they are in different 
directories.

All the other cases, if the files were in the same directory or if the encoding 
was utf-8 (from 
which ascii is a subset), already should have worked with the previous patch.

Regards,
-- 
José Abílio
diff --git a/lib/scripts/fig_copy.py b/lib/scripts/fig_copy.py
index d5e0421668..a398c1dbf5 100644
--- a/lib/scripts/fig_copy.py
+++ b/lib/scripts/fig_copy.py
@@ -17,14 +17,15 @@
 # picture files that are stored as relative paths are replaced
 # with the absolute path.
 
+from __future__ import print_function
 import os, sys
 
 if len(sys.argv) != 3:
-print >> sys.stderr, "Usage: fig_copy.py  "
+print ("Usage: fig_copy.py  ", file=sys.stderr)
 sys.exit(1)
 
 if not os.path.isfile(sys.argv[1]):
-print >> sys.stderr, "Unable to read", sys.argv[1]
+print ("Unable to read", sys.argv[1], file=sys.stderr)
 sys.exit(1)
 
 from_dir = os.path.split(os.path.realpath(sys.argv[1]))[0]
@@ -45,14 +46,14 @@ import re
 # We're looking for a line of text that defines an entry of
 # type '2' (a polyline), subtype '5' (an external picture file).
 # The line has 14 other data fields.
-patternline = re.compile(r'^\s*2\s+5(\s+[0-9.+-]+){14}\s*$')
-emptyline   = re.compile(r'^\s*$')
-commentline = re.compile(r'^\s*#.*$')
+patternline = re.compile(br'^\s*2\s+5(\s+[0-9.+-]+){14}\s*$')
+emptyline   = re.compile(br'^\s*$')
+commentline = re.compile(br'^\s*#.*$')
 # we allow space in path name
-figureline  = re.compile(r'^(\s*[01]\s*)(\S[\S ]*)(\s*)$')
+figureline  = re.compile(br'^(\s*[01]\s*)(\S[\S ]*)(\s*)$')
 
-input = open(sys.argv[1], 'r')
-output = open(sys.argv[2], 'w')
+input = open(sys.argv[1], 'rb')
+output = open(sys.argv[2], 'wb')
 
 # path in the fig is relative to this path
 os.chdir(from_dir)
@@ -68,7 +69,7 @@ for line in input:
 found = False
 elif patternline.match(line):
 found = True
-print >> output, line,
+output.write(line)
 
 input.close()
 output.close()

Re: Bug 11101: Document with xfig figures fail with python3

[José Abílio Matos]

On Tuesday, 3 April 2018 13.28.55 WEST José Abílio Matos 
wrote:
> Could you test the attached patch?

There was a typo in the last patch...

-- 
José Abílio
diff --git a/lib/scripts/fig_copy.py b/lib/scripts/fig_copy.py
index d5e0421668..c6235195c2 100644
--- a/lib/scripts/fig_copy.py
+++ b/lib/scripts/fig_copy.py
@@ -17,14 +17,15 @@
 # picture files that are stored as relative paths are replaced
 # with the absolute path.
 
+from __future__ import print_function
 import os, sys
 
 if len(sys.argv) != 3:
-print >> sys.stderr, "Usage: fig_copy.py  "
+print ("Usage: fig_copy.py  ", file=sys.stderr)
 sys.exit(1)
 
 if not os.path.isfile(sys.argv[1]):
-print >> sys.stderr, "Unable to read", sys.argv[1]
+print ("Unable to read", sys.argv[1], file=sys.stderr)
 sys.exit(1)
 
 from_dir = os.path.split(os.path.realpath(sys.argv[1]))[0]
@@ -68,7 +69,7 @@ for line in input:
 found = False
 elif patternline.match(line):
 found = True
-print >> output, line,
+print (line, end="", file=output)
 
 input.close()
 output.close()

Re: Bug 11101: Document with xfig figures fail with python3

[José Abílio Matos]

On Tuesday, 3 April 2018 12.55.20 WEST Helge Hafting wrote:
> Existing documents with xfig figures cannot be opened, because LyX then
> invokes /usr/share/lyx/scripts/fig_copy.py which python3 does not
> understand. In other words, backward compatibility seems broken.
> 
> On arch linux, "python" is now python3.  Python version 2 is available,
> but is called "python2".
> 
> I can work around this by creating a /usr/local/bin/python script that does:
> 
> exec python2 "$@"
> 
> This is a bit heavy-handed, as other sw may want python3.
> 
> 
> python2 has no problems with fig_copy.py, but LyX 2.3.0 does not seem to
> take advantage of python2.
> 
> 
> Helge Hafting

That was on oversight from me. :-(

Could you test the attached patch?

I suspect that this should not be enough, basically the question is about the 
encoding of the fig 
files. I will test this and send later a more complete patch.

Regards,
-- 
José Abílio
--- fig_copy.py	(original)
+++ fig_copy.py	(refactored)
@@ -17,14 +17,15 @@
 # picture files that are stored as relative paths are replaced
 # with the absolute path.
 
+from __future__ import print_function
 import os, sys
 
 if len(sys.argv) != 3:
-print >> sys.stderr, "Usage: fig_copy.py  "
+print("Usage: fig_copy.py  ", file=sys.stderr)
 sys.exit(1)
 
 if not os.path.isfile(sys.argv[1]):
-print >> sys.stderr, "Unable to read", sys.argv[1]
+print("Unable to read", sys.argv[1], file=sys.stderr)
 sys.exit(1)
 
 from_dir = os.path.split(os.path.realpath(sys.argv[1]))[0]
@@ -68,7 +69,7 @@
 found = False
 elif patternline.match(line):
 found = True
-print >> output, line,
+print(line, end=' ', file=output)
 
 input.close()
 output.close()

Re: [LyX/master] Upstreaming compilation patch needed for Gentoo.

[Pavel Sanda]

Scott Kostyshak wrote:
> Why does e.g. excluding  can cause a compilation error on
> one system and not on others. Why don't I get a compilation error
> without this patch?

I just forwarded the patch from downstream without seeing the problem myself to
give more info, but different qt versions can have slightly different
dependency tree and I wouldn't be surprised that even different packaging
options (like what exact qt module is installed on your system) could lead to
slightly different headers, qt became such a monster nowadays...

Anyway, we do use QButtonGroup in that unit, so the patch is appropriate.

Pavel

Re: LyX 2.2.3 bug: File->Export->PDF fail to copy the pdf onto a sshfs mount

[Helge Hafting]

Den 31. jan. 2018 21:25, skrev Scott Kostyshak:

On Wed, Jan 31, 2018 at 01:39:31PM +, Helge Hafting wrote:

File->Export->PDF is supposed to create a PDF in a temp directory, and then
copy it to the right place.

For me, this fails when the working directory is on a sshfs mount. (It works
fine on a local filesystem)

This has worked for many years, but this week I see a mysterious failure:

Is it 100% reproducible? Did you update your LyX version this week?

It is 100% reproduceable. I now have LyX 2.3.0 (arch linux amd64), and 
the problem is exactly the same.


There is the possibility that my sshfs setup is somehow wrong, or that 
archlinux has changed their packages. But 'cp' has no problem. I have 
been using this server for many years, and I don't see other problems 
like this.


Helge Hafting

Bug 11101: Document with xfig figures fail with python3

[Helge Hafting]

Existing documents with xfig figures cannot be opened, because LyX then 
invokes /usr/share/lyx/scripts/fig_copy.py which python3 does not 
understand. In other words, backward compatibility seems broken.


On arch linux, "python" is now python3.  Python version 2 is available, 
but is called "python2".


I can work around this by creating a /usr/local/bin/python script that does:

exec python2 "$@"

This is a bit heavy-handed, as other sw may want python3.


python2 has no problems with fig_copy.py, but LyX 2.3.0 does not seem to 
take advantage of python2.



Helge Hafting

Re: LyX 2.2.3 bug: File->Export->PDF fail to copy the pdf onto a sshfs mount

[Helge Hafting]

This is now bug 11100, sorry for taking so long time to register it.
Helge Hafting

Rotten link in tutorial

[Pieter Dijkshoorn]

Dear LyX developers,

Because of compatibility issues between lyx 2.2.3 and 2.3.0 I tried
following this tutorial: https://wiki.lyx.org/Windows/Compilation. All went
well until I tried to dowload the file at
http://ftp.lyx.de/LyX-Windows-Deps/lyx-windows-deps-msvc2015.zip. The file
is not there anymore.

My problem was solved by going to http://ftp.lyx.de/
, and downloading the 2.3.0
installer for windows from there. According to the website
, "LyX 2.3.0 Windows binaries are not
available at this time".

Kind regards,
Pieter Dijkshoorn

Re: Tab stop width in Preamble

[racoon]

On 02.04.2018 21:31, Richard Kimberly Heck wrote:

On 04/02/2018 06:08 AM, racoon wrote:

On 27.03.2018 11:16, racoon wrote:

On 27.03.2018 11:11, racoon wrote:

Hi,

Could it be that the tab stop width in the preamble is 12 spaces
wide? That seems an awful lot to me. Is there a way to change it
something narrower, like 2 spaces?


The same applies to ERTs. They have a tab stop of 4 spaces. Can that
be changed to 2 spaces? (And maybe preamble and ERT tab stops should
be the same in general?)


I've found a couple of links concerning setting the tab stop width.
Maybe someone knows how to use them.


I've committed this to master and to 2.3.2-staging for the preamble, set
to four spaces, which seems to work pretty well. If you want to change
it elsewhere, have a look at b4d885ac for the code.


There is actually at least one more instance where a smaller tab stop 
might be good: the code preview.


Daniel

Re: Tab stop width in Preamble

[racoon]

On 02.04.2018 21:31, Richard Kimberly Heck wrote:

On 04/02/2018 06:08 AM, racoon wrote:

On 27.03.2018 11:16, racoon wrote:

On 27.03.2018 11:11, racoon wrote:

Hi,

Could it be that the tab stop width in the preamble is 12 spaces
wide? That seems an awful lot to me. Is there a way to change it
something narrower, like 2 spaces?


The same applies to ERTs. They have a tab stop of 4 spaces. Can that
be changed to 2 spaces? (And maybe preamble and ERT tab stops should
be the same in general?)


I've found a couple of links concerning setting the tab stop width.
Maybe someone knows how to use them.


I've committed this to master and to 2.3.2-staging for the preamble, set
to four spaces, which seems to work pretty well. If you want to change
it elsewhere, have a look at b4d885ac for the code.


Thanks!

Daniel