boost::shared_ptr

[Richard Kimberly Heck]

What do we use instead now? I'm trying to update an old patch of
Georg's for bug 7474, and it uses boost::shared_ptr.

Riki

Re: Update on 2.3.0 situation and Windows-specific issues

[Richard Kimberly Heck]

On 04/04/2018 10:47 PM, Scott Kostyshak wrote:
> On Wed, Apr 04, 2018 at 11:07:42PM +, Uwe Stöhr wrote:
>> I am sorry but I cannot understand not to release the Win installer just for
>> a dialog or not. Is this that important not to release our hard work over
>> months for LyX 2.3.0 for Windows users? Certainly not.
> In my opinion it is that important, because updating LyX could break
> something else on a user's computer. 

For people who did not follow the discussion on lyx-users, I'd like to
draw attention
to this message:
    https://marc.info/?l=lyx-users=152265353312871
To me, it makes it quite clear that the MikTeX update process is very
fragile, even at
the best of times---unsurprisingly, given how much is being updated. (It
reminds me of
what the Fedora update process used to be like.)

Riki

Re: Behavior of overset inset creation on selection

[Scott Kostyshak]

On Wed, Apr 04, 2018 at 04:36:26PM +, Jean-Marc Lasgouttes wrote:

> Comments welcome.

Tested and works well! I actually wasn't very hopeful that someone would
make a patch when I posted this issue. I am glad to be surprised.

Thank you for your work on it,

Scott


signature.asc
Description: PGP signature

Re: Update on 2.3.0 situation and Windows-specific issues

[Scott Kostyshak]

On Wed, Apr 04, 2018 at 11:07:42PM +, Uwe Stöhr wrote:
> Am 31.03.2018 um 19:37 schrieb Scott Kostyshak:
> 
> > I've included something along these lines in the newest proposal for a
> > dialog.
> 
> Dear Developers,
> 
> yes, I take it personally that you cannot trust me as Windows developer who
> has experiences with LyX under Windows for more than 10 years. I gave LyX
> lectures to students and did a lot to help users over years.
> 
> I invested much time to write the details for interested people in the LyX
> Wiki and our docs but not to molest average users. So what is your problem?
> That I hide info from users? No, I just decide where I give info. Or why do
> you think I created many different Wiki pages and expert LyX documentation
> files?

I think you did all of that work and spent all of that time because you
care a lot about LyX users.

> I am sorry but I cannot understand not to release the Win installer just for
> a dialog or not. Is this that important not to release our hard work over
> months for LyX 2.3.0 for Windows users? Certainly not.

In my opinion it is that important, because updating LyX could break
something else on a user's computer. As I discussed [1], I think the
consequences could be very bad for users affected by this, especially
average Windows users because it is hard for them to understand why
something that used to work (compilation of a document) no longer works,
and what the problem is, and how to fix it. The average Windows user
would have a lot of trouble with that, and imagine that they have to
deal with that when they face a deadline.

> The situation is with a car: the majority just use it. They press the ON
> button or turn a key to start the motor and drive to e.g. a supermarket.
> They are not interested how the motor start is internally done or even what
> is below the car hood. Their task is to drive to the market. But what you
> want is that everybody should know what is under the hood. Why? Why can't
> people just use things?

I think that analogies can be useful in making points, but only if they
fit correctly. In this analogy what is the part that is analogous to a
MiKTeX update breaking something?

> What I do with the installer, is providing a LyX that just works to be able
> to focus on your task to write the text you want or have to write.

I don't see how providing a dialog works against this goal.

> Please leave the expert point of view that users have to know background
> things. This is not how it works in the Windows world. Or does the
> LibreOffice Win installer bother you with background stuff? No, they don't
> bother users but give all expert info on their Wiki pages - so exactly as I
> do and did.

Did installing LibreOffice update something else? Again, I just don't
understand the analogy. If you agree that a MiKTeX update has a chance
of causing a problem, please represent that element in some way in your
comparisons. If you think that a MiKTeX update cannot cause problems,
then OK let's focus on that issue instead of mixing up other
issues.

> I am currently abroad (and will be the next 2 weeks) and cannot read all
> mails you forwarded to me.

OK.

> It is not very helpful to make a survey on a mailing list since, as I
> explained, most users don't know or use mailing lists. Those who write there
> have usually some background knowledge. But why does my installer not have a
> special dialog - because average users won't understand it because of lack
> of background knowledge.

I have found the feedback from lyx-users to be very helpful. We are
doing our best to come up with a message that is as clear as possible
without causing confusion. I have learned a lot from the replies there,
and I think we are making good progress.

> If you cannot trust my expertise - and it seems so

I'm confident that you have more experience than I do helping Windows
users. Perhaps you have more experience than any single LyX developer
for helping Windows users. But I do not think that the distance is as
large as you think, and I think that as a group, we have a lot of
combined experience. I do not agree with your claim that just because
many of us use Linux, we are incapable of making advice for what we
think is best for Windows users. I help LyX Windows users on lyx-users,
on http://tex.stackexchange.com, and on https://latex.org/forum/. My
family uses Windows, my friends use Windows, my colleagues use Windows,
and my students use Windows. And I am often the technical support for
people in all of those categories. The large majority of people I help
with computers are Windows users, not Linux users. I teach about 80
students a year, and they need to use their computer to work on
assignments. I am their technical support. I am not teaching computer
science students.  Some of the students have very little knowledge of
computers [2]. I just helped a student on Monday who had trouble
figuring out how to find the location of a file they downloaded, and how

Re: Update on 2.3.0 situation and Windows-specific issues

[Richard Kimberly Heck]

On 04/04/2018 07:07 PM, Uwe Stöhr wrote:
> Am 31.03.2018 um 19:37 schrieb Scott Kostyshak:
>
>> I've included something along these lines in the newest proposal for a
>> dialog.
>
> Dear Developers,
>
> yes, I take it personally that you cannot trust me as Windows
> developer who has experiences with LyX under Windows for more than 10
> years. 

Hi, Uwe,

It is not true that people don't trust you, and it really isn't helpful
to phrase it that way. This is not an issue of expertise, experience, or
anythinng of that sort. It's a judgement call about what to do in what
is obviously a difficult situation.

As others have explained, we work as a team here, and none of us ever
gets to make a decision all by ourselves about anything that is
important in LyX. I am pretty confident that all of us who have been
here for any amount of time have been on both sides of these kinds of
disagreements. I think the rest of us are puzzled why this issue should
be any different from any other where we discuss things, take a vote,
and more forward.

I think all of us understand your point of view. You want users to have
the simplest possible experience and, as a result, have created an
installer that is as automatic as it can be. Many of the rest of us have
real doubts about the wisdom of this, but we are not raising that issue.
The only issue here is: Should we or should we not upgrade aspects of
users' systems without asking their permission to do so? All of us
understand that, eventually, everyone will have to do this upgrade and
that there are things one can do even without upgrading that will break
people's MikTeX installations. Nonetheless, we think that we simply
cannot just *tell* users that we are upgrading their MikTeX
installations or, for that matter, any other software. We have to ask
first, and we have to leave things exactly as they were if people say "no".

I am quite certain that, even if only two-thirds of the team felt that
way, then we'd defer to your judgement. But it is not that way.
Literally everyone else agrees with what I have just written, and we
*all* have to stand behind what we release under the LyX name. It's not
just your reputation that is at stake here.

Riki

Re: Update on 2.3.0 situation and Windows-specific issues

[Uwe Stöhr]

Am 31.03.2018 um 19:37 schrieb Scott Kostyshak:


I've included something along these lines in the newest proposal for a
dialog.


Dear Developers,

yes, I take it personally that you cannot trust me as Windows developer 
who has experiences with LyX under Windows for more than 10 years. I 
gave LyX lectures to students and did a lot to help users over years.


I invested much time to write the details for interested people in the 
LyX Wiki and our docs but not to molest average users. So what is your 
problem? That I hide info from users? No, I just decide where I give 
info. Or why do you think I created many different Wiki pages and expert 
LyX documentation files?


I am sorry but I cannot understand not to release the Win installer just 
for a dialog or not. Is this that important not to release our hard work 
over months for LyX 2.3.0 for Windows users? Certainly not.


The situation is with a car: the majority just use it. They press the ON 
button or turn a key to start the motor and drive to e.g. a supermarket. 
They are not interested how the motor start is internally done or even 
what is below the car hood. Their task is to drive to the market. But 
what you want is that everybody should know what is under the hood. Why? 
Why can't people just use things?


What I do with the installer, is providing a LyX that just works to be 
able to focus on your task to write the text you want or have to write.


Please leave the expert point of view that users have to know background 
things. This is not how it works in the Windows world. Or does the 
LibreOffice Win installer bother you with background stuff? No, they 
don't bother users but give all expert info on their Wiki pages - so 
exactly as I do and did.


I am currently abroad (and will be the next 2 weeks) and cannot read all 
mails you forwarded to me.


It is not very helpful to make a survey on a mailing list since, as I 
explained, most users don't know or use mailing lists. Those who write 
there have usually some background knowledge. But why does my installer 
not have a special dialog - because average users won't understand it 
because of lack of background knowledge.



If you cannot trust my expertise - and it seems so - then I can move my 
installer to Github and announce it as separate program.


regards Uwe

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

[José Abílio Matos]

After looking into all the python scripts I have fixed most of the issues.

The only possible issues are files that are not in utf-8 encoding, I think that 
in all those cases we are on the safe side but I could be wrong.

The patch as it is should be compatible with both python 2 and python 3, so 
it should be safe both for lyx 2.3 and 2.4.

I would appreciate some testing before committing it. :-)

Regards,
-- 
José Abílio
diff --git a/lib/scripts/convertDefault.py b/lib/scripts/convertDefault.py
index e54b066888..9a460b7cf3 100644
--- a/lib/scripts/convertDefault.py
+++ b/lib/scripts/convertDefault.py
@@ -16,8 +16,11 @@
 # replacement in ~/.lyx/scripts
 
 # converts an image $2 (format $1) to $4 (format $3)
+from __future__ import print_function
 import os, re, sys
 
+PY2 = sys.version_info[0] == 2
+
 # We may need some extra options only supported by recent convert versions
 re_version = re.compile(r'^Version:.*ImageMagick\s*(\d*)\.(\d*)\.(\d*).*$')
 # imagemagick 7
@@ -31,6 +34,9 @@ if fout.close() != None:
 fout = os.popen('convert -version 2>&1')
 output = fout.readline()
 fout.close()
+if not PY2:
+output = output.decode()
+
 version = re_version.match(output)
 
 # Imagemagick by default
@@ -63,12 +69,12 @@ if sys.argv[1] == 'pdf' and (version >= 0x060206 or gm):
 if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
 opts = opts + ' -flatten'
 
-# print >> sys.stdout, command, sys.argv[2], sys.argv[4]
+# print (command, sys.argv[2], sys.argv[4], file= sys.stdout)
 if (im or gm) and os.system(r'%s %s "%s" "%s"' % (command, opts, sys.argv[2], sys.argv[3] + ':' + sys.argv[4])) != 0:
-print >> sys.stderr, sys.argv[0], 'ERROR'
-print >> sys.stderr, ('Execution of "%s" failed.' % command)
+print (sys.argv[0], 'ERROR', file= sys.stderr)
+print ('Execution of "%s" failed.' % command, file= sys.stderr)
 sys.exit(1)
 elif not im and not gm and sys.platform == 'darwin' and os.system(r'%s "%s" "%s"' % (command, sys.argv[2], sys.argv[4])) != 0:
-print >> sys.stderr, sys.argv[0], 'ERROR'
-print >> sys.stderr, ('Execution of "%s" failed.' % command)
+print (sys.argv[0], 'ERROR', file= sys.stderr)
+print ('Execution of "%s" failed.' % command, file= sys.stderr)
 sys.exit(1)
diff --git a/lib/scripts/fen2ascii.py b/lib/scripts/fen2ascii.py
index d7f0fb3d77..74087440e2 100644
--- a/lib/scripts/fen2ascii.py
+++ b/lib/scripts/fen2ascii.py
@@ -9,6 +9,7 @@
 # This script will convert a chess position in the FEN
 # format to an ascii representation of the position.
 
+from __future__ import print_function
 import sys,string,os
 
 os.close(0)
@@ -26,7 +27,7 @@ comp=string.split(line,'/')
 cont=1
 margin= " "*6
 
-print margin+'   +'+"-"*15+'+'
+print (margin+'   +'+"-"*15+'+')
 for i in range(8):
 cont = cont + 1
 tmp=""
@@ -42,7 +43,7 @@ for i in range(8):
 cont = cont + 1
 
 row = 8 - i
-print margin, row, tmp+"|"
+print (margin, row, tmp+"|")
 
-print margin+'   +'+"-"*15+'+'
-print margin+'a b c d e f g h '
+print (margin+'   +'+"-"*15+'+')
+print (margin+'a b c d e f g h ')
diff --git a/lib/scripts/fig2pdftex.py b/lib/scripts/fig2pdftex.py
index 603fd31103..b458ccd8f3 100644
--- a/lib/scripts/fig2pdftex.py
+++ b/lib/scripts/fig2pdftex.py
@@ -26,7 +26,7 @@
 #   the real pdf file will be overwritten by a tex file named file.pdf.
 #
 
-
+from __future__ import print_function
 import os, sys, re
 
 
@@ -35,7 +35,7 @@ def runCommand(cmd):
 run a command, quit if fails
 '''
 if os.system(cmd) != 0:
-print "Command '%s' fails." % cmd
+print("Command '%s' fails." % cmd)
 sys.exit(1)
 
 
@@ -78,15 +78,15 @@ else:
 # with tetex.
 epsfile = outbase + '.pstex'
 tmp = mkstemp()
-boundingboxline = re.compile('%%BoundingBox:\s+(\d*)\s+(\d*)\s+(\d*)\s+(\d*)')
-for line in open(epsfile).xreadlines():
-if line[:13] == '%%BoundingBox':
-(llx, lly, urx, ury) = map(int, boundingboxline.search(line).groups())
+boundingboxline = re.compile(b'%%BoundingBox:\s+(\d*)\s+(\d*)\s+(\d*)\s+(\d*)')
+for line in open(epsfile, 'rb'):
+if line[:13] == b'%%BoundingBox':
+(llx, lly, urx, ury) = list(map(int, boundingboxline.search(line).groups()))
 width = urx - llx
 height = ury - lly
 xoffset = - llx
 yoffset = - lly
-tmp.write('''BoundingBox: 0 0 %d %d
+tmp.write(b'''BoundingBox: 0 0 %d %d
 << /PageSize  [%d %d] >> setpagedevice
 gsave %d %d translate
 ''' % (width, height, width, height, xoffset, yoffset))
diff --git a/lib/scripts/fig2pstex.py b/lib/scripts/fig2pstex.py
index aaf3a1bd3a..90e163de40 100644
--- a/lib/scripts/fig2pstex.py
+++ b/lib/scripts/fig2pstex.py
@@ -26,6 +26,7 @@
 #   the real eps file will be overwritten by a tex file named file.eps.
 #
 
+from __future__ import print_function
 import os, sys
 
 # We expect two args, the names of the 

Re: [LyX/master] Do not use \tablefootnote in minipages

[Richard Kimberly Heck]

On 04/04/2018 02:09 PM, Jürgen Spitzmüller wrote:
> 2018-04-04 17:00 GMT+02:00 Richard Kimberly Heck  >:
>
> Fine for 2.3.2-staging.
>
>
> Note that it fixes a regression, so it might be a candidate for 2.3.x.

If you think it is safe enough for that, then go ahead.

Riki

Re: [LyX/master] Do not use \tablefootnote in minipages

[Jürgen Spitzmüller]

2018-04-04 17:00 GMT+02:00 Richard Kimberly Heck :

> Fine for 2.3.2-staging.
>

Note that it fixes a regression, so it might be a candidate for 2.3.x.

Jürgen


>
> Riki
>
>

Re: Behavior of overset inset creation on selection

[Jean-Marc Lasgouttes]

Le 31/03/2018 à 19:49, Scott Kostyshak a écrit :

To see an issue that has long annoyed me, do the following:

1. In math mode, type "=".
2. Select the "=" you just typed.
3. Choose "Overset" from the math toolbar (alternatively, just type "\overset").

The "=" is put in the "above" box, because that is the first LaTeX
argument. From the user perspective, I think that putting "=" in the
primary box is usually expected. For example, I think that this would be
more consistent with when the user selects something and chooses
"subscript". The thing selected is in the main box (it is not placed
into the subscript).


This patch tries to fix this. This touches several commonly used 
methods, so there is a real risk to introduce a regression. Let's see 
what happens.


If the result is satisfactory, I will have to finish the patch  (more 
refactoring needs to be done). Note that some insets other than Overset 
are touched: Script, Sideset, Underset. I did not really test them.


Comments welcome.

JMarc


From 988ffb35975aeaad173d9dea665aaccff620b300 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 4 Apr 2018 18:24:14 +0200
Subject: [PATCH] (WIP) When inserting math inset, put cursor selection in the
 correct cell

The original use case for this bug is entering an overset inset when
there is a selection. The expected result was to have the selection
pasted in main text, but the result was to have it in the cell.

Insets already have idxFirst() that is able to set cursor to the
"entry" cell of an inset. This patch introduces firstIdx(), which is
the index of this cell and useit in idxFirst() (idem for
lastIdx/idxLast).

As a consequence, several instances of idxFirst/idxLast can be removed.

Now for the real fix: the two places where the cell in which selection
is inserted seem to be:
* Cursor::macroModeClose
* Cursor::handleNest

These two methods are changed to insert material in the entry cell
instead of cell 0.

Finallly, fix a typo in InsetMathNest::edit() where enter_front
computation was wrong.
---
 src/Cursor.cpp   | 11 +--
 src/Cursor.h |  5 -
 src/mathed/InsetMathHull.cpp |  2 +-
 src/mathed/InsetMathNest.cpp | 12 ++--
 src/mathed/InsetMathNest.h   |  5 +
 src/mathed/InsetMathOverset.cpp  | 16 
 src/mathed/InsetMathOverset.h|  4 ++--
 src/mathed/InsetMathScript.cpp   | 16 
 src/mathed/InsetMathScript.h |  6 ++
 src/mathed/InsetMathSideset.cpp  | 16 
 src/mathed/InsetMathSideset.h|  6 ++
 src/mathed/InsetMathUnderset.cpp | 16 
 src/mathed/InsetMathUnderset.h   |  4 ++--
 13 files changed, 33 insertions(+), 86 deletions(-)

diff --git a/src/Cursor.cpp b/src/Cursor.cpp
index eb8c501..f3fccfa 100644
--- a/src/Cursor.cpp
+++ b/src/Cursor.cpp
@@ -1646,6 +1646,12 @@ void Cursor::handleNest(MathAtom const & a, int c)
 }
 
 
+void Cursor::handleNest(MathAtom const & a)
+{
+	handleNest(a, a.nucleus()->asNestInset()->firstIdx());
+}
+
+
 int Cursor::targetX() const
 {
 	if (x_target() != -1)
@@ -1703,6 +1709,7 @@ bool Cursor::macroModeClose(bool cancel)
 	// try to put argument into macro, if we just inserted a macro
 	bool macroArg = false;
 	InsetMathMacro * atomAsMacro = atom.nucleus()->asMacro();
+	InsetMathNest * atomAsNest = atom.nucleus()->asNestInset();
 	if (atomAsMacro) {
 		// macros here are still unfolded (in init mode in fact). So
 		// we have to resolve the macro here manually and check its arity
@@ -1717,8 +1724,8 @@ bool Cursor::macroModeClose(bool cancel)
 	}
 
 	// insert remembered selection into first argument of a non-macro
-	else if (atom.nucleus()->nargs() > 0)
-		atom.nucleus()->cell(0).append(selection);
+	else if (atomAsNest && atomAsNest->nargs() > 0)
+		atomAsNest->cell(atomAsNest->firstIdx()).append(selection);
 
 	MathWordList const & words = mathedWordList();
 	MathWordList::const_iterator it = words.find(name);
diff --git a/src/Cursor.h b/src/Cursor.h
index 5ca98cb..08309fa 100644
--- a/src/Cursor.h
+++ b/src/Cursor.h
@@ -515,8 +515,11 @@ public:
 
 
 	/// replace selected stuff with at, placing the former
+	// selection in entry cell of atom
+	void handleNest(MathAtom const & at);
+	/// replace selected stuff with at, placing the former
 	// selection in given cell of atom
-	void handleNest(MathAtom const & at, int cell = 0);
+	void handleNest(MathAtom const & at, int cell);
 
 	/// make sure cursor position is valid
 	/// FIXME: It does a subset of fixIfBroken. Maybe merge them?
diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 8f40d2c..c132997 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -2253,7 +2253,7 @@ void InsetMathHull::handleFont2(Cursor & cur, docstring const & arg)
 	font.fromString(to_utf8(arg), b);
 	if (font.fontInfo().color() != Color_inherit) {
 		MathAtom at = MathAtom(new InsetMathColor(buffer_, true, 

Re: Regression - italic font in text after mathed

[Jean-Marc Lasgouttes]

Le 04/04/2018 à 17:54, Pavel Sanda a écrit :

Hi,

I found weird regression:
1. go behind the last character in mathed (but remain in the inset)
2. hit space instead to leave the inset
3. write something in text, the text suddenly becomes italic without reason


Probably due to my cursor height patch which resets 
Cursor::current_font. I will fix it, but it might be that many instances 
of this issue exist. Time will tell.


JMarc

Re: How to get rid of indentation in footnote

[Matěj Cepl]

On 2018-04-03, 08:08 GMT, jezZiFeR wrote:
> could somebody please help: how could I get rid of the 
> indentation of footnotes in the first line of the footer? 
> I want every footnote to begin at the margin without 
> indentation. I use KOMA-script-report in LyX 2.3.0. Please let 
> me know if you need a screenshot.

Try something on the tone of:

 \newlength{\mc@fnbodywidth}
 \renewcommand{\@makefntext}[1]{%
 \setlength{\mc@fnbodywidth}{\linewidth}
 \addtolength{\mc@fnbodywidth}{-1.8em}
 \noindent\parbox[t]{1.8em}%
 {\hfill\@makefnmark\hspace*{3pt}}%
 \parbox[t]{\mc@fnbodywidth}{#1}%
 }

It's a long time since I really worked with LyX, but you may 
take a look at 
https://gitlab.com/mcepl/programky/tree/master/contract where 
you can find some inspiration (hopefully). It is completely 
unsupported and I have forgotten most how it works.

Best,

Matěj


pgp4dvQvQe5ny.pgp
Description: PGP signature

Regression - italic font in text after mathed

[Pavel Sanda]

Hi,

I found weird regression:
1. go behind the last character in mathed (but remain in the inset)
2. hit space instead to leave the inset
3. write something in text, the text suddenly becomes italic without reason

Pavel

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

[Scott Kostyshak]

On Wed, Apr 04, 2018 at 01:16:45PM +, Emile Lunardon wrote:
> 2018-04-04 4:11 GMT+02:00 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?
>
> Now with LyX 2.3,  LaTeX insets with '{}' inside, are no more recognized
> using advanced S and erroneous replacements of [ or ] no more occur.

OK so there is still a problem. Thanks for checking.

Scott


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

On Wed, Apr 04, 2018 at 10:38:58AM +, Jean-Marc Lasgouttes wrote:

> We did not manage to have a full discussion :)  Executive summary is like

I like this phrase. Next time, I will ask for an "Executive summary".
It is better than the alternative, "summary for dummies" :)

> Stephan: I get a crash with 2.2 and master when selecting quickly and the
> following patch helps
> 
> JMarc: I see that newword (the thing that avoids adding spell checker marks
> under currently edited word) is not correct in this case. It would be better
> to understand why it is not correct
> 
> Stephan: I do not understand what you mean [probably because my explanation
> was not as good as this one]
> 
> JMarc: [rephrases the problem]
> 
> I do not know what is the status beyond that, sorry.

Thank you for the summary. That helps. I will now forget about this
thread. It is up to you and Stephan if you want to keep it alive.

Scott


signature.asc
Description: PGP signature

Re: Applying LFUN_MATH_MODE to big help docs causes memory problems

[Scott Kostyshak]

On Wed, Apr 04, 2018 at 10:33:47AM +, Jean-Marc Lasgouttes wrote:
> Le 04/04/2018 à 04:17, Scott Kostyshak a écrit :
> > 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.
> 
> My idea was to apply an arbitrary limit before converting to string.

Ah I see. So conversion to string can be slow. I was focused on the
conversion of string to math so did not think about that. Makes sense.

> Converting the full User Guide to a string is not a good idea memory-wise.

If I copy the full User Guide and paste into a text editor, it is very
fast. Why would converting to a string be slower?

> My proposal is : only accept to convert up to 10 (or 20, whatever)
> paragraphs.

Sounds like the best proposal. Now we have to think whether this is
worth the work and better than doing nothing. As far as I know, I'm the
only one that came across this issue and I was actually trying to break
LyX if I remember correctly. Nonetheless, I suppose we do not want LyX
to freeze, even in weird situations.

I still wonder if we should also refuse to convert to math if the
selection contains a certain type of inset. e.g. even if just one
paragraph, I don't know if we want to convert a float to math. But I
have no idea what the list of insets would be, so maybe this is actually
not a good idea.

By the way, I wonder why we stopped receiving reports from the author of
that program that would send random keys to LyX (see [1] and [2]).

Scott


[1]
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152090.html

[2]
http://www.lyx.org/trac/query?status=!closed=gma...@gmail.com


signature.asc
Description: PGP signature

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

[Jean-Marc Lasgouttes]

Le 04/04/2018 à 16:50, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I pushed it to master. Please try it out and let me know whether it is
ready for 2.3.x, especially with small font size.


I am working with it. The most striking of small cursor is if you type operator
first, e.g. hit minus ("-") in mathed first and see the cursor size.

I am fine with that, but I can imagine it can be irritating to others...
But it's up to them to show up and scream ;)


This is not supposed to happen... I'll have a look.

JMarc

Re: [LyX/master] Do not use \tablefootnote in minipages

[Richard Kimberly Heck]

On 04/04/2018 04:54 AM, Juergen Spitzmueller wrote:
> commit 37404df686dc42c5eb88fbd51103016e175cad09
> Author: Juergen Spitzmueller 
> Date:   Wed Apr 4 10:53:40 2018 +0200
>
> Do not use \tablefootnote in minipages
> 
> Minipages provide their own working \footnote's
> 
> Should also go to 2.3.x.

Fine for 2.3.2-staging.

Riki

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

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> I pushed it to master. Please try it out and let me know whether it is 
> ready for 2.3.x, especially with small font size.

I am working with it. The most striking of small cursor is if you type operator
first, e.g. hit minus ("-") in mathed first and see the cursor size.

I am fine with that, but I can imagine it can be irritating to others...
But it's up to them to show up and scream ;)

Pavel

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

[Jean-Marc Lasgouttes]

Le 03/04/2018 à 17:41, Pavel Sanda a écrit :

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



I pushed it to master. Please try it out and let me know whether it is 
ready for 2.3.x, especially with small font size.


JMarc

Re: Encoding of an eps file

[José Abílio Matos]

On Wednesday, 4 April 2018 14.28.44 WEST José Abílio Matos wrote:
> Hi,
>   while trying to solve #Bug 11101 I faced the doubt
> of what is the encoding of an eps file.
> 
> Is it ascii or can it use another encoding?
> 
> Regards,

Replying myself: it can be another encoding.

$ file -bi example.eps
application/postscript; charset=iso-8859-1

-- 
José Abílio

Encoding of an eps file

[José Abílio Matos]

Hi,
while trying to solve #Bug 11101 I faced the doubt 
of what is the encoding of an eps file.

Is it ascii or can it use another encoding?

Regards,
-- 
José Abílio

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

[Emile Lunardon]

Now with LyX 2.3,  LaTeX insets with '{}' inside, are no more recognized
using advanced S and erroneous replacements of [ or ] no more occur.

2018-04-04 4:11 GMT+02:00 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
>

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

[Jean-Marc Lasgouttes]

Le 04/04/2018 à 03:54, Scott Kostyshak a écrit :

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?


We did not manage to have a full discussion :)  Executive summary is like

Stephan: I get a crash with 2.2 and master when selecting quickly and 
the following patch helps


JMarc: I see that newword (the thing that avoids adding spell checker 
marks under currently edited word) is not correct in this case. It would 
be better to understand why it is not correct


Stephan: I do not understand what you mean [probably because my 
explanation was not as good as this one]


JMarc: [rephrases the problem]

I do not know what is the status beyond that, sorry.

JMarc

Re: Applying LFUN_MATH_MODE to big help docs causes memory problems

[Jean-Marc Lasgouttes]

Le 04/04/2018 à 04:17, Scott Kostyshak a écrit :

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.


My idea was to apply an arbitrary limit before converting to string. 
Converting the full User Guide to a string is not a good idea memory-wise.


My proposal is : only accept to convert up to 10 (or 20, whatever) 
paragraphs.


JMarc