date:20170420

Dear all,

As discussed [1], the current plan is to release alpha1 on Saturday.

Please do not make any commits to master today after 22h00 UTC until
master is open again. Between now and 22h00 UTC, please only make
commits that:

  (1) are very safe

and

  (2) you are confident do not break any of the ctests

If there is a strong reason to break one of those two criteria, please
start a discussion on the list explaining why an exception should be
made.

Otherwise, please just wait until after alpha1.

After 22h00 UTC, I will run all of the ctests, as well as compilation
tests for various configurations. Assuming all tests pass, I'll then tag
and tar alpha1 and send the tar out for packaging.

Scott

[1] 
https://www.mail-archive.com/search?l=mid=20170410034041.ijhka562h55j3qez%40steph



signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

On Thu, Apr 20, 2017 at 11:48:12PM -0400, Scott Kostyshak wrote:

> > $1 = (const lyx::support::FileName &) @0x3559560: {
> >   _vptr.FileName = 0x38ca7d0, 
> >   d = 0x0
> > }
> 
> What information does this tell you? I guess that 0x38ca7d0 is a memory
> address of the pointer?

Ah so the idea is that at this point I should realize that it should be
an actual file name, not a pointer to a file name?

Scott


signature.asc
Description: PGP signature

Re: CopyrightYear is the correct command name in acmsiggraph-0.92.layout

On Thu, Feb 16, 2017 at 07:06:48PM +0100, Jean-Pierre Chrétien wrote:

> Happily, ACM decided to shift to the sole acmart.cls class for all their
> publications as Jürgen pointed out (see also
> https://www.tug.org/tug2016/slides/veytsman.pdf), and made very recently all
> their old class files unavailable.
> So we rather should cencentrate on creating a layout for the acmart class
> rather than fighting with obsolete stuff like I did (it is stated that
> obsoleted LaTeX acm packages won't be usable to submit publications after
> Spring 2017).

Looks like some work has been done on a layout for acmart.cls by John
Perry at

  http://www.lyx.org/trac/ticket/10632

Can someone take a look at that?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] lyx2lyx/lyx_2_2.py: correct reversion of boxes

On Fri, Apr 21, 2017 at 01:05:44AM +0200, Uwe Stöhr wrote:
> El 19.04.2017 a las 06:58, Scott Kostyshak escribió:
> 
> > >  lyx2lyx/lyx_2_2.py: correct reversion of boxes
> > 
> > git bisect suggests that this commit broke the test
> > 
> >export/doc/Math_lyx21
> > 
> > Uwe, can you take a look?
> 
> At first I don't understand why I don't get any error or warning when doing
> 
> lyx -e lyx21x Math.lyx
> lyx -batch Math.21.lyx
> 
> Math.21.lyx is then correctly created without errors but using the -batch
> mode I don't get any error or warning too. Therefore the tests are all
> always passed for me.

Good to know. That's a problem that we should hopefully fix. I think
using "-batch" in that way is undocumented behavior. Perhaps we could do
something like execute "lyx-quit".

> I already asked Kornel what I can do but it seems to
> be a bug of LyX.
> 
> I fixed the lyx2lyx bug now.

Thanks, the lyx2lyx tests all pass now.

Scott


signature.asc
Description: PGP signature

Re: Should LaTeX output from command line be equivalent to GUI?

On Wed, Mar 01, 2017 at 03:10:23PM -0500, Scott Kostyshak wrote:
> On Wed, Mar 01, 2017 at 07:05:36PM +0100, Jean-Marc Lasgouttes wrote:
> > Le 01/03/2017 à 18:42, Scott Kostyshak a écrit :
> > > > It gives me the following output:
> > > > 
> > > > 8548c8548
> > > > < \settowidth{\nomlabelwidth}{"@, "|, "!, ""}
> > > > ---
> > > > > \settowidth{\nomlabelwidth}{May�sculas}
> > > 
> > > Can anyone reproduce?
> > 
> > I did not try to, but the reason is obvious: this is InsetNomencl code,
> > where \nomlabelwidth is set to the width of the larger entry. This width
> > uses the width seen on screen if there is a GUI (which does not make sense!)
> > and the string length otherwise.
> > 
> > Looking at nomencl's documentation, I think that we should not set
> > \nomlabelwidth, but instead add a width option to InsetNomencl and pass it
> > to \printnomenclature (as optional argument).
> > 
> > The other simpler solution would be to remove this hack. The only problem is
> > that this will change the display of existing documents.
> 
> OK so if we do this it would be for master only, and we should put
> something in the release notes.

I created a trac ticket here:

  http://www.lyx.org/trac/ticket/10634

I did not set the milestone but if you think we should fix it for 2.3.0
we should set it.

Scott


signature.asc
Description: PGP signature

design patterns used in LyX

Dear all,

I would like to improve my understanding of programming and C++ in a way that
will help me understand LyX's code better.

I'm wondering if:

(1) studying design patterns is a reasonable way to achieve that goal
(2) what the best way to do that would be
(3) which design patterns we use in LyX

I feel like my understanding of C++ is similar to knowing a linguistic language
by memorizing the dictionary. I understand what most lines of code do (just
like understanding what words mean in an English sentence), but I don't have a
good understanding of big picture concepts.

Are there any general concepts used in LyX that have formal names that I
could study? For example, it took me a while to realize that "pointer to
implementation" is actually a general strategy. I would like to study
more techniques such as that.

When searching for books on design patterns, the following two seem to stand
out:

https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/product-reviews/0201633612/
https://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315/

I am considering getting one.

I also found JMarc's commit at 91b38516 which referenced

https://www.ics.com/designpatterns/book/

but perhaps he just came across that URL when searching.

It would be great if there were a couple of examples of "technique name" paired
with a reference to an actual example of where we use that technique in LyX.
I've only seen a couple of references to general techniques, but perhaps I
haven't been keeping my eyes open enough. It was actually Jürgen's commit at
8f6491f0 and Guillaume's recent commit at 4fc8c7fe ("composition over
inheritence") that made me remember my goal of learning general strategies.

Scott

signature.asc
Description: PGP signature

#9841: use Qt's session management?

Please see

  http://www.lyx.org/trac/ticket/9841

Guillaume proposed to use Qt's session management, which would simplify
things. Does anyone have an opinion?

I'm not sure if Guillaume would have the time and interest to implement
this for 2.3.0, but at least we could make a decision now.

Scott


signature.asc
Description: PGP signature

#10400: keyboard shortcut for document settings?

Should we have a keyboard shortcut for document settings, as proposed at

  http://www.lyx.org/trac/ticket/10400

?

There is a proposal to use ctrl + p, which is now free because we got
rid of print.

I agree a shortcut would be nice. I have mixed feelings about the
particular shortcut ctrl + p, but I don't have another suggestion.

Scott


signature.asc
Description: PGP signature

#10469: patch for putting LyX window on top on Windows

Dear all,

I am wondering if we should include racoon's patch at #10469. It can be
seen here:

  http://www.lyx.org/trac/attachment/ticket/10469/0001-Fix-for-10469.patch

I would propose that we include it with an OS guard for Windows only for
the setWindowState line.

I'm not sure anyone understands why the patch works, but racoon has
tested it, and it is simple.

Any thoughts?

Scott


signature.asc
Description: PGP signature

compile-time Qt checks

Anyone interested in using the tool described here to find bugs in our
Qt-related code?

  https://www.kdab.com/uncovering-32-qt-best-practices-compile-time-clazy/

Scott


signature.asc
Description: PGP signature

Re: Is anyone planning to test TL 2017 pre-test?

On Mon, Apr 10, 2017 at 12:22:26AM -0400, Scott Kostyshak wrote:
> Dear all,
> 
> Is anyone planning to test TL 2017 pretest? It begins 16 April [1]. I am
> planning to install it and run all of our export tests. Some will surely
> fail. And then it will be a question of whether we need to change our
> LaTeX export. Hopefully we will not, but it is good to plan for this
> possibility.
> 
> I'm hoping that another LyX developer will have a virtual box set up
> with LyX and TL 2017 pretest so that they can help figure out whether
> and how we need to change our LaTeX export code.
> 
> Scott

Only a few ctests are failing on pretest. One set of failures (LuaTeX
compilation of EmbeddedObjects manual) is due to a known LuaTeX bug that
I think is fixed [1], and will soon be in the TeX Live mirrors. Another
set of failures only affect tests marked as UNRELIABLE. I will still
investigate those if the failures persist.

In summary, I'm not worried we need to change anything on our end.

Scott

[1]
https://www.mail-archive.com/search?l=mid=CAEW6iOgRu7ZuK0-cuwr5%3D7Bj4tg9dZ3MM3LxKNHtgwwuUEqnDQ%40mail.gmail.com

signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

On Thu, Apr 20, 2017 at 07:59:05PM +0200, Kornel Benko wrote:
> Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 
> 
> > On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > > A 2nd SIGSEGV, involving similar actions, but the crash happens 
> > > > earlier, so
> > > > I guess it's a different bug:
> > > > 1. clear your ~/.lyx-trunk/cache/*
> > > > 2. start LyX, new doc
> > > > 3. type "info-insert icon whatevernonsense"
> > > > 
> > > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > > 
> > > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> > > bisect tomorrow if no one beats me to it:
> > > 
> > >   git bisect start
> > >   git bisect good 15fd7920
> > >   git bisect bad dbcbf305
> > 
> > My bisect lead to 244de5d2
> 
> This makes sense, because I came to the same commit while investigating the 
> crash.

I'm curious (to improve my debugging skills), how did you think through
this and how did the above lead you to 244de5d2?

> Backtrace gives src/support/FileName.cpp:188
>   return d->name
> (gdb) p d->name
> Cannot access memory at address 0x0

I get to here OK. I think the though process is "why do we crash when
reading d->name? Let's print it out". We cannot access the memory, so
that means something is wrong with "d->name". Let's go higher up to see
where d->name becomes invalid.

> (gdb) up
>   src/graphics/GraphicsConverter.cpp:146
> (gdb) p doc_fname_

Here I am already a little lost. How did you know to print doc_fname_?
I see in the gdb output that it is an argument of the function that we
are in. But did you just make the connection between the "name" in
"d->name" and the "name" in "doc_fname_" ?

> $1 = (const lyx::support::FileName &) @0x3559560: {
>   _vptr.FileName = 0x38ca7d0, 
>   d = 0x0
> }

What information does this tell you? I guess that 0x38ca7d0 is a memory
address of the pointer?

Scott

signature.asc
Description: PGP signature

Re: [LyX/master] special character "allowbreak" (ZWSP), fileformat change

On Thu, Apr 20, 2017 at 11:29:55PM +0200, Günter Milde wrote:
> commit f5ac0580ff8f4f1fd34d792f7952fb05d182e162
> Author: Günter Milde 
> Date:   Mon Mar 6 14:49:30 2017 +0100
> 
> special character "allowbreak" (ZWSP), fileformat change
> 
> New special character to mark an optional line break
> without inserting a hyphen (ZWSP). See #10585.
> 
> Corresponds to the Unicode character U+200B ZERO WIDTH SPACE
> 
>  This isn't a “space”. It is an invisible character that can be used
>  to provide line break opportunities.
>  http://unicode.org/notes/tn27/
> 
> While the literal Unicode character can be used in the LyX
> file, it is invisible in the GUI.
> 
> For visible feedback, the patch adds a new special character "allowbreak".
> 
> The small mark is inspired by LibereOffice.
> A tooltip is added.

A bisect suggests that this commit broke the following test:

  tex2lyx/roundtrip/box-color-size-space-align.tex (Failed)

I'm guessing that the following test was also broken by this commit (but
I only bisected based on the above test):

  tex2lyx/cmplyx/box-color-size-space-align.tex (Failed)

Günter will you have time to look into this today?

Scott


signature.asc
Description: PGP signature

proper way to check inclusion among DocIterator ?


Hi,

is there an easy way to check whether a DocIterator d is positioned within two 
others a and b ?
(that is, going through the document using forwardPos(), one encounters a, then 
d, then b).

AFAIU, DocIterator::operator() just compares nesting levels, but no pos() nor 
pit() etc.

Thanks,

T.

Re: [patch] for LyX 2.2.3 - box reversion lyx2lyx


El 17.04.2017 a las 05:30, Uwe Stöhr escribió:

the attached patch fixes several box reversion issues in lyx2lyx. Scott 
could verify that the conversion to LyX 2.1.x works now as expected.


Hi Richard,

this patch fixed some issues but Math.lyx uncovered an issue that I 
introduced with this patch.

Attached is the patch for LyX 2.2.3 that allows to revert Math.lyx again.

sorry and regards
Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\lyx_2_2-cac7b00.001.py" 
"b/D:\\LyXGit\\2.2.x\\lib\\lyx2lyx\\lyx_2_2.py"
index c30477de17..a65f8ca67d 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\lyx_2_2-cac7b00.001.py"
+++ "b/D:\\LyXGit\\2.2.x\\lib\\lyx2lyx\\lyx_2_2.py"
@@ -1093,11 +1093,13 @@ def revert_BoxFeatures(document):
 if i == -1:
 return
 binset = find_token(document.body, "\\begin_inset Box", i - 11)
-if binset == -1:
-return # then "thickness" is is just a word in the text
+if binset == -1 or binset != i - 11:
+i = i + 1
+continue # then "thickness" is is just a word in the text
 einset = find_end_of_inset(document.body, binset)
 if einset == -1:
 document.warning("Malformed LyX document: Can't find end of box 
inset!")
+i = i + 1
 continue
 # read out the values
 beg = document.body[i].find('"');

Re: [LyX/master] lyx2lyx/lyx_2_2.py: correct reversion of boxes


El 19.04.2017 a las 06:58, Scott Kostyshak escribió:


 lyx2lyx/lyx_2_2.py: correct reversion of boxes


git bisect suggests that this commit broke the test

   export/doc/Math_lyx21

Uwe, can you take a look?


At first I don't understand why I don't get any error or warning when doing

lyx -e lyx21x Math.lyx
lyx -batch Math.21.lyx

Math.21.lyx is then correctly created without errors but using the 
-batch mode I don't get any error or warning too. Therefore the tests 
are all always passed for me. I already asked Kornel what I can do but 
it seems to be a bug of LyX.


I fixed the lyx2lyx bug now.

regards Uwe

Re: [coverity again] missing move constructors


Le 08/04/2017 à 23:05, Jean-Marc Lasgouttes a écrit :


Also, I do not understand this (I know it is the same as the old code)
+explicit Inset(Inset const &) : buffer_(0) {}

What is this good for? The semantics look quite broken to me. Is this
even used? (I guess we should make it private to find out).


Like in InsetMathHull and InsetMathNest, I imagine that this is meant to
implement some sort of cache that one invalidates on copy. It is used in
all the Inset*::clone functions for a start.

operator= on the other hand is used nowhere, so the difference does not 
matter. In the attached I even undefine it.



FileName:
This would be automatically copyable and movable if not for the use of
the pointer to implementation.


What is the problem with the pointer?


For motivations see for instance
.


As long as the implementation does
not contain a backpointer, I would say that copying the pointer (and
setting to null in the original?


This is what I propose to do automatically.


Is this supposed to go through a
destructor at some time?)


Yes, one must be careful about custom destructors with move
operators. There is no magic ensuring that the destructor is not
called after a move.


should be good enough to won the contents.

There is a solution here:

. If we
used spimpl.h from there, then all the custom destructor and copies
could be removed, and the moves would be generated automatically. In
fact this could be used to simplify other copyable classes with a
pointer to implementation. Do you think the Boost license allow its
inclusion in src/support?


I have to take a look.


Thanks.



InsetMathNest and InsetMathHull:
To do this one should define a template cached that
consists in X where the copy is overridden to reset the value (assuming
it is very important to do this).


I really do not know what this thing is.



I am thinking about something along the lines of the attached patches.
But to be clear, one should not expect any performance gain. Only some
review, clarification, and simplification of the code.

Speaking of review, I found that setMouseHover was never used, making
the variable useless. What do you think?

Guillaume
>From 9e0a2bc9ca8b496b5af488634eef905a9f837170 Mon Sep 17 00:00:00 2001
From: Guillaume MM 
Date: Sun, 9 Apr 2017 21:43:33 +0200
Subject: [PATCH 1/3] InsetMathHull: let move operators be defined
 automatically

---
 src/CutAndPaste.cpp  |  11 +++--
 src/mathed/InsetMathHull.cpp | 101 ++-
 src/mathed/InsetMathHull.h   |  19 
 src/mathed/InsetMathNest.cpp |  33 +
 src/mathed/InsetMathNest.h   |  26 +-
 src/mathed/InsetMathRef.cpp  |   4 +-
 src/mathed/MathMacro.cpp |  11 -
 src/mathed/MathMacroTemplate.cpp |   4 +-
 src/support/unique_ptr.h |  29 +++
 9 files changed, 113 insertions(+), 125 deletions(-)

diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp
index 17dbdc6..e625ebe 100644
--- a/src/CutAndPaste.cpp
+++ b/src/CutAndPaste.cpp
@@ -252,16 +252,17 @@ pasteSelectionHelper(DocIterator const & cur, ParagraphList const & parlist,
 		case MATH_HULL_CODE: {
 			// check for equation labels and resolve duplicates
 			InsetMathHull * ins = it->asInsetMath()->asHullInset();
-			std::vector labels = ins->getLabels();
+			std::vector const & labels =
+ins->getLabels();
 			for (size_t i = 0; i != labels.size(); ++i) {
 if (!labels[i])
 	continue;
-InsetLabel * lab = labels[i];
-docstring const oldname = lab->getParam("name");
-lab->updateLabel(oldname);
+InsetLabel & lab = *labels[i];
+docstring const oldname = lab.getParam("name");
+lab.updateLabel(oldname);
 // We need to update the buffer reference cache.
 need_update = true;
-docstring const newname = lab->getParam("name");
+docstring const newname = lab.getParam("name");
 if (oldname == newname)
 	continue;
 // adapt the references
diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 38cdd26..d5b9318 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -195,12 +195,10 @@ docstring hullName(HullType type)
 	return from_ascii("none");
 }
 
-static InsetLabel * dummy_pointer = 0;
-
 InsetMathHull::InsetMathHull(Buffer * buf)
 	: InsetMathGrid(buf, 1, 1), type_(hullNone), numbered_(1, NUMBER),
-	  numbers_(1, empty_docstring()), label_(1, dummy_pointer),
-	  preview_(new RenderPreview(this))
+	  numbers_(1, empty_docstring()), label_(1),
+	  preview_(make_unique(this))
 {
 	//lyxerr << "sizeof InsetMath: " << sizeof(InsetMath) << endl;
 	//lyxerr << "sizeof MetricsInfo: " << sizeof(MetricsInfo) << endl;
@@ -214,8 +212,8 @@ InsetMathHull::InsetMathHull(Buffer * buf)
 
 InsetMathHull::InsetMathHull(Buffer * buf, HullType type)

New warnings in master

../../src/insets/InsetSpecialChar.cpp: In member function ‘virtual 
lyx::docstring lyx::InsetSpecialChar::toolTip(const lyx::BufferView&, 
int, int) const’:
../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
‘LDOTS’ not handled in switch [-Wswitch]

  switch (kind_) {
 ^
../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
‘MENU_SEPARATOR’ not handled in switch [-Wswitch]
../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
‘PHRASE_LYX’ not handled in switch [-Wswitch]
../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
‘PHRASE_TEX’ not handled in switch [-Wswitch]
../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
‘PHRASE_LATEX2E’ not handled in switch [-Wswitch]
../../src/insets/InsetSpecialChar.cpp:92:9: warning: enumeration value 
‘PHRASE_LATEX’ not handled in switch [-Wswitch]


Guillaume

Re: SIGSEGV on luatex export #2


On 20/04/2017 22:28, Guillaume MM wrote:

The attached fixes it for me.


for me as well, pushed, thanx :-)!

T.

Re: [LyX/master] BufferParams: get rid of the HSpace class for mathindent as requested by JMarc


El 20.04.2017 a las 23:17, Uwe Stöhr escribió:

I have seen your changes but now LyX has no longer the GlueLength 
ability as you noted.


Sorry. This ability was not in LyX. glue lengths are not allowed as 
parameter of \setspace. So having HSpace there was indeed never necessary.


thanks and regards
Uwe

Re: [LyX/master] BufferParams: get rid of the HSpace class for mathindent as requested by JMarc


El 20.04.2017 a las 18:11, Jean-Marc Lasgouttes escribió:

I turns out that I committed it by mistake. Please complain if something 
is wrong.


I did in my previous mail and just put in a fix for the error I get.

thanks for your work and regards
Uwe

Re: [LyX/master] BufferParams: get rid of the HSpace class for mathindent as requested by JMarc


El 19.04.2017 a las 11:58, Jean-Marc Lasgouttes escribió:

HSpace is a class that contains a GlueLength, a complex class that 
handles subleties of a length like 1cm-2mm+3mm. Is that "just a string" 
to you??


"1cm-2mm+3mm" is a string to me, yes. I did not need the special 
features of the Length class, but I guess for the on screen 
visualization it is necessary.


I have seen your changes but now LyX has no longer the GlueLength 
ability as you noted. I cannot remember what I had in mind 8 years ago 
when implementing it, but I remember that glue length are useful and 
were even requested by users. So maybe there was a good reason to allow 
glue lengths for the paragraph indentation.


In your changes you reverted the allowMathIndent() routine in 
GuiDocument. This is necessary because now we have a bug:

- set default math indent
- now change to custom and input a length and press Apply
- now uncheck "Indent Formulas"
result: the length fields are still active.

I am tending to re-introduce allowMathIndent() therefore.


Do as you want, I am not going to write UI after all.


OK.

regards Uwe

Re: beamer editing


Le 20/04/2017 à 23:10, Edwin Leuven a écrit :

On 20 Apr 2017, at 22:47, Guillaume MM  wrote:


At the time I reviewed your patch and pointed out regressions of the new
behaviour: .


i don’t see any of those regressions


Strange, the patch is the same as at the time.



(unless i misunderstood you)


It was a long time ago and I do not remember the details unfortunately.




I also suggested to introduce instead a new layout that uses
flex insets for frames, to solve this exact issue. It is now available
at . I had positive feedback about
it on the general list. Would you like to give it a try?


it’s editing wise definitely an improvement!

(and aesthetically a minor regression ;-)



Thanks for your test

Guillaume



best, ed.

Re: beamer editing

2017-04-20 Thread Edwin Leuven

On 20 Apr 2017, at 22:47, Guillaume MM  wrote:
> 
> At the time I reviewed your patch and pointed out regressions of the new
> behaviour: .

i don’t see any of those regressions 

(unless i misunderstood you)

> I also suggested to introduce instead a new layout that uses
> flex insets for frames, to solve this exact issue. It is now available
> at . I had positive feedback about
> it on the general list. Would you like to give it a try?

it’s editing wise definitely an improvement!

(and aesthetically a minor regression ;-)

best, ed.

Re: beamer editing


Le 20/04/2017 à 09:40, Edwin Leuven a écrit :

hello,

quite some time ago i complained about editing frame content in lyx

basic frame content is indented and has a standard environment

a new line  however removes the indent and resets the standard 
environment to frame

to continue editing one has to re-ident and reset the environment, which is imo 
disruptive and unnecessary

i think the desired/expected behavior is that  preserves the identing 
and environment

and that  only resets things if the line is empty

(just like in itemize)

at the time i send in the attached little patch



Hello Edwin,

At the time I reviewed your patch and pointed out regressions of the new
behaviour: .

I also suggested to introduce instead a new layout that uses
flex insets for frames, to solve this exact issue. It is now available
at . I had positive feedback about
it on the general list. Would you like to give it a try?

Guillaume




i was wondering what you think about the suggested behavior, and whether you 
have some comments on the patch

it would be nice to have this fixed for 2.3

regards, edwin

Re: beamer editing

2017-04-20 Thread Edwin Leuven

On 20 Apr 2017, at 10:08, Jürgen Spitzmüller  wrote:
> Am Donnerstag, den 20.04.2017, 09:40 +0200 schrieb Edwin Leuven:
>> quite some time ago i complained about editing frame content in lyx
>> 
>> …
>> i think the desired/expected behavior is that  preserves the
>> identing and environment
>> 
>> and that  only resets things if the line is empty
> 
> I think your proposal makes sense at least for the beamer case.

feel free to apply the patch ;-)

ed.

Re: Qt terminal message "path is empty"


Le 18/04/2017 à 08:10, Scott Kostyshak a écrit :

I've been getting the following message on recent master:

  QFileSystemWatcher::removePath: path is empty

One way to trigger it is to have two different LyX instances open, write
"hello" in one of them and select it and copy it and paste it in the
other instance.

The attached patch fixes it for me, but it's probably wrong. I can
investigate into why I get an empty path at this point in the code, if
someone thinks it is worth the time.

Scott



I'll need to have a look; in a few days.

Guillaume

Re: SIGSEGV on luatex export #2


Le 20/04/2017 à 19:02, Scott Kostyshak a écrit :

On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:

On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:

A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
I guess it's a different bug:
1. clear your ~/.lyx-trunk/cache/*
2. start LyX, new doc
3. type "info-insert icon whatevernonsense"

=> LyX SIGNAL CAUGHT dialog with std::bad_alloc.


I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
bisect tomorrow if no one beats me to it:

  git bisect start
  git bisect good 15fd7920
  git bisect bad dbcbf305


My bisect lead to 244de5d2 but I'm not confident in the bisect (for some
revisions I could reproduce once and then not a separate time. I always
cleared the cache each time but still had mixed results).

When git bisect narrowed in on the commits around there, I thought it
would be 6c920757 since that has to do with icons. But that's not where
bisect took me.

So don't take my results too seriously. Hopefully someone else can take
a look.

Scott



The attached fixes it for me.

You can get a trace for when an exception is thrown in gdb with "catch 
throw".


Guillaume
diff --git a/src/graphics/GraphicsCacheItem.cpp b/src/graphics/GraphicsCacheItem.cpp
index c698168..33d4747 100644
--- a/src/graphics/GraphicsCacheItem.cpp
+++ b/src/graphics/GraphicsCacheItem.cpp
@@ -95,7 +95,7 @@ public:
 	/// The filename we refer too.
 	FileName const filename_;
 	/// The document filename this graphic item belongs to
-	FileName const & doc_file_;
+	FileName doc_file_;
 	///
 	FileMonitor const monitor_;
 
diff --git a/src/graphics/GraphicsConverter.cpp b/src/graphics/GraphicsConverter.cpp
index 55ae246..9e6cbd7 100644
--- a/src/graphics/GraphicsConverter.cpp
+++ b/src/graphics/GraphicsConverter.cpp
@@ -63,7 +63,7 @@ public:
 	SignalType finishedConversion;
 
 	///
-	FileName const & doc_fname_;
+	FileName doc_fname_;
 	///
 	string script_command_;
 	///

Re: SIGSEGV on luatex export #2

2017-04-20 Thread Kornel Benko

Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 

> On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, 
> > > so
> > > I guess it's a different bug:
> > > 1. clear your ~/.lyx-trunk/cache/*
> > > 2. start LyX, new doc
> > > 3. type "info-insert icon whatevernonsense"
> > > 
> > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > 
> > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> > bisect tomorrow if no one beats me to it:
> > 
> >   git bisect start
> >   git bisect good 15fd7920
> >   git bisect bad dbcbf305
> 
> My bisect lead to 244de5d2

This makes sense, because I came to the same commit while investigating the 
crash.
Backtrace gives src/support/FileName.cpp:188
return d->name
(gdb) p d->name
Cannot access memory at address 0x0

(gdb) up
src/graphics/GraphicsConverter.cpp:146
(gdb) p doc_fname_
$1 = (const lyx::support::FileName &) @0x3559560: {
  _vptr.FileName = 0x38ca7d0, 
  d = 0x0
}

(gdb) up
src/graphics/GraphicsConverter.cpp:90

(gdb) p doc_fname
$2 = (const lyx::support::FileName &) @0x3559560: {
  _vptr.FileName = 0x38ca7d0, 
  d = 0x0
}
(gdb) up
(gdb) up
src/graphics/GraphicsCacheItem.cpp:452
(gdb) p doc_file_

$3 = (const lyx::support::FileName &) @0x3559560: {
  _vptr.FileName = 0x38ca7d0, 
  d = 0x0
}
(gdb) up
src/graphics/GraphicsCacheItem.cpp:235


> but I'm not confident in the bisect (for some
> revisions I could reproduce once and then not a separate time. I always
> cleared the cache each time but still had mixed results).
> 
> When git bisect narrowed in on the commits around there, I thought it
> would be 6c920757 since that has to do with icons. But that's not where
> bisect took me.
> 
> So don't take my results too seriously. Hopefully someone else can take
> a look.
> 
> Scott

Kornel

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

Re: SIGSEGV on luatex export #2


On 20/04/2017 19:02, Scott Kostyshak wrote:

My bisect lead to 244de5d2 but I'm not confident in the bisect (for some
revisions I could reproduce once and then not a separate time. I always
cleared the cache each time but still had mixed results).

When git bisect narrowed in on the commits around there, I thought it
would be 6c920757 since that has to do with icons. But that's not where
bisect took me.


perhaps the problem was fixed and later came back ?!?

I'll see whether I can get a decent stack trace...

Thx,

T.

templates handling

2017-04-20 Thread Guenter Milde

Dear LyXers,

background reading for the "reorganize templates folder" ticket, I found an
interesting statement in the Customization guide (5.2.4 Creating templates):


  Templates are created just like usual documents: using LyX. The only
  difference is that usual documents contain all possible settings,
  including the font scheme and the paper size. Usually a user doesn't
  want a template to overwrite his preferred settings for such
  parameters. For that reason, the designer of a template should remove
  the corresponding commands like \font_roman or \papersize from the
  template LyX file. This can be done with any simple text-editor, for
  example vi or notepad.
  
I fully agree with the idea to leave out settings that are not relevant for or
fixed by the template's document class or purpose. 

This may also solve our problem with the default default fonts beeing ugly
bitmaps: Choose LatinModern in the default template and leave out the font
settings in all templates that would use bitmap default fonts.

However:

a) The templates that ship with LyX in lib/templates don't do so, they
   contain all possible settings (at least all font settings).
   
   This may be due to "just saving" after some edit or lyx2lyx inserting
   settings with format conversions -- with the developer doing the edit or
   conversion unaware of the above passage in Customization.lyx
   
b) Documents using a template without settings are *not* filled with a
   user's preferred settings (as stored in templates/defaults.lyx) but with
   the global LyX defaults.
   
Am I missing something? 
Is this a bug?

Günter

Re: SIGSEGV on luatex export #2

On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
> > I guess it's a different bug:
> > 1. clear your ~/.lyx-trunk/cache/*
> > 2. start LyX, new doc
> > 3. type "info-insert icon whatevernonsense"
> > 
> > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> 
> I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> bisect tomorrow if no one beats me to it:
> 
>   git bisect start
>   git bisect good 15fd7920
>   git bisect bad dbcbf305

My bisect lead to 244de5d2 but I'm not confident in the bisect (for some
revisions I could reproduce once and then not a separate time. I always
cleared the cache each time but still had mixed results).

When git bisect narrowed in on the commits around there, I thought it
would be 6c920757 since that has to do with icons. But that's not where
bisect took me.

So don't take my results too seriously. Hopefully someone else can take
a look.

Scott

signature.asc
Description: PGP signature

Re: [LyX/master] BufferParams: get rid of the HSpace class for mathindent as requested by JMarc

2017-04-20 Thread Jean-Marc Lasgouttes


Le 19/04/2017 à 18:15, Jean-Marc Lasgouttes a écrit :

The attached patches (1) revert your patch and (2) use a Length object
instead of HSpace (as well as rename variables with the shorter
mathindent name).

If it is OK with you I will commit these, and then commit a change to
make the indentation visible on screen.


I turns out that I committed it by mistake. Please complain if something 
is wrong.


JMarc

Re: make distcheck: cannot remove '../../po/lyx.pot'

On Thu, Apr 20, 2017 at 04:57:00PM +0200, Jean-Marc Lasgouttes wrote:
> Le 01/07/2016 à 03:44, Scott Kostyshak a écrit :
> > > I just tried 1.15 with Ubuntu 15.10 and I do get the same error. The
> > > mystery remains.
> > 
> > I still see this with current master and Ubuntu 16.04.
> > 
> > Does the following work for anyone on current master?
> > 
> > git reset --hard && git clean -xdf && ./autogen.sh &&
> > ./configure --enable-build-type=pre &&
> > make &&
> > make check &&
> > make distcheck &&
> > echo "GOOD"
> 
> For what is worth, it works for me on ubuntu 17.10.

Thanks for checking. I just ran the set of compilation tests (testing
monolithic, --disable-nls, etc) and everything is working well now.

Scott


signature.asc
Description: PGP signature

Re: make distcheck: cannot remove '../../po/lyx.pot'

2017-04-20 Thread Jean-Marc Lasgouttes


Le 01/07/2016 à 03:44, Scott Kostyshak a écrit :

I just tried 1.15 with Ubuntu 15.10 and I do get the same error. The
mystery remains.


I still see this with current master and Ubuntu 16.04.

Does the following work for anyone on current master?

git reset --hard && git clean -xdf && ./autogen.sh &&
./configure --enable-build-type=pre &&
make &&
make check &&
make distcheck &&
echo "GOOD"


For what is worth, it works for me on ubuntu 17.10.

JMarc

Re: Re-organizing templates and examples folders (#8715)

2017-04-20 Thread Stephan Witt

Am 20.04.2017 um 14:27 schrieb Helge Hafting :
> 
> Den 11. april 2017 19:05, skrev Guenter Milde:
> 
>> * Under Linux, the local templates are in ~/.lyx/templates
>>   I have set this as my templates path in Tools>Settings and
>>   in this dir a symlink to the standard templates.
>>  
> Nice trick - but user friendliness ought to be the default. When LyX is 
> installed without tweaks, "new from template" will let you use the templates 
> that come with LyX (Template button) or the "Documents" button which merely 
> goes to the home folder. There is no easy way to get at custom templates 
> stored in the standard location ~/.lyx/templates/
> 
> I don't know what limitations qt has, is there only two buttons possible on 
> this dialog?

Please consider platforms where no buttons are available at all: Mac OS X and 
Windows.

Stephan

> If so, the "new from template" dialog should have:
> [Std templates]   that go to the system templates as usual
> [Your templates] that go to ~/.lyx/templates/ instead of ~/
> 
> If this isn't possible due to qt constraints, please make [templates] go to 
> ~/.lyx/templates and have tools->reconfigure create the symlink to the system 
> template folder. That way, users will have easy access to both sets of 
> templates without having to set anything up.
> 
> Lyx should be able to make new documents based on private or std. templates, 
> without the user searching for either. And it should not be necessary to 
> tweak the paths either. Tweaking paths is for those who have company 
> templates in something like /mnt/server17/wordprocessing/templates/
> 
> Helge Hafting

Re: Re-organizing templates and examples folders (#8715)

2017-04-20 Thread Helge Hafting


Den 11. april 2017 19:05, skrev Guenter Milde:


* Under Linux, the local templates are in ~/.lyx/templates
   I have set this as my templates path in Tools>Settings and
   in this dir a symlink to the standard templates.
   
   
Nice trick - but user friendliness ought to be the default. When LyX is 
installed without tweaks, "new from template" will let you use the 
templates that come with LyX (Template button) or the "Documents" button 
which merely goes to the home folder. There is no easy way to get at 
custom templates stored in the standard location ~/.lyx/templates/


I don't know what limitations qt has, is there only two buttons possible 
on this dialog?

If so, the "new from template" dialog should have:
 [Std templates]   that go to the system templates as usual
 [Your templates] that go to ~/.lyx/templates/ instead of ~/

If this isn't possible due to qt constraints, please make [templates] go 
to ~/.lyx/templates and have tools->reconfigure create the symlink to 
the system template folder. That way, users will have easy access to 
both sets of templates without having to set anything up.


Lyx should be able to make new documents based on private or std. 
templates, without the user searching for either. And it should not be 
necessary to tweak the paths either. Tweaking paths is for those who 
have company templates in something like 
/mnt/server17/wordprocessing/templates/


Helge Hafting

Re: Re-organizing templates and examples folders (#8715)

2017-04-20 Thread Guenter Milde

On 2017-04-11, Guenter Milde wrote:
> On 2017-04-06, Scott Kostyshak wrote:

>> There is a proposal to reorganize templates and examples folders. If we
>> do want to do it, I think that soon would be a good time.

>> To take a look at the proposal, check out:

>>   http://www.lyx.org/trac/ticket/8715

> Several points:

> * The OP seems to miss the [examples] button in the File>Open dialogue.

The proeblem is, this button is only present in Linux:

UserGuide.lyx:

  Example files This directory will be opened when you use the button
Examples in the File->Open dialog.

Note: The Examples button does not exist when using LyX
on Mac OS and Windows systems.

Customization.lyx: misses this bit and is vague about the dialogue:

  examples/ contains example files that explain how to use some
features. In the file browser, press the Examples button to
get there.

TODO: fix the Customization guide (may wait until we get a consensus on
what to do with the examples).

In comment #1, Jürgen says:

   I do not like the mixing of templates and examples, which serve a very
   different purpose.

Generally, I agree:

Templates:
  provide a starting point for documents,
  store settings for a class of documents.
  https://en.wikipedia.org/wiki/Template_%28word_processing%29

   Templates should leave out irrelevant settings to be
   filled with user defaults.

   --- Customization, 5.2.4 Creating templates

Examples:
  document a LyX feature, layout, or module.

OTOH,

* In LyX, there is no special template file type, every LyX document can
  serve as a template, just open it via File>New from template.

* Also templates can be considered part of the documentation:

   A template acts as a kind of tutorial for your layout, showing how it
   might be used, though containing dummy content.

   --- Customization, 5.2.4 Creating templates

* Examples may serve as templates (especially if there is no on-purpose
  template for a special document class).

Hence we should not merge templates and examples but it makes sense to
have them not too far in the File>New from template dialogue.

Suggestion:

* move examples to lib/doc/examples,
* create (and use) language subdirectories,
* add a menu entry Help>Examples...

* create a symlink SYSDIR/templates/examples -> SYSDIR/doc/examples,
* create a symlink SYSDIR/templates/my_templates -> USERDIR/templates
  (alternatively, set USERDIR/templates as default templates path and
  create a symlink to SYSDIR/templates there),
* create (and use) language subdirectories for templates, too.

* Document the [templates] box in the File>Save as dialogue in the user Guide
  as an easy option to create local templates.

Günter

Re: SIGSEGV on luatex export #2

On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
> I guess it's a different bug:
> 1. clear your ~/.lyx-trunk/cache/*
> 2. start LyX, new doc
> 3. type "info-insert icon whatevernonsense"
> 
> => LyX SIGNAL CAUGHT dialog with std::bad_alloc.

I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
bisect tomorrow if no one beats me to it:

  git bisect start
  git bisect good 15fd7920
  git bisect bad dbcbf305

Scott


signature.asc
Description: PGP signature

Re: beamer editing

2017-04-20 Thread Jürgen Spitzmüller

Am Donnerstag, den 20.04.2017, 09:40 +0200 schrieb Edwin Leuven:
> hello,
> 
> quite some time ago i complained about editing frame content in lyx
> 
> basic frame content is indented and has a standard environment
> 
> a new line  however removes the indent and resets the standard
> environment to frame
> 
> to continue editing one has to re-ident and reset the environment,
> which is imo disruptive and unnecessary
> 
> i think the desired/expected behavior is that  preserves the
> identing and environment
> 
> and that  only resets things if the line is empty
> 
> (just like in itemize) 
> 
> at the time i send in the attached little patch
> 
> i was wondering what you think about the suggested behavior, and
> whether you have some comments on the patch

I think your proposal makes sense at least for the beamer case.

Jürgen

> 
> it would be nice to have this fixed for 2.3
> 
> regards, edwin
> 
> 
> 

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

beamer editing

2017-04-20 Thread Edwin Leuven

hello,

quite some time ago i complained about editing frame content in lyx

basic frame content is indented and has a standard environment

a new line  however removes the indent and resets the standard 
environment to frame

to continue editing one has to re-ident and reset the environment, which is imo 
disruptive and unnecessary

i think the desired/expected behavior is that  preserves the identing 
and environment

and that  only resets things if the line is empty

(just like in itemize) 

at the time i send in the attached little patch

i was wondering what you think about the suggested behavior, and whether you 
have some comments on the patch

it would be nice to have this fixed for 2.3

regards, edwin





depth.diff
Description: Binary data

Re: SIGSEGV on luatex export #2


A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
I guess it's a different bug:
1. clear your ~/.lyx-trunk/cache/*
2. start LyX, new doc
3. type "info-insert icon whatevernonsense"

=> LyX SIGNAL CAUGHT dialog with std::bad_alloc.

T.

On 20/04/2017 09:03, Tommaso Cucinotta wrote:

Hi,

I'm seeing a SIGSEGV in the bug-export-latex-in.txt autotest [1].
Albeit the test doesn't fail, I'm clearly seeing on screen that LyX is showing
the SIGSEGV dialog. Trying a manual repro, it doesn't seem to happen, but
running it in the autotests it does happen all the times.

Anyone might have a clue on what's wrong ?

Thanks,

T.

[1]

TestBegin -dbg files test.lyx > lyx-log.txt 2>&1
KK: \Axinfo-insert icon math-mode\[Return]
KK: \Axbuffer-export luatex\[Return]
KK: \[Tab]\[Return]
TestEnd
Lang C
Assert ! pcregrep -M "support/FileName.cpp .* creating path '/.*/lib/images'" 
lyx-log.txt
Assert ! pcregrep -M 'support/FileName.cpp .* Checksumming 
"/.*/lib/images/.*math-mode.pdf" .*lasted ' lyx-log.txt

SIGSEGV on luatex export