Re: [patch] My first LFUN

[Guillaume Munch]

Le 20/12/2015 22:42, Jean-Marc Lasgouttes a écrit :

Le 17/12/2015 01:36, Guillaume Munch a écrit :

Here's a version with tabular-feature instead of table-modify (and no
change to Shortcuts.lyx given that the docs are now frozen).


A few comments on patches (not all of them for you):
* you still handle inset-modify tabular for documents and of binding
files, right?


I am not sure to understand the question. "Inset-modify tabular" still
exists for the tabular dialog. It does not make much sense to use it for
binding files and documentation for the commands used currently.


Richard, how difficult would it be to use lf2lfun in
lyx2lyx to translate info insets? We do not really know what version of
lfuns we have in lyx files, do we?


I planned to change everything with S when the docs are returned 
before release. Do you think we need a permanent conversion?




* does the lfun2lfun update require a new version for our ui/bind files?

* did you update LFUNS.lyx using the relevant script (I guess you did,
but want to be sure).


Yes



* in the 3rd patch, why don't you return "false" instead of
  case LFUN_TABULAR_FEATURE: {
+if (!isTable()) {
+status.clear();
+status.setUnknown(true);
+return true;
+}


If !isTable(), then we want to ask the enclosing tabular, if exists. Is
replacing the three nested lines with "return false" going to achieve
the same?

Thanks.

Re: [patch] My first LFUN

[Jean-Marc Lasgouttes]

Le 17/12/2015 01:36, Guillaume Munch a écrit :

Here's a version with tabular-feature instead of table-modify (and no
change to Shortcuts.lyx given that the docs are now frozen).


A few comments on patches (not all of them for you):
* you still handle inset-modify tabular for documents and of binding 
files, right? Richard, how difficult would it be to use lf2lfun in 
lyx2lyx to translate info insets? We do not really know what version of 
lfuns we have in lyx files, do we?


* does the lfun2lfun update require a new version for our ui/bind files?

* did you update LFUNS.lyx using the relevant script (I guess you did, 
but want to be sure).


* in the 3rd patch, why don't you return "false" instead of
case LFUN_TABULAR_FEATURE: {
+   if (!isTable()) {
+   status.clear();
+   status.setUnknown(true);
+   return true;
+   }


Note that I only read the poatches, I did not try them out yet.

JMarc

[PATCH] Bug 9907: Master-Child Closing Crash

[Richard Heck]

See http://www.lyx.org/trac/ticket/9907.

Here's a proper patch intended to fix this bug. It actually does a lot
less than it appears to do. The old BufferList::releaseChild(parent,
child) routine did a few different things: First, it checked whether the
child in question was open as a child of some other parent; if not, it
released it; if so, it set its parent to 0. The new patch replaces that
routine with BufferList::isOthersChild, which only does the first of
these things. The other tasks are performed by the caller, depending
upon the return value.

So the change made in Buffer.cpp (should!) actually make no difference
at all.

The advantage is that we can now check, in GuiView::closeBuffer, whether
the child is open as a child of some other Buffer before trying to close it.

Richard

>From d749c635dce01418b8623710d4287d1c9fd62cb3 Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Sun, 20 Dec 2015 11:50:18 -0500
Subject: [PATCH] Fix bug 9907. The problem was that, when closing one Buffer,
 we were closing all of its children, even if they were open as children of
 some other Buffer.

---
 src/Buffer.cpp|  8 ++--
 src/BufferList.cpp| 47 ---
 src/BufferList.h  |  9 +
 src/frontends/qt4/GuiView.cpp | 26 +++-
 4 files changed, 50 insertions(+), 40 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index eac9821..115a542 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -517,8 +517,12 @@ Buffer::~Buffer()
 		Impl::BufferPositionMap::iterator end = d->children_positions.end();
 		for (; it != end; ++it) {
 			Buffer * child = const_cast(it->first);
-			if (theBufferList().isLoaded(child))
-theBufferList().releaseChild(this, child);
+			if (theBufferList().isLoaded(child)) { 
+			 if (theBufferList().isOthersChild(this, child))
+ child->setParent(0);
+			 else
+theBufferList().release(child);
+			}
 		}
 
 		if (!isClean()) {
diff --git a/src/BufferList.cpp b/src/BufferList.cpp
index 68a1e80..ff99a09 100644
--- a/src/BufferList.cpp
+++ b/src/BufferList.cpp
@@ -267,6 +267,28 @@ bool BufferList::exists(FileName const & fname) const
 }
 
 
+bool BufferList::isOthersChild(Buffer * parent, Buffer * child)
+{
+	LASSERT(parent, return false);
+	LASSERT(child, return false);
+	LASSERT(parent->isChild(child), return false);
+	
+	// Does child document have a different parent?
+	Buffer const * parent_ = child->parent();
+	if (parent_ && parent_ != parent)
+		return true;
+	
+	BufferStorage::iterator it = bstore.begin();
+	BufferStorage::iterator end = bstore.end();
+	for (; it != end; ++it) {
+		Buffer * buf = *it;
+		if (buf != parent && buf->isChild(child))
+			return true;
+	}
+	return false;
+}
+
+
 namespace {
 
 struct equivalent_to : public binary_function
@@ -364,31 +386,6 @@ int BufferList::bufferNum(FileName const & fname) const
 }
 
 
-bool BufferList::releaseChild(Buffer * parent, Buffer * child)
-{
-	LASSERT(parent, return false);
-	LASSERT(child, return false);
-	LASSERT(parent->isChild(child), return false);
-
-	// Child document has a different parent, don't close it.
-	Buffer const * parent_ = child->parent();
-	if (parent_ && parent_ != parent)
-		return false;
-
-	BufferStorage::iterator it = bstore.begin();
-	BufferStorage::iterator end = bstore.end();
-	for (; it != end; ++it) {
-		Buffer * buf = *it;
-		if (buf != parent && buf->isChild(child)) {
-			child->setParent(0);
-			return false;
-		}
-	}
-	release(child);
-	return true;
-}
-
-
 void BufferList::changed(bool update_metrics) const
 {
 	BufferStorage::const_iterator it = bstore.begin();
diff --git a/src/BufferList.h b/src/BufferList.h
index 242eff0..690bf6a 100644
--- a/src/BufferList.h
+++ b/src/BufferList.h
@@ -55,13 +55,14 @@ public:
 	/// \return 0 if the Buffer creation is not possible for whatever reason.
 	Buffer * newInternalBuffer(std::string const & s);
 
+	/// Is child a child of some Buffer other than parent?
+	/// NOTE: child must be a child of parent, and both must be non-null.
+	/// Otherwise we assert.
+	bool isOthersChild(Buffer * parent, Buffer * child);
+
 	/// delete a buffer
 	void release(Buffer * b);
 
-	/// Release \p child if it really is a child and is not used elsewhere.
-	/// \return true is the file was closed.
-	bool releaseChild(Buffer * parent, Buffer * child);
-
 	/// Close all open buffers.
 	void closeAll();
 
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 548381b..c2101f3 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -2849,23 +2849,31 @@ bool GuiView::closeBuffer(Buffer & buf)
 		ListOfBuffers::const_iterator it = clist.begin();
 		ListOfBuffers::const_iterator const bend = clist.end();
 		for (; it != bend; ++it) {
-			// If a child is dirty, do not close
-			// without user intervention
-			//FIXME: should we look in other tabworkareas?
 			Buffer * child_buf 

Re: [patch] My first LFUN

[Richard Heck]

On 12/20/2015 06:12 PM, Guillaume Munch wrote:
> Le 20/12/2015 22:42, Jean-Marc Lasgouttes a écrit :
>> Le 17/12/2015 01:36, Guillaume Munch a écrit :
>>> Here's a version with tabular-feature instead of table-modify (and no
>>> change to Shortcuts.lyx given that the docs are now frozen).
>>
>> A few comments on patches (not all of them for you):
>> * you still handle inset-modify tabular for documents and of binding
>> files, right?
>
> I am not sure to understand the question. "Inset-modify tabular" still
> exists for the tabular dialog. It does not make much sense to use it for
> binding files and documentation for the commands used currently.

The problem is that people may have customized bind and ui files that use
"inset-modify tabular". JMarc's question is: Will those commands still work
after your patch?

>> * does the lfun2lfun update require a new version for our ui/bind files?

The answer to this question thus partly depends upon the answer to the
former
one. If the old "inset-modify tabular" commands no longer work, then we
need a
format change of the ui and bind files. Indeed, one might think we
should have a
format change anyway, since the old syntax might now be regarded as
deprecated.

>> Richard, how difficult would it be to use lf2lfun in lyx2lyx to
>> translate
>> info insets? We do not really know what version of lfuns we have in lyx
>> files, do we?
>
> I planned to change everything with S when the docs are returned before
> release. Do you think we need a permanent conversion?

Note that this is now kind of the same question, but concerning the
docs. In this
case, I'm inclined to think that what we need is a format change of the
LyX files.
(In answer to JMarc: Since there's no mapping from LyX formats to LFUN
formats,
we can't use prefs2prefs to fix this.)

If that seems weird: Sometimes format changes aren't really format changes.
Rather, they are like hooks that force lyx2lyx to be run. In this case,
the plan
would be to search for uses of "inset-modify tabular" within InsetInfo and
replace them with the corresponding case of "tabular-modify". Here
again, the
problem is that someone might have used "inset-modify tabular" in their own
files, with InsetInfo. Think e.g. of someone who might have made a set
of LyX
teaching manuals for use in their own group.

Richard

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 17/12/2015 16:50, Guillaume Munch a écrit :

Le 14/12/2015 12:27, Jean-Marc Lasgouttes a écrit :

Le 14/12/2015 12:05, Guillaume Munch a écrit :

You're right, see now second patch attached. It's a fairly simple
change, only adding some information to Georg's displayColAlign(), in
addition to some mechanical refactoring and disabling of horizontal
alignment buttons which were wrongly enabled. See the new commit log.


Thanks for the patches. A couple remarks:
- in switches it would be better to avoid using default:. This way, when
adding a new hull type, we'll get a warning for each un-handled case and
we'll have to think about the right value.


I agree, and thanks for the information. I never know what I am allowed
to expect from c++ compilers, so I tend to imitate the style I find in
the LyX sources...


- if defaultColAlign and defaultColSpace are broken in some way, the
least we shell do is add a FIXME in the source. Deciding what to do with
them would be even better.


Yes: are these data used in output formats different from LaTeX (e.g.
LyXHTML)? Then we should add a FIXME. Otherwise they are useless and we
can remove them.



I concluded that defaultCol* were now superfluous (in addition to
broken), and there already are FIXMEs regarding the alignment in html,
so I removed them in the attached.
>From ddc5488d0a78b1a0a6fc7cced1bc621229b3f1da Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Mon, 14 Dec 2015 01:54:27 +
Subject: [PATCH 1/3] Sanitize InsetMathHull and add a check for mutability in
 LFUN_MATH_MUTATE

The transformation is purely mechanical (apart for the addition of
isMutable()). Remove in particular all comparisons < and >= involving HullType.

Add a guard to make sure that mutate() only operates on types it has been
designed for. Then I figured I could use this new knowledge to give feedback
when math-mutate is not implemented via getStatus(). (To test this, insert a
regexp in Advanced Search & Replace and try to change it into a standard
equation via the contextual menu.)
---
 src/mathed/InsetMath.h   |   3 +-
 src/mathed/InsetMathHull.cpp | 357 +++
 src/mathed/InsetMathHull.h   |   2 +
 3 files changed, 231 insertions(+), 131 deletions(-)

diff --git a/src/mathed/InsetMath.h b/src/mathed/InsetMath.h
index bd72863..deb6915 100644
--- a/src/mathed/InsetMath.h
+++ b/src/mathed/InsetMath.h
@@ -34,7 +34,8 @@ enum HullType {
 	hullFlAlign,
 	hullMultline,
 	hullGather,
-	hullRegexp
+	hullRegexp,
+	hullUnknown
 };
 
 HullType hullType(docstring const & name);
diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 097a344..1fa9fbd 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -79,16 +79,18 @@ namespace {
 	int getCols(HullType type)
 	{
 		switch (type) {
-			case hullEqnArray:
-return 3;
-			case hullAlign:
-			case hullFlAlign:
-			case hullAlignAt:
-			case hullXAlignAt:
-			case hullXXAlignAt:
-return 2;
-			default:
-return 1;
+		case hullEqnArray:
+			return 3;
+
+		case hullAlign:
+		case hullFlAlign:
+		case hullAlignAt:
+		case hullXAlignAt:
+		case hullXXAlignAt:
+			return 2;
+
+		default:
+			return 1;
 		}
 	}
 
@@ -128,28 +130,29 @@ HullType hullType(docstring const & s)
 	if (s == "flalign")   return hullFlAlign;
 	if (s == "regexp")return hullRegexp;
 	lyxerr << "unknown hull type '" << to_utf8(s) << "'" << endl;
-	return HullType(-1);
+	return hullUnknown;
 }
 
 
 docstring hullName(HullType type)
 {
 	switch (type) {
-		case hullNone:   return from_ascii("none");
-		case hullSimple: return from_ascii("simple");
-		case hullEquation:   return from_ascii("equation");
-		case hullEqnArray:   return from_ascii("eqnarray");
-		case hullAlign:  return from_ascii("align");
-		case hullAlignAt:return from_ascii("alignat");
-		case hullXAlignAt:   return from_ascii("xalignat");
-		case hullXXAlignAt:  return from_ascii("xxalignat");
-		case hullMultline:   return from_ascii("multline");
-		case hullGather: return from_ascii("gather");
-		case hullFlAlign:return from_ascii("flalign");
-		case hullRegexp: return from_ascii("regexp");
-		default:
-			lyxerr << "unknown hull type '" << type << "'" << endl;
-			return from_ascii("none");
+	case hullNone:   return from_ascii("none");
+	case hullSimple: return from_ascii("simple");
+	case hullEquation:   return from_ascii("equation");
+	case hullEqnArray:   return from_ascii("eqnarray");
+	case hullAlign:  return from_ascii("align");
+	case hullAlignAt:return from_ascii("alignat");
+	case hullXAlignAt:   return from_ascii("xalignat");
+	case hullXXAlignAt:  return from_ascii("xxalignat");
+	case hullMultline:   return from_ascii("multline");
+	case hullGather: return from_ascii("gather");
+	case hullFlAlign:return from_ascii("flalign");
+	case hullRegexp: return from_ascii("regexp");
+	case hullUnknown:
+	default:
+		lyxerr << "unknown hull 

Re: [patch] My first LFUN

[Guillaume Munch]

Le 20/12/2015 19:28, Jean-Marc Lasgouttes a écrit :

Le 20/12/15 19:49, Guillaume Munch a écrit :

Here's a version with tabular-feature instead of table-modify (and no
change to Shortcuts.lyx given that the docs are now frozen).


It would be nice if somebody could review this before the feature freeze.


I'll try to have a go tomorrow. I've been busy these days.



Thanks

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

[Scott Kostyshak]

On Sat, Dec 19, 2015 at 10:19:59AM -0800, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > It would be nice to fix this so that we can run all of the compilation
> > tests before releasing beta.
> 
> Did you try to bisect? Pavel

Yes I did this for a previous instance of the error. I bisected on two
different computers and got the same commit. I fixed it here: 7c4a1e16

I have no idea why it fixed the error though. And it is not surprising
that another instance of the error (with a different build command)
occurs. I'm not sure it is worth a lot of time to bisect to find another
commit that I don't understand why it would cause the error. Georg has
mentioned that it could be due to some strange timestamp issue, or
possibly an issue with faking permissions. I'm not sure in this case
that a bisect would lead us to the root problem.

Scott


signature.asc
Description: PGP signature

Re: What is our goal for 2.2 regarding the export tests?

[Scott Kostyshak]

On Sat, Dec 19, 2015 at 04:33:42AM -0500, Scott Kostyshak wrote:
> On Sat, Dec 19, 2015 at 10:08:29AM +0100, Kornel Benko wrote:
> 
> > This is meant if we are checking for regression. Yes.
> > But it is better to also check for load, to catch also layout errors.
> > ctest -L 'export|load'
> 
> Good point. I will add this command to the checklist for release
> managers. I am eventually going to clean up my notes and make public a
> checklist for future release managers to follow.

For me the following test fails: 
INVERTED.EXAMPLES_export/examples/he/splash_pdf5_systemF

When I do the export manually, the PDF looks fine (although I do not
know Hebrew).

Günter, does the export succeed for you?

I wonder if this is because I am using an outdated TeX Live.

Scott


signature.asc
Description: PGP signature

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

[Scott Kostyshak]

On Sat, Dec 19, 2015 at 11:41:02AM +0100, Kornel Benko wrote:
> Am Samstag, 19. Dezember 2015 um 05:24:48, schrieb Scott Kostyshak 
> 
> > On Tue, Dec 15, 2015 at 12:28:32PM -0500, Scott Kostyshak wrote:
> > > On Tue, Dec 15, 2015 at 02:20:50PM +0100, Jean-Marc Lasgouttes wrote:
> > > 
> > > > > I have no idea why, but the attached patch seems to fix 'make 
> > > > > distcheck' for me.
> > > > > 
> > > > > Can it go in?
> > > > 
> > > > It is strange that it can fix anything. But it should definitely go
> > > > in.
> > > 
> > > OK it's in at 7c4a1e16.
> > 
> > I am still seeing the error. I don't know if it is another instance of
> > it or the same one. Is there anyone that does not see the error that
> > would be interested in investigating? If so, I will give the precise
> > steps to reproduce.
> > 
> > It would be nice to fix this so that we can run all of the compilation
> > tests before releasing beta.
> > 
> > Scott
> 
> Just a question .. why are you compiling in source? I could not see errors in
>   ./autogen.sh
>   cd build-dir
>   source-dir/configure --enable-build-type=pre --disable-nls
>   make -j12
>   make -j12 check
>   make -j12 distcheck

I now use a build directory and I see the error. There is something
about this bug that it does not surprise me that you cannot reproduce. I
have no idea what's going on.

Scott


signature.asc
Description: PGP signature

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

[Jean-Marc Lasgouttes]

Le 19/12/2015 12:17, Georg Baum a écrit :

This code is executed in build-dir/po, so ../../po/lyx.pot points to the
file in the source tree. lyx.pot exists and is writable, so the only thing I
can imagine is some trickery that tries to forbid writing into the source
tree by faking permissions, but this is beyond my knowledge.


This trickery is the only simple aspect of this thing. The targz is 
unpacked and the source tree is set to read only:


distcheck: dist
case '$(DIST_ARCHIVES)' in \
*.tar.gz*) \
  GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) ;;\
*.tar.bz2*) \
  bzip2 -dc $(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.lz*) \
  lzip -dc $(distdir).tar.lz | $(am__untar) ;;\
*.tar.xz*) \
  xz -dc $(distdir).tar.xz | $(am__untar) ;;\
*.tar.Z*) \
  uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
*.shar.gz*) \
  GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar ;;\
*.zip*) \
  unzip $(distdir).zip ;;\
esac
chmod -R a-w $(distdir)
chmod u+w $(distdir)
mkdir $(distdir)/_build $(distdir)/_build/sub $(distdir)/_inst
chmod a-w $(distdir)
[more ugly code]

JMarc

Re: [LyX/master] Work around bug #9841

[Georg Baum]

I assume that the cited message was supposed to go to the list, so I 
cite it completely.


Am 20.12.2015 um 05:20 schrieb Richard Heck:

On 12/19/2015 05:55 PM, Guillaume Munch wrote:

Le 19/12/2015 10:17, Georg Baum a écrit :

Unfortunately we have a regression now: Both tex2lyx and lyx2lyx output
these parameters in a different order than LyX.

In which sense is it a regression? Where is it important to have the
same order?
Having the same order avoids artificial changes if someone edits a 
document produced by tex2lyx or lyx2lyx. This is mainly important for 
documents under version control, and such a change could create a 
similar merge conflict as the one which should be avoided by the changed 
order. For the same reason all LyX files (docs, examples templates etc) 
should be updated at once to the new format IMHO, so that we do not see 
artificial changes as in b5c693eb0f99a.


Currently, both lyx2lyx and tex2lyx do not produce exactly the same 
files as LyX (there are e.g. insignificant whitespace changes), but some 
work has been done in the past to make the output as similar as 
possible, and we should not throw away this work now by declaring that 
we don't care anymore.



I assume Georg means that the tex2lyx tests will now fail, since there
will be
differences in the order in which these parameters are output. Of course
that can
be fixed by adapting the test files.


The tex2lyx tests do not fail currently, since the output order in 
tex2lyx has not been changed. But you are right, if the order in tex2lyx 
is changed, then the references must be updated, too.


Georg

Also, lyx2lyx might rely on the old order for backward conversion.
Did you check that it still works?

Yes, it does not depend on the order.

This is very difficult, maybe impossible, to know without tests...which
of course
we do not have.

It is a big problem with the lyx2lyx code, one I work hard to correct
along the way,
that people tend to make assumptions about the exact order in which
different lines will
appear, and even how many lines there are between different parameters.
As a result,
even the addition of blank lines where they shouldn't matter can break
lyx2lyx. And, in
the past, has. It isn't sufficient, therefore, to check places in which
output_changes and tracking_changes are actually mentioned in the
lyx2lyx code. Other code might assume
that the line that comes three lines after some other line is this or
that, and now it isn't.

Granted, code that makes such assumptions is inherently fragile and
should have been
written differently. But be that as it may, there's a lot of such code.

I think maybe what we need here is a format change, and lyx2lyx
reversion code that
ensures the old order. Then lyx2lyx code that assumes the old order will
still work.

I should have thought of both these things. At least the latter, since,
as I said, I've had
to deal with such bugs before, and they are not fun.

Richard

Re: [PATCH] three bugfixes

[Jürgen Spitzmüller]

Am Samstag 19 Dezember 2015, 23:35:15 schrieb Guillaume Munch:
> I tested the patch and it does not solve the reported problem. As I
> understand it, it only loads the user preamble from the parent document.
> In my test document, \upharpoonright is still not defined because the
> macros are still not validated, and \texorpdfstring is still not defined
> because the hyperref is still not loaded, so the situation is the same
> as before the patch.

OK, so further (similar) additions are needed.

But I did not see an example document here or on trac, so it is hard to help.

> Let me ask naively, what is the expected difference with unchecking 
> "Select master document"? 

You mean in Document Settings? It assures the document inherits settings from 
the master, even if the master buffer is not opened.

Jürgen

Re: [LyX/master] Amend f441590c

[Jürgen Spitzmüller]

Am Sonntag 20 Dezember 2015, 00:55:39 schrieb Guillaume Munch:
> +/*
>  void GuiLog::on_copyPB_clicked()
>  {
> theClipboard().put(fromqstr(logTB->toPlainText()));
>  }
> +*/
>  
>  
>  Dialog * createGuiLog(GuiView & lv) { return new GuiLog(lv); }
> diff --git a/src/frontends/qt4/GuiLog.h b/src/frontends/qt4/GuiLog.h
> index 8159836..5aa3f60 100644
> --- a/src/frontends/qt4/GuiLog.h
> +++ b/src/frontends/qt4/GuiLog.h
> @@ -34,7 +34,7 @@ public:
>  private Q_SLOTS:
> void updateContents();
> /// copy log to clipboard
> -   void on_copyPB_clicked();
> +   //void on_copyPB_clicked();

Why don't you simply remove this code if it is really unused now?

Jürgen

Re: [LyX/master] Add 3rdparty to source package

[Kornel Benko]

Am Sonntag, 20. Dezember 2015 um 12:10:19, schrieb Peter Kümmel 

> Am 20.12.2015 um 11:29 schrieb Georg Baum:
> > Kornel Benko wrote:
> >
> >> Setting SRC_LIBCHARSET in the patch might be guarded by:
> >> if(UNIX AND NOT MINGW)
> >> endif()
> >> But since I cannot test windows or Mac I don't commit.
> 
> You will see here if it compiles here:
> https://travis-ci.org/syntheticpp/lyx
> 
> >
> > I'd say commit. If relocatable.c is not supposed to be compiled, then it
> > should be removed from the sources, these are stripped down anyway. If this
> > really results in an error on windows then somebody will notice.
> >
> > These libs are only supposed to be built with mingw or MSVC, except
> > hunspell: On linux and OS X they are already provided by the OS. iconv is
> > even part of libc on linux. We should probably split the LYX_3RDPARTY_BUILD
> > switch so that the bundled hunspell can also be used independently from the
> > two other libs.
> 
> So which logic we should use?
> 
> 1. iconv and zlib must not build on Linux
> 2. LYX_3RDPARTY_BUILD triggers only hunspell build and usage on Linux,
> even when there is a system version of hunspell

I committed 2.) for now.

> Or is it better to disable all three libs on Linux?
> Is there any benefit to use the bundled libs?

I do not see the benefit for linux ATM. But it does not harm and maybe in future
we could add some really needed 3rdparty sources.

BTW, shouldn't boost be 3rdparty too?

> Peter

Kornel

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

Re: [LyX/master] Add 3rdparty to source package

[Peter Kümmel]

Am 20.12.2015 um 12:31 schrieb Kornel Benko:

Am Sonntag, 20. Dezember 2015 um 12:10:19, schrieb Peter Kümmel 


Am 20.12.2015 um 11:29 schrieb Georg Baum:

Kornel Benko wrote:


Setting SRC_LIBCHARSET in the patch might be guarded by:
if(UNIX AND NOT MINGW)
endif()
But since I cannot test windows or Mac I don't commit.


You will see here if it compiles here:
https://travis-ci.org/syntheticpp/lyx



I'd say commit. If relocatable.c is not supposed to be compiled, then it
should be removed from the sources, these are stripped down anyway. If this
really results in an error on windows then somebody will notice.

These libs are only supposed to be built with mingw or MSVC, except
hunspell: On linux and OS X they are already provided by the OS. iconv is
even part of libc on linux. We should probably split the LYX_3RDPARTY_BUILD
switch so that the bundled hunspell can also be used independently from the
two other libs.


So which logic we should use?

1. iconv and zlib must not build on Linux
2. LYX_3RDPARTY_BUILD triggers only hunspell build and usage on Linux,
 even when there is a system version of hunspell


I committed 2.) for now.


Or is it better to disable all three libs on Linux?
Is there any benefit to use the bundled libs?


I do not see the benefit for linux ATM. But it does not harm and maybe in future
we could add some really needed 3rdparty sources.

BTW, shouldn't boost be 3rdparty too?


Yes, but I didn't want change too much at once.

But now I've moved boost to 3rdparty.
And updated to 1.60.



Peter

Re: [LyX/master] Work around bug #9841

[Guillaume Munch]

Le 20/12/2015 10:16, Georg Baum a écrit :

I assume that the cited message was supposed to go to the list, so I
cite it completely.

Am 20.12.2015 um 05:20 schrieb Richard Heck:

On 12/19/2015 05:55 PM, Guillaume Munch wrote:

Le 19/12/2015 10:17, Georg Baum a écrit :

Unfortunately we have a regression now: Both tex2lyx and lyx2lyx output
these parameters in a different order than LyX.

In which sense is it a regression? Where is it important to have the
same order?

Having the same order avoids artificial changes if someone edits a
document produced by tex2lyx or lyx2lyx. This is mainly important for
documents under version control, and such a change could create a
similar merge conflict as the one which should be avoided by the changed
order. For the same reason all LyX files (docs, examples templates etc)
should be updated at once to the new format IMHO, so that we do not see
artificial changes as in b5c693eb0f99a.

Currently, both lyx2lyx and tex2lyx do not produce exactly the same
files as LyX (there are e.g. insignificant whitespace changes), but some
work has been done in the past to make the output as similar as
possible, and we should not throw away this work now by declaring that
we don't care anymore.


OK.




I assume Georg means that the tex2lyx tests will now fail, since there
will be
differences in the order in which these parameters are output. Of course
that can
be fixed by adapting the test files.


The tex2lyx tests do not fail currently, since the output order in
tex2lyx has not been changed. But you are right, if the order in tex2lyx
is changed, then the references must be updated, too.

Georg

Also, lyx2lyx might rely on the old order for backward conversion.
Did you check that it still works?

Yes, it does not depend on the order.

This is very difficult, maybe impossible, to know without tests...which
of course
we do not have.

It is a big problem with the lyx2lyx code, one I work hard to correct
along the way,
that people tend to make assumptions about the exact order in which
different lines will
appear, and even how many lines there are between different parameters.
As a result,
even the addition of blank lines where they shouldn't matter can break
lyx2lyx. And, in
the past, has. It isn't sufficient, therefore, to check places in which
output_changes and tracking_changes are actually mentioned in the
lyx2lyx code. Other code might assume
that the line that comes three lines after some other line is this or
that, and now it isn't.

Granted, code that makes such assumptions is inherently fragile and
should have been
written differently. But be that as it may, there's a lot of such code.

I think maybe what we need here is a format change, and lyx2lyx
reversion code that
ensures the old order. Then lyx2lyx code that assumes the old order will
still work.

I should have thought of both these things. At least the latter, since,
as I said, I've had
to deal with such bugs before, and they are not fun.



Thanks for the patient explanations. That starts making too much for a
quick workaround. I would suggest reverting dc016de3.

If what we need is a format change, then it is better to implement the
solution n°3 (attached) described at
.
On the one hand, the format change is very simple. On the other hand, I
do not like to suggest such a change at the last minute, and we should
not do this if anybody has a doubt. I had been counting on a quick
workaround such as dc016de3 to be available, as I was told. But, as I
gathered from the conversation, the proposed change is the most
consensual. It was favoured by Günter and Pavel, it is similar to what
Jean-Marc suggested and also similar in LibreOffice to saving to the
.fodt format.

Notes:
* The GUI can be updated later.
* I do not update the documentation yet, but I checked that the update
completes successfully.
* I made sure that there is not minor difference between lyx, tex2lyx
and lyx2lyx when writing the new parameter (it is always right before
\origin).


Guillaume

>From c25d226afe043ead37151e86b4eb0cf65b12e288 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Sun, 20 Dec 2015 13:08:49 +
Subject: [PATCH 1/3] Revert "Work around bug #9841"

This reverts commit dc016de34eab3fe24d9673a48cabf754bebbadaa.

See discussion at http://mid.gmane.org/n53ar8$1tj$1...@ger.gmane.org
---
 src/BufferParams.cpp | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index e3121c7..dfa13ec 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1274,14 +1274,9 @@ void BufferParams::writeFile(ostream & os, Buffer const * buf) const
 	}
 
 	os << "\\tracking_changes " << convert(track_changes) << '\n'
+	   << "\\output_changes " << convert(output_changes) << '\n'
 	   << "\\html_math_output " << html_math_output << '\n'
 	   << "\\html_css_as_file " << html_css_as_file << '\n'
-		// 

Re: [patch] My first LFUN

[Guillaume Munch]

Le 17/12/2015 00:36, Guillaume Munch a écrit :

Le 16/12/2015 13:30, Jean-Marc Lasgouttes a écrit :

Le 11/12/2015 23:36, Guillaume Munch a écrit :

Dear list,


Following the discussions in , here
are a series of patches meant to address #9794 (inset-modify tabular
commands are incorrectly disabled) and #4189 (Edit->Rows not
shown when in mathed insert).


Dear Guillaume,

I do not have time right now to look at the patch, but I do not like the
'tricks' to avoid renaming icons. The easiest way out would probably be
to rename to the original tabular-features LFUN name.



Here's a version with tabular-feature instead of table-modify (and no
change to Shortcuts.lyx given that the docs are now frozen).




It would be nice if somebody could review this before the feature freeze.


Guillaume

Re: [LyX/master] Work around bug #9841

[Richard Heck]

On 12/20/2015 01:45 PM, Guillaume Munch wrote:
>
> If what we need is a format change, then it is better to implement the
> solution n°3 (attached) described at
> .
> On the one hand, the format change is very simple. On the other hand, I
> do not like to suggest such a change at the last minute, and we should
> not do this if anybody has a doubt. I had been counting on a quick
> workaround such as dc016de3 to be available, as I was told. But, as I
> gathered from the conversation, the proposed change is the most
> consensual. It was favoured by Günter and Pavel, it is similar to what
> Jean-Marc suggested and also similar in LibreOffice to saving to the
> .fodt format.
>
> Notes:
> * The GUI can be updated later.
> * I do not update the documentation yet, but I checked that the update
> completes successfully.
> * I made sure that there is not minor difference between lyx, tex2lyx
> and lyx2lyx when writing the new parameter (it is always right before
> \origin).

No opinion on the substantive question.

Richard

Re: [patch] My first LFUN

[Richard Heck]

On 12/16/2015 07:36 PM, Guillaume Munch wrote:
> Le 16/12/2015 13:30, Jean-Marc Lasgouttes a écrit :
>> Le 11/12/2015 23:36, Guillaume Munch a écrit :
>>> Dear list,
>>>
>>>
>>> Following the discussions in ,
>>> here
>>> are a series of patches meant to address #9794 (inset-modify tabular
>>> commands are incorrectly disabled) and #4189 (Edit->Rows not
>>> shown when in mathed insert).
>>
>> Dear Guillaume,
>>
>> I do not have time right now to look at the patch, but I do not like the
>> 'tricks' to avoid renaming icons. The easiest way out would probably be
>> to rename to the original tabular-features LFUN name.
>>
>
> Here's a version with tabular-feature instead of table-modify (and no
> change to Shortcuts.lyx given that the docs are now frozen).

I try not to mess with tabular stuff, since I almost never use tables.

Richard

Re: [LyX/master] Add 3rdparty to source package

[Georg Baum]

Pavel Sanda wrote:

> I guess this is related, after running autogen.sh:
> 
> 3rdparty/libiconv/Makefile.am: error: object 'relocatable.$(OBJEXT)'
> created by '1.14/libcharset/lib/relocatable.c' and
> '1.14/lib/relocatable.c' Makefile:445: recipe for target 'Makefile.in'
> failed make: *** [Makefile.in] Error 1

This is strange. When I run make it does not descend into 3rdparty, since
this directory is not listed in the SUBDIRS variable in top level 
Makefile.am. This is the intended behaviour.

Did you run configure after autogen.sh? I assume the error happens when 
calling make?


Georg

Re: [LyX/master] Add 3rdparty to source package

[Georg Baum]

Kornel Benko wrote:

> Setting SRC_LIBCHARSET in the patch might be guarded by:
> if(UNIX AND NOT MINGW)
> endif()
> But since I cannot test windows or Mac I don't commit.

I'd say commit. If relocatable.c is not supposed to be compiled, then it 
should be removed from the sources, these are stripped down anyway. If this 
really results in an error on windows then somebody will notice.

These libs are only supposed to be built with mingw or MSVC, except 
hunspell: On linux and OS X they are already provided by the OS. iconv is 
even part of libc on linux. We should probably split the LYX_3RDPARTY_BUILD 
switch so that the bundled hunspell can also be used independently from the 
two other libs.


Georg

Re: [LyX/master] Add 3rdparty to source package

[Kornel Benko]

Am Sonntag, 20. Dezember 2015 um 11:29:59, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Setting SRC_LIBCHARSET in the patch might be guarded by:
> > if(UNIX AND NOT MINGW)
> > endif()
> > But since I cannot test windows or Mac I don't commit.
> 
> I'd say commit. If relocatable.c is not supposed to be compiled, then it 
> should be removed from the sources, these are stripped down anyway. If this 
> really results in an error on windows then somebody will notice.

OK

> These libs are only supposed to be built with mingw or MSVC, except 
> hunspell: On linux and OS X they are already provided by the OS. iconv is 
> even part of libc on linux. We should probably split the LYX_3RDPARTY_BUILD 
> switch so that the bundled hunspell can also be used independently from the 
> two other libs.
> 

So, if we disable iconv and zlib from building on UNIX we were don too.
I try it this way. This does not effect windows, so it should be safe.

> Georg

Kornel

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

Re: why Babel with dvi3 (LuTeX)?

[Guenter Milde]

On 2015-12-19, Jürgen Spitzmüller wrote:
> Am Mittwoch 16 Dezember 2015, 20:35:27 schrieb Guenter Milde:
>> This should be the same for any export using Unicode fonts, however a look
>> in the source pane shows, that with DVI (LuaTeX), the export still uses
>> Babel, not Polyglossia.

> Probably an oversight. I agree that polyglossia should be preferred now for 
> all LuaTeX ouput (with fontspec).

This means we only have to check for "useNonTeXFonts" 
(polyglossia is already used for all XeTeX output).

Günter

Re: [LyX/master] Add 3rdparty to source package

[Peter Kümmel]

Am 20.12.2015 um 11:29 schrieb Georg Baum:

Kornel Benko wrote:


Setting SRC_LIBCHARSET in the patch might be guarded by:
if(UNIX AND NOT MINGW)
endif()
But since I cannot test windows or Mac I don't commit.


You will see here if it compiles here:
https://travis-ci.org/syntheticpp/lyx



I'd say commit. If relocatable.c is not supposed to be compiled, then it
should be removed from the sources, these are stripped down anyway. If this
really results in an error on windows then somebody will notice.

These libs are only supposed to be built with mingw or MSVC, except
hunspell: On linux and OS X they are already provided by the OS. iconv is
even part of libc on linux. We should probably split the LYX_3RDPARTY_BUILD
switch so that the bundled hunspell can also be used independently from the
two other libs.


So which logic we should use?

1. iconv and zlib must not build on Linux
2. LYX_3RDPARTY_BUILD triggers only hunspell build and usage on Linux,
   even when there is a system version of hunspell

Or is it better to disable all three libs on Linux?
Is there any benefit to use the bundled libs?

Peter

Re: origin again

[Jean-Marc Lasgouttes]

Le 14/12/2015 22:04, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


Would it make sens to add a parametr \is_lyx_doc to our fileformat? We
could decide to do lots of interesting things (like have all relative
paths be relative to lib/doc) to files declared this way.


I am not sure. The whole purpose of \origin is to support the case when
somebody copies a file to a different location outside of LyX (instead of
using "Save As" in LyX, which adjusts all paths correctly). If we now
introduce a setting \is_lyx_doc then we would need to reset this setting
automatically on loading. Otherwise the image references of a document that
was copied from the LyX doc folder to some other location would be wrong.



The
documentor's toolbar could also magically kick in when editing such a
file (in non readonly mode).


This would be possible already, by testing for \origin starting with
"/systemlyxdir".


I really do not like that this /systemlyxdir thing has to be set on 
install by mofiying the file and that this setting is not accessible 
from the GUI. I'd prefer a scheme where the document is explicitly 
marked as lyxdoc and is handled differently depending on whether it is 
in its natural place or not. That would smell less like black magick.



JMarc

Raspberry Pi 2 scroll speed

[Peter Kümmel]

Recently I gave away the computer which I've used when I was
very busy on LyX. It was an Athlon XP 2GHz singlecore.

I was interested how the hardware progress looks like from
the LyX perspective, means the time needed to scroll
to the end of the reference manual:

Athlon XP 2GHz: 19s (< full HD)
Haswell 4Ghz  :  8s (full HD window)
Haswell 4Ghz  :  3s (4k fullscreen)
Raspberry Pi 2: 34s (Ubuntu Mate, full HD)

Especially I was in interested in the Raspberry Pi 2 numbers,
and it looks like the Rasp could at least be used for editing
lyx files.

Peter

Re: change loading of packages to address #9884 or revert or nothing?

[Jürgen Lange]

I prefer: 1. revert 0bf8b8a1.
The reason is, that most of my documents are otherwise not compatible with  
2.2.0 anymore. So I will be stuck to 2.1.4 forever.

Re: [PATCH] three bugfixes

[Richard Heck]

On 12/20/2015 09:42 AM, Guillaume Munch wrote:
> Le 20/12/2015 04:43, Richard Heck a écrit :
>> On 12/19/2015 06:35 PM, Guillaume Munch wrote:
>>>
>>> Let me ask naively, what is the expected difference with unchecking
>>> "Select master document"?
>>
>> I assume you mean "Select default master document"?
>>
>>> (apart from the fact that we need to close the master document and
>>> reopen the child after this, which is a bug obviously, and the fact
>>> that the former parent document is forgotten on reopening, making it
>>> unconvenient to re-enable)
>>
>> I don't think it is a bug. I think perhaps you are misunderstanding the
>> purpose of this setting.
>>
>> Having a *default* master makes it the case that, whenever you open this
>> document directly, it causes the default master to be opened, and for
>> the document you are actually opening to be opened as a child (or
>> grandchild, or ) of that document. This makes sense e.g. for files
>> that are chapters of books: When you edit the chapter, you want it to be
>> edited as a chapter of the book, not as a standalone file. Note that
>> this does *not* mean the same file cannot appear as children of other
>> masters. What it means, in effect, is that the file cannot be edited as
>> a standalone document.
>>
>> But there are other files that can function as children of different
>> masters and that one does want to be able to edit as standalone
>> documents. Or a file that is always used as a child but that it doesn't
>> make sense to associate with a default master. An example of the latter
>> from my own use would be a file of math macros I use in various
>> documents.
>>
>> So, with all that said, suppose a default master was previously selected
>> and one decides to remove that setting. Nothing else does *or should*
>> happen at that time. If the document is currently open as a child (which
>> it will be), then it must remain open as a child. The only other option
>> would be automatically to close the current master, and all of its
>> children, and re-open this document standalone. But that would be
>> totally wrong. Simply saying "I don't want this document any longer, by
>> default, to be a child of some other document" can't also mean: Oh, and
>> by the way, please also close the entire document set of which this was
>> a part, and then re-open this one. We aren't saying this document isn't
>> part of that document set, only that it shouldn't by default be
>> considered part of it. The same goes if one were to change what the
>> default master is.
>>
>> I think it is very unclear what to do here. I think it's a good idea of
>> Jurgen's to allow selection of whether to use the master's params or our
>> own. But I'd add that it would also make sense to allow the child's
>> params to be added to the master's. Consider, again, a file of my
>> favorite math macros. Maybe there are modules that need to be used with
>> these, or some preamble code, and one would think one should be able to
>> indicate those in the macro file and have them always be used when that
>> file is used in some other document. I can imagine thinking that this
>> should be the default behavior when a default master is defined, though
>> I'm not sure about that.
>>
>
>
> Yes, all this parent/child relationship seems quite complicated and ad
> hoc. While testing what would happen when a document has two parents, I
> found the following crash: .

The multi-parent problem has caused crashes before. I'll have a look at
this one.

Richard

Script to cross-compile for Linux

[Peter Kümmel]

I added a script for cross-compiling for Windows.

development/cmake/scripts/xmingw

'xmingw' Must be called from a build directory with
the path to the LyX code.

Mingw needs to be installed. On Ubuntu I assume the package
gcc-mingw-w64-i686 is enough.

The script download a pre-compiled Qt 5.5.1 version, and starts
compiling.

Peter

Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 20/12/2015 11:28, Jürgen Spitzmüller a écrit :

Am Samstag 19 Dezember 2015, 23:35:15 schrieb Guillaume Munch:

I tested the patch and it does not solve the reported problem. As I
understand it, it only loads the user preamble from the parent document.
In my test document, \upharpoonright is still not defined because the
macros are still not validated, and \texorpdfstring is still not defined
because the hyperref is still not loaded, so the situation is the same
as before the patch.


OK, so further (similar) additions are needed.

But I did not see an example document here or on trac, so it is hard to help.


I added test documents here: . I am 
not pushing for a solution to be found before 2.2.0, since it seems to 
require discussions. Thanks for your help so far.


Guillaume

Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 20/12/2015 04:43, Richard Heck a écrit :

On 12/19/2015 06:35 PM, Guillaume Munch wrote:


Let me ask naively, what is the expected difference with unchecking
"Select master document"?


I assume you mean "Select default master document"?


(apart from the fact that we need to close the master document and
reopen the child after this, which is a bug obviously, and the fact
that the former parent document is forgotten on reopening, making it
unconvenient to re-enable)


I don't think it is a bug. I think perhaps you are misunderstanding the
purpose of this setting.

Having a *default* master makes it the case that, whenever you open this
document directly, it causes the default master to be opened, and for
the document you are actually opening to be opened as a child (or
grandchild, or ) of that document. This makes sense e.g. for files
that are chapters of books: When you edit the chapter, you want it to be
edited as a chapter of the book, not as a standalone file. Note that
this does *not* mean the same file cannot appear as children of other
masters. What it means, in effect, is that the file cannot be edited as
a standalone document.

But there are other files that can function as children of different
masters and that one does want to be able to edit as standalone
documents. Or a file that is always used as a child but that it doesn't
make sense to associate with a default master. An example of the latter
from my own use would be a file of math macros I use in various documents.

So, with all that said, suppose a default master was previously selected
and one decides to remove that setting. Nothing else does *or should*
happen at that time. If the document is currently open as a child (which
it will be), then it must remain open as a child. The only other option
would be automatically to close the current master, and all of its
children, and re-open this document standalone. But that would be
totally wrong. Simply saying "I don't want this document any longer, by
default, to be a child of some other document" can't also mean: Oh, and
by the way, please also close the entire document set of which this was
a part, and then re-open this one. We aren't saying this document isn't
part of that document set, only that it shouldn't by default be
considered part of it. The same goes if one were to change what the
default master is.

I think it is very unclear what to do here. I think it's a good idea of
Jurgen's to allow selection of whether to use the master's params or our
own. But I'd add that it would also make sense to allow the child's
params to be added to the master's. Consider, again, a file of my
favorite math macros. Maybe there are modules that need to be used with
these, or some preamble code, and one would think one should be able to
indicate those in the macro file and have them always be used when that
file is used in some other document. I can imagine thinking that this
should be the default behavior when a default master is defined, though
I'm not sure about that.




Yes, all this parent/child relationship seems quite complicated and ad
hoc. While testing what would happen when a document has two parents, I
found the following crash: .


Guillaume

[CRASH] Master-Child Closing Crash in Master

[Richard Heck]

On 12/20/2015 09:51 AM, Richard Heck wrote:
> On 12/20/2015 09:42 AM, Guillaume Munch wrote:
>> Yes, all this parent/child relationship seems quite complicated and ad
>> hoc. While testing what would happen when a document has two parents, I
>> found the following crash: .
> The multi-parent problem has caused crashes before. I'll have a look at
> this one.

Recipe from bug:

 1. open master1.lyx and master2.lyx at the same time (which both have
child1.lyx as a child)
 2. make dummy modifications to master1.lyx, master2.lyx and child1.lyx
 3. close master2.lyx, don't save
 4. close master1.lyx, enjoy SIGSEGV

So the immediate problem is that the child gets closed with master2.
When we go to close master1, it isn't there, and we get a SIGSEV.

This is not unlike bug #6603.

Consider a different case: Where we just switch between tabs. In this
case, we get a focusInEvent and, as a result, run updateBuffer, which
eventually runs InsetInclude::loadIfNeeded. This guarantees that the
child is there. When we return to master1 after closing master2,
however, we do not get that signal, and we do not run updateBuffer.

This happens only if we close master2 using the X on the tab. If you
close it using the menu, then updateBuffer gets run. The reason for the
difference is that closing using the X does not activate the dispatch
machinery.

This also only happens if we are currently editing master1 when we close
master2. If we are editing master2 itself, then we get the focusInEvent
when we go to master1. But if we were already editing master1, then we
do not get a focusInEvent.

We also only get the crash if the parent of the child is currently set
as master2. If it's instead master1, then the child does not get closed
but only hidden.

So, under these specific circumstances, updateBuffer never gets run when
we return to master1, so the child is never re-loaded.

One solution is to figure out somewhere updateBuffer can be run.

Another solution would be to check somewhere whether this particular
child is also the child of some other buffer before closing it. The
comment before GuiView::closeWorkArea says:

// We only want to close the buffer if it is not visible in other workareas
// of the same view, nor in other views, and if this is not a child

Unfourtunately, this never gets checked for children that are getting
closed along with the master.

Likely other bug: When we switch from master1 to master2, we do NOT
reset the parent of the child. It seems to me we should do so, probably
in InsetInclude::loadIfNeeded.

Richard

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Thu, Dec 17, 2015 at 06:57:23PM +, Guillaume Munch wrote:

> Le 12/12/2015 09:47, Enrico Forestieri a écrit :
> >On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote:
> >>Le 11/12/2015 22:47, Enrico Forestieri a écrit :
> >>>On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote:
> >>>
> • Defect: The following character (parbreak separator) is not a line
>    break (the symbol is misleading). Obtained with Enter Enter Enter.
> >>>
> >>>It breaks a line and introduces a blank line afterwards. Here an
> >>>unobtrusive symbol is required (because it is also used for other
> >>>reasons explained in the removed documentation) and it is not simple
> >>>deciding what to use.
> >>
> >>Well in that case I find obtrusive that it looks so close to a usual and
> >>common linebreak inset.
> >
> >Initially, I used a different color, but this was also criticized...
> >As I said, any suggestion is welcome, but see below.
> >
> >>>I thought that using the same symbol you find on
> >>>the Enter key could convey this info. The symbol is heavier than the
> >>>line break symbol and easily distinguishable from it.
> >>
> >>I agree that after having learned about it, I could distinguish them.
> >>This is going to confuse users nevertheless.
> >
> >Any change is going to confuse initially. Then one gets accustomed to it.
> 
> Of course when there is a change one must get accustomed to it. But I
> was speaking of the fact that it is a symbol already used, which is
> worse.

Yes, I think I got it, no need to repeat it. As regards the fact that it
is the same symbol, let me point out that unicode symbols very similar in
shape (as an example: ↩↲↵⤶⏎) are considered to be different symbols.
Moreover, you also say that they can be distinguished.

> >>>You are welcome to propose suggestions.
> >>
> >>Yes. I suggest something that conveys the meaning, rather than the
> >>output in the LaTeX source. What is the meaningful purpose of this new
> >>separator? As I understand it at the moment, a variation on the
> >>horizontal bar of the plain separator would be better.
> >
> >Take into account that this symbol is also going to be output at the
> >end of (possibly many) lines (where previously LyX was outputting a blank
> >line), maybe in between of enumeration environments or the likes, so that
> >a horizontal bar would be very obtrusive (at least to me). Moreover, I
> >think it would cause still major confusion, as this could be exchanged as
> >an environment separator (while this would be his function only when it is
> >alone on a line).
> 
> Do you mean that you expect the parbreak separator to be used often on
> purpose, instead of a plain separator, not just as the result of a
> conversion 2.1 -> 2.2 ?

It is annoying repeating again all discussions made at the time those
insets were introduced, but let's do it. There was consensus that the
--Separator-- layout should have been dropped and something else adopted
in its place. The output should have not changed. So, as the Separator
layout was introducing a blank line after itself, the new inset come in two
versions, one not introducing a blank line and the other one introducing
it. In this way, using the parbreak separator as the default one, I was
hoping to avoid complaints. There is no provision for introducing this
separator from the gui and it should be introduced only when needed. It is
only introduced when pressing Enter at the beginning of a Standard layout
immediately following a non-standard one. In this way, it allows to
reintroduce the same environment in an intuitive way and exactly mimics
the behavior of the old Separator layout. If this is not deemed important,
then letting always introduce the plain separator is very simple. However,
when converting old documents, the parbreak separator should be used in
place of the Separator layout. So, I think that it might be more confusing
using two different versions for the same purpose.

> Maybe I just fail to see its purpose and in particular why it is more
> important than the plain separator.

It is not more important. I hope the above helps clarifying it.

> >This symbol is essentially representing a latex blank
> >line and I find its actual shape the best way to convey this concept. For
> >example, this is how a blank line would be represented in a word processor
> >when you ask to also show non-printable characters.
> 
> This makes no sense to me. In a word processor this symbol would
> represent a new line in the final output, and this corresponds to the
> new line inset in LyX.

And a newline symbol all alone on the line represents a blank line.

> What about a shortened plain separator lowered to the baseline with a
> small bar on the end, in other words:
> * A bottom right corner ⌟ but elongated (notice that this is Unicode 1.1
> and could therefore be used directly, but misses the "elongated" part)
> * Something similar to the caracters ⨼ or ⏗ but lowered to the baseline
> (and 

[PATCH] Re: [CRASH] Master-Child Closing Crash in Master

[Richard Heck]

On 12/20/2015 11:48 AM, Richard Heck wrote:
> On 12/20/2015 09:51 AM, Richard Heck wrote:
>> On 12/20/2015 09:42 AM, Guillaume Munch wrote:
>>> Yes, all this parent/child relationship seems quite complicated and ad
>>> hoc. While testing what would happen when a document has two parents, I
>>> found the following crash: .
>> The multi-parent problem has caused crashes before. I'll have a look at
>> this one.
>
> Recipe from bug:
>
>  1. open master1.lyx and master2.lyx at the same time (which both have
> child1.lyx as a child)
>  2. make dummy modifications to master1.lyx, master2.lyx and child1.lyx
>  3. close master2.lyx, don't save
>  4. close master1.lyx, enjoy SIGSEGV
>
> So the immediate problem is that the child gets closed with master2.
> When we go to close master1, it isn't there, and we get a SIGSEV.
>
> This is not unlike bug #6603.
>
> Consider a different case: Where we just switch between tabs. In this
> case, we get a focusInEvent and, as a result, run updateBuffer, which
> eventually runs InsetInclude::loadIfNeeded. This guarantees that the
> child is there. When we return to master1 after closing master2,
> however, we do not get that signal, and we do not run updateBuffer.
>
> This happens only if we close master2 using the X on the tab. If you
> close it using the menu, then updateBuffer gets run. The reason for
> the difference is that closing using the X does not activate the
> dispatch machinery.
>
> This also only happens if we are currently editing master1 when we
> close master2. If we are editing master2 itself, then we get the
> focusInEvent when we go to master1. But if we were already editing
> master1, then we do not get a focusInEvent.
>
> We also only get the crash if the parent of the child is currently set
> as master2. If it's instead master1, then the child does not get
> closed but only hidden.
>
> So, under these specific circumstances, updateBuffer never gets run
> when we return to master1, so the child is never re-loaded.
>
> One solution is to figure out somewhere updateBuffer can be run.
>
> Another solution would be to check somewhere whether this particular
> child is also the child of some other buffer before closing it. The
> comment before GuiView::closeWorkArea says:
>
> // We only want to close the buffer if it is not visible in other
> workareas
> // of the same view, nor in other views, and if this is not a child
>
> Unfourtunately, this never gets checked for children that are getting
> closed along with the master.

The attached patch is really proof of concept. There are some not so
nice things about it, namely, that it asks whether to save the child,
which it doesn't need to do, since the child will stay open. Probably
the right thing to do is factor out some "Am I a child of some other
buffer?" routine from the current BufferList::releaseChild method and
use that somewhere.

> Likely other bug: When we switch from master1 to master2, we do NOT
> reset the parent of the child. It seems to me we should do so,
> probably in InsetInclude::loadIfNeeded.

It seems we do this when we have to reload the child, but not when it is
already loaded. It is easy to do this, as in the attached. The downside
to doing it this way is that parent of a child that is included multiple
times will now be set to whatever the parent is the last time it is
included. I don't expect this is a problem, but it could change some
behavior somewhere. Currently, the parent will be set to whatever it is
the first time the file is included. Multiple inclusions aren't handled
all that cleanly anyway, though.

Richard

>From 9edf06bed497c09e18c2d035ad4d697344ce0dfd Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Sun, 20 Dec 2015 11:50:18 -0500
Subject: [PATCH] Basic idea for fixing child crash.

---
 src/BufferList.cpp|  4 ++--
 src/frontends/qt4/GuiView.cpp | 13 -
 src/frontends/qt4/GuiView.h   |  4 ++--
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/src/BufferList.cpp b/src/BufferList.cpp
index 68a1e80..ec6a9a1 100644
--- a/src/BufferList.cpp
+++ b/src/BufferList.cpp
@@ -366,9 +366,9 @@ int BufferList::bufferNum(FileName const & fname) const
 
 bool BufferList::releaseChild(Buffer * parent, Buffer * child)
 {
-	LASSERT(parent, return false);
+	// LASSERT(parent, return false);
 	LASSERT(child, return false);
-	LASSERT(parent->isChild(child), return false);
+	LASSERT(!parent || parent->isChild(child), return false);
 
 	// Child document has a different parent, don't close it.
 	Buffer const * parent_ = child->parent();
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 548381b..f80aae5 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -2812,7 +2812,7 @@ bool GuiView::closeWorkAreaAll()
 }
 
 
-bool GuiView::closeWorkArea(GuiWorkArea * wa, bool close_buffer)
+bool GuiView::closeWorkArea(GuiWorkArea * wa, bool close_buffer, 

Re: [patch] My first LFUN

[Jean-Marc Lasgouttes]

Le 20/12/15 19:49, Guillaume Munch a écrit :

Here's a version with tabular-feature instead of table-modify (and no
change to Shortcuts.lyx given that the docs are now frozen).


It would be nice if somebody could review this before the feature freeze.


I'll try to have a go tomorrow. I've been busy these days.

JMarc

Re: [LyX/master] Add 3rdparty to source package

[Pavel Sanda]

Georg Baum wrote:
> Did you run configure after autogen.sh? I assume the error happens when 
> calling make?

Yes, also there is error when calling configure I did not catch before.
config.status: creating Makefile
config.status: creating lyx.1
config.status: creating 3rdparty/Makefile
config.status: creating 3rdparty/boost/Makefile
config.status: creating 3rdparty/hunspell/Makefile
config.status: error: cannot find input file: `3rdparty/libiconv/Makefile.in'

P

Re: [LyX/master] Add 3rdparty to source package

[Peter Kümmel]

Am 20.12.2015 um 21:01 schrieb Pavel Sanda:

Georg Baum wrote:

Did you run configure after autogen.sh? I assume the error happens when
calling make?




Here  3rdparty/libiconv/Makefile.in  is already generated by autogen.sh.
Maybe some old files in the source tree?


Yes, also there is error when calling configure I did not catch before.
config.status: creating Makefile
config.status: creating lyx.1
config.status: creating 3rdparty/Makefile
config.status: creating 3rdparty/boost/Makefile
config.status: creating 3rdparty/hunspell/Makefile
config.status: error: cannot find input file: `3rdparty/libiconv/Makefile.in'

P