date:20151023


Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial effort
at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).



Guillaume

Re: Update on the patches


Le 23/10/2015 09:54, Jean-Marc Lasgouttes a écrit :

Le 20/10/2015 19:23, Guillaume Munch a écrit :

http://www.emacswiki.org/emacs/SmartTabs


Indeed, thanks. Do you use it?

JMarc




Not yet because it does not seem straightforward to install here, but I 
am convinced that Georg's solution is the best and there is no more 
excuse not to do it, so yes, I will eventually. If you have any tip for 
installing it on Ubuntu without effort, please tell me.



Guillaume

Re: Regression in lyx2lyx box alignment


Le 22/10/2015 21:03, Georg Baum a écrit :

Le 20/10/2015 23:46, Uwe Stöhr a écrit :

Georg, attached are 2 documents, one created with LyX 2.1. where I used
the paragraph settings to center, one created with LyX 2.2. You see the
difference: The Paragraph-alignment added a paragraph of course leading
to whitespace one doesn't want in boxes.


Thanks, this was the kind of information I was missing.


So in some sense the goal is to allow horizontal alignment in parbox 
like can be done in makebox. It should actually be easy to have the 
makebox alignment case show on screen as WYSIWYM, I'll have a look at it.



As far as I understand the different boxes, it is possible to determine the
wanted behaviour automatically, so 3/ would be overkill IMHO. However, I am
pretty sure that the setting would depend on the box parameters, so some
research work is still needed.

Such a change would be a file format change (since it would change the
amount of whitespace of existing documents), however a different one than
489 which we were discussing before. Since nobody indicated interest in
working on this so far, and Uwe is abroad again, I think we should postpone
this. Unless somebody comes up with new information, or I get a veto by
Scott, I will implement solution 2) of my previous message tomorrow, i.e.
reverting the alignment handling in InsetBox.cpp (+ the corresponding
changes in the enable/disable GUI logic, which I forgot to mention in the
previous message).


This is OK with me.

JMarc

Re: Update on the patches


Le 20/10/2015 19:23, Guillaume Munch a écrit :

http://www.emacswiki.org/emacs/SmartTabs


Indeed, thanks. Do you use it?

JMarc

Re: Where is the script that posts to lyx-cvs?


Le 20/10/2015 00:46, Richard Heck a écrit :

It's the file
/home/git/repositories/lyx.git/hooks/post-receive-email.py, which is a
symbolic link from
/home/git/repositories/lyx.git/hooks/post-receive-email. Configuration
info for that file is in /home/git/repositories/lyx.git/config.


Thanks. It is a bit difficult for me to understand what the code does, 
though... Anyway, I propose that lyx-cvs just accepts all messages 
coming from lyx.lyx.org. Would that be OK?


JMarc

Re: Where is the script that posts to lyx-cvs?


On 10/23/2015 04:56 AM, Jean-Marc Lasgouttes wrote:

Le 20/10/2015 00:46, Richard Heck a écrit :

It's the file
/home/git/repositories/lyx.git/hooks/post-receive-email.py, which is a
symbolic link from
/home/git/repositories/lyx.git/hooks/post-receive-email. Configuration
info for that file is in /home/git/repositories/lyx.git/config.


Thanks. It is a bit difficult for me to understand what the code does, 
though... Anyway, I propose that lyx-cvs just accepts all messages 
coming from lyx.lyx.org. Would that be OK?


I think that would probably be fine, though if there is something else 
you were considering, I can have a look at the script. I agree it is a 
bit convoluted, but I had to adapt some of it a while back to get 
separate commit messages for different commits pushed at the same time.


Richard

Re: [PATCH] Re: Regression in lyx2lyx box alignment


On 10/23/2015 11:33 AM, Jean-Marc Lasgouttes wrote:

Le 23/10/2015 11:21, Jean-Marc Lasgouttes a écrit :

Le 19/10/2015 21:46, Georg Baum a écrit :
I found another reason for removal: The display in LyX does only 
consider
the paragraph alignment, so if you set that to left (which means 
that the
paragraph does not output any alignment command), and set it so 
something
else than left in the box, the display in LyX will be wrong. Fixing 
this

would probably result in ugly, hard to maintain code.


Actually fixing this for LR boxes (so-called makebox in the code) is not
difficult because we have the framework for table cells already. I
propose to put that in master. Would it be OK?


Note that this is orthogonal with Georg's proposed fix.


Looked OK to me...

rh

Re: Changebars


Le 23/10/2015 16:55, Paul A. Rubin a écrit :

Hi all,

Is there any plan afoot to incorporate changebars in the output (when
change tracking and show changes in output are enabled) in a forthcoming
version of LyX?

I've cobbled together a module for it (public repo at
https://gitlab.msu.edu/LyX/changebars) and tested it against LyX 2.1.4.
It works with several output formats but /not/ with dvipdfm or XeTeX
(don't know why). Also, if you have dvipost.sty installed (and if LyX
found it during configuration), LyX inserts dvipost commands that
royally screw up the display of the changes, as well as blocking display
of the changebars.

If someone wants to bundle it with a future LyX version, you have my
blessing. If not, I'll link it from the wiki (barring objections).

Cheers,
Paul




Dear Paul,


I had a look and I had to click a few times before finding the relevant 
files. Can you please send the files to the list? (I think it's just the 
.module file right?) This looks good except that you should use "Require 
changebar" instead of \usepackage{changebar}. But I am not an expert for 
layout files for please send it to the list so others can comment.



Guillaume

Re: [PATCH] Re: Regression in lyx2lyx box alignment


Le 23/10/2015 11:21, Jean-Marc Lasgouttes a écrit :

Le 19/10/2015 21:46, Georg Baum a écrit :

I found another reason for removal: The display in LyX does only consider
the paragraph alignment, so if you set that to left (which means that the
paragraph does not output any alignment command), and set it so something
else than left in the box, the display in LyX will be wrong. Fixing this
would probably result in ugly, hard to maintain code.


Actually fixing this for LR boxes (so-called makebox in the code) is not
difficult because we have the framework for table cells already. I
propose to put that in master. Would it be OK?


Note that this is orthogonal with Georg's proposed fix.

JMarc

Upgrade to boost 1.59?

I think we should upgrade our local copy of boost to 1.59 before alpha 
(or at least before beta).


Is the procedure documented somewhere?

Also, what can we do to hide the warnings related to auto_ptr? If we are 
out of ideas, I propose to compile with -Wno-deprecated-functions in 
C++11 mode.


JMarc

Changebars

2015-10-23 Thread Paul A. Rubin


Hi all,

Is there any plan afoot to incorporate changebars in the output (when 
change tracking and show changes in output are enabled) in a forthcoming 
version of LyX?


I've cobbled together a module for it (public repo at 
https://gitlab.msu.edu/LyX/changebars) and tested it against LyX 2.1.4. 
It works with several output formats but /not/ with dvipdfm or XeTeX 
(don't know why). Also, if you have dvipost.sty installed (and if LyX 
found it during configuration), LyX inserts dvipost commands that 
royally screw up the display of the changes, as well as blocking display 
of the changebars.


If someone wants to bundle it with a future LyX version, you have my 
blessing. If not, I'll link it from the wiki (barring objections).


Cheers,
Paul

Re: Upgrade to boost 1.59?

Op 23 okt. 2015 17:37 schreef "Jean-Marc Lasgouttes" :
>
> I think we should upgrade our local copy of boost to 1.59 before alpha
(or at least before beta).
>
> Is the procedure documented somewhere?
>
> Also, what can we do to hide the warnings related to auto_ptr? If we are
out of ideas, I propose to compile with -Wno-deprecated-functions in C++11
mode.
>
> JMarc

I have it documented somewhere. Should I put it in development.lyx ?

Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

2015-10-23 Thread Uwe Stöhr

  Original Message  
From: Scott Kostyshak
Sent: Donnerstag, 22. Oktober 2015 18:45‎
‎
On Thu, Oct 22, 2015 at 08:55:05AM +0200, Vincent van Ravesteijn wrote:
> On Thu, Oct 22, 2015 at 7:13 AM, Scott Kostyshak  wrote:
> > On Mon, Oct 19, 2015 at 04:33:43PM +0200, Uwe Stöhr wrote:
> >> Dear LyXers,
> >>
> >> I would like to have a beta release short after the feature-freeze.
> >> During the beta and RC-cycle the docs will be updated because this
> >> usually takes some weeks.
> >
> > Sounds good to me.
> 
> IMO, it sounds a bit weird to me to have a beta release short after a
> feature freeze without considering the state of the codebase. I guess
> you announce a feature freeze, after which all devs will focus on
> improving the quality of the codebase until a certain level is reached
> at which a beta can be released. A feature freeze is just meant to
> bundle the devs' energy to focus on bugfixing and polishing existing
> features, and to make sure that not one part of the devs are doing the
> hard work on fixing bugs while the other half is introducing new ones.

Thank you for pointing this out, Vincent! I see what you mean and what
you suggest sounds the most sensible (and likely the most common in
other projects as well). After the feature freeze we might want some
time to iron out some bugs before releasing a beta. And besides, after a
feature freeze it seems there is already the necessary information to
start the process of updating the documentation. 

> Uwe, can you explain‎
why it is useful to have the beta released before starting to work on
the documentation? Why not start right after the feature freeze?

I need fixed strings. In my experience string changes happened frequently 
before releases and with a beta they were more or less frozen. So I don't 
insist on a beta but in more or less stable strings ( menu names etc.).

Regards Uwe 

Scott

Re: back to LyX and therefore questions concerning LyX 2.2

2015-10-23 Thread Uwe Stöhr


  Original Message  
From: Scott Kostyshak
Sent: Donnerstag, 22. Oktober 2015 18:45‎

> Uwe, can you explain‎
why it is useful to have the beta released before starting to work on
the documentation? Why not start right after the feature freeze?

I need fixed strings. In my experience string changes happened frequently 
before releases and with a beta they were more or less frozen. So I don't 
insist on a beta but in more or less stable strings ( menu names etc.).

Regards Uwe 

Scott

[PATCH] Re: Regression in lyx2lyx box alignment


Le 19/10/2015 21:46, Georg Baum a écrit :

I found another reason for removal: The display in LyX does only consider
the paragraph alignment, so if you set that to left (which means that the
paragraph does not output any alignment command), and set it so something
else than left in the box, the display in LyX will be wrong. Fixing this
would probably result in ugly, hard to maintain code.


Actually fixing this for LR boxes (so-called makebox in the code) is not 
difficult because we have the framework for table cells already. I 
propose to put that in master. Would it be OK?


JMarc


>From c3d39f5ef0247d447446a81684b3090eccf591c8 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Fri, 23 Oct 2015 11:16:21 +0200
Subject: [PATCH] Implement on screen rendering of alignment in LR boxes.

---
 src/insets/InsetBox.cpp |   24 
 src/insets/InsetBox.h   |2 ++
 2 files changed, 26 insertions(+)

diff --git a/src/insets/InsetBox.cpp b/src/insets/InsetBox.cpp
index 21d7feb..02a998e 100644
--- a/src/insets/InsetBox.cpp
+++ b/src/insets/InsetBox.cpp
@@ -223,6 +223,30 @@ ColorCode InsetBox::backgroundColor(PainterInfo const &) const
 }
 
 
+LyXAlignment InsetBox::contentAlignment() const
+{
+	if (!params_.use_makebox)
+		return LYX_ALIGN_NONE;
+
+	LyXAlignment align = LYX_ALIGN_NONE;
+	switch (params_.hor_pos) {
+	case 'l':
+		align = LYX_ALIGN_LEFT;
+		break;
+	case 'c':
+		align = LYX_ALIGN_CENTER;
+		break;
+	case 'r':
+		align = LYX_ALIGN_RIGHT;
+		break;
+	case 's':
+		// we do cannot show 'stretch' wysiwym yet
+		break;
+	}
+	return align;
+}
+
+
 void InsetBox::doDispatch(Cursor & cur, FuncRequest & cmd)
 {
 	switch (cmd.action()) {
diff --git a/src/insets/InsetBox.h b/src/insets/InsetBox.h
index 877dd60..151d622 100644
--- a/src/insets/InsetBox.h
+++ b/src/insets/InsetBox.h
@@ -115,6 +115,8 @@ public:
 	///
 	ColorCode backgroundColor(PainterInfo const &) const;
 	///
+	LyXAlignment contentAlignment() const;
+	///
 	bool allowParagraphCustomization(idx_type = 0) const { return !forcePlainLayout(); }
 	///
 	bool allowMultiPar() const;
-- 
1.7.9.5

Minimum compiler version


I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter

Re: Upgrade to boost 1.59?




Am 23.10.2015 um 18:13 schrieb Vincent van Ravesteijn:


Op 23 okt. 2015 17:37 schreef "Jean-Marc Lasgouttes"
>:
 >
 > I think we should upgrade our local copy of boost to 1.59
before alpha (or at least before beta).
 >
 > Is the procedure documented somewhere?
 >
 > Also, what can we do to hide the warnings related to
auto_ptr? If we are out of ideas, I propose to compile with
-Wno-deprecated-functions in C++11 mode.
 >
 > JMarc

I have it documented somewhere. Should I put it in
development.lyx ?

Vincent



I could do it. I've done it already multiple times.

Peter

(a little, little back ;)

Build bot reactivated

I've reactivated the build-bot for Windows binaries of the 
master branch. It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).


http://syntheticpp.github.io/LyX-bleeding-edge

Maybe it helps a bit for 2.2.

Peter

Re: Minimum compiler version

Am 23.10.2015 um 20:55 schrieb Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter

Dear Peter,

See

and subsequent messages. The only concrete example was
Jean-Marc's OSX 10.7 computer, although in this case there is a
straightfoward fix according to Google.

Hi Guillaume,

I assume GCC on this system is very old, but Xcode also
ships with clang, which supports

"The LLVM compiler now supports C++11 'user defined
literals' and 'unrestricted unions' features."

https://developer.apple.com/library/watchos/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_4_0.html#//apple_ref/doc/uid/TP40016147-SW5

so maybe using clang is an option.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless
(which makes me wonder why C++11 was at all invented). However the
discussion about allowing Unicode string literals clearly showed the
contrary: .

The overall discussion about C++11 was rather unconvincing,
and as a consequence I have already decided to use C++11 features
without restraint starting from 2.3, and not to make a single
non-trivial effort at possible backports into 2.2 of any of my patches. One
cannot claim one day that LyX is short in developer time, and another day
that increasing backporting efforts is without consequences. This
makes me hope that this 2.2 version will be short-lived (however
impatient I am to see it out).

Then backporting is an argument to require c++11 already for
2.2.

Peter

Guillaume

Re: Build bot reactivated




Am 23.10.2015 um 21:07 schrieb Richard Heck:

On 10/23/2015 12:52 PM, Peter Kümmel wrote:

I've reactivated the build-bot for Windows binaries of the
master branch. It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).

http://syntheticpp.github.io/LyX-bleeding-edge

Maybe it helps a bit for 2.2.


You should add a warning that using those binaries could
melt you monitor and has also been found to cause cancer in
laboratory rats. ;-)


Do you think the warning is too extreme?

Clearly, it would be better to build the complete installer,
but I'm not sure if it is worth the effort, especially
because Uwe is working mainly on Windows.

Peter



Richard

Re: Minimum compiler version




Am 23.10.2015 um 21:16 schrieb Vincent van Ravesteijn:

Guillaume


Well, I probably can wake you from your dreams of C++11
quickly when I try compiling your C++11 features with
MSVC2010...




Vincent

Re: Minimum compiler version




Am 23.10.2015 um 21:16 schrieb Vincent van Ravesteijn:

Guillaume


Well, I probably can wake you from your dreams of C++11
quickly when I try compiling your C++11 features with
MSVC2010...



There is MSVC 2015, which is nearly C++11/14 feature 
complete. So is there any good reason not to require MSVC15?


And if someone could not install MSVC2015 on his system, 
maybe because he uses the system (and time ;) ) at work,

he could still copy a QtCreator version with MinGW without
admin rights.

Peter


Vincent

Re: Minimum compiler version




Am 23.10.2015 um 21:27 schrieb Stephan Witt:

See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.


Note, I've to pass --disable-cxx11 to configure to build LyX on
my system. LyX 2.1.x an Mac is available for systems back to OS 10.6
for LyX 2.2.0 there isn't any statement for which systems it should
be available.

Stephan


The compiler version depends on the developer system/Xcode 
version not the Mac OS target version.


Overall "Mac users" are used to see new features not 
supported on older systems. So I see no problem to have 2.2 
running on more recent OS version.


Peter




Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial effort
at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).



Guillaume

Re: Minimum compiler version




Am 23.10.2015 um 21:34 schrieb Vincent van Ravesteijn:

support of MSVC2010.


I think I don't need to tell Peter about MSVC support for
C++11 (I guess he knows better than me).

The message was really meant for you: if you introduce C++11
features that cannot compile on MSVC, you will meet some
resistance.



So only you insist on MSVC2010 support?

Peter


Vincent

Re: Build bot reactivated


On 10/23/2015 12:52 PM, Peter Kümmel wrote:
I've reactivated the build-bot for Windows binaries of the master 
branch. It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).


http://syntheticpp.github.io/LyX-bleeding-edge

Maybe it helps a bit for 2.2.


You should add a warning that using those binaries could melt you 
monitor and has also been found to cause cancer in laboratory rats. ;-)


Richard

Re: Minimum compiler version


Le 23/10/2015 20:34, Vincent van Ravesteijn a écrit :

Op 23-10-2015 om 21:22 schreef Guillaume Munch:

Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit :

Op 23-10-2015 om 20:55 schreef Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial
effort
at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).

Guillaume


Well, I probably can wake you from your dreams of C++11 quickly when I
try compiling your C++11 features with MSVC2010...

Vincent





I think that your message was meant as an answer Peter's question
explaining that for some reason you need the support of MSVC2010.


I think I don't need to tell Peter about MSVC support for C++11 (I guess
he knows better than me).

The message was really meant for you: if you introduce C++11 features
that cannot compile on MSVC, you will meet some resistance.



Ok, but then it is the same situation for 2.3, and about specific 
features. Good to know in advance, but this will need to be discussed as 
it happens.

Re: Build bot reactivated

2015-10-23 Thread Liviu Andronic

On Fri, Oct 23, 2015 at 9:07 PM, Richard Heck  wrote:
> On 10/23/2015 12:52 PM, Peter Kümmel wrote:
>>
>> I've reactivated the build-bot for Windows binaries of the master branch.
>> It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).
>>
>> http://syntheticpp.github.io/LyX-bleeding-edge
>>
>> Maybe it helps a bit for 2.2.
>
>
> You should add a warning that using those binaries could melt you monitor
> and has also been found to cause cancer in laboratory rats. ;-)
>
Last I heard, before the previous major release LyX was a child eating
monster... :)

Liviu


> Richard
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Minimum compiler version


Op 23-10-2015 om 20:55 schreef Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial effort
at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).

Guillaume


Well, I probably can wake you from your dreams of C++11 quickly when I 
try compiling your C++11 features with MSVC2010...


Vincent

Re: Minimum compiler version


Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit :

Op 23-10-2015 om 20:55 schreef Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial effort
at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).

Guillaume


Well, I probably can wake you from your dreams of C++11 quickly when I
try compiling your C++11 features with MSVC2010...

Vincent






I think that your message was meant as an answer Peter's question 
explaining that for some reason you need the support of MSVC2010.

Re: Minimum compiler version

2015-10-23 Thread Stephan Witt

Am 23.10.2015 um 20:55 schrieb Guillaume Munch :

> Le 23/10/2015 17:55, Peter Kümmel a écrit :
>> I wonder to still see auto_ptr:
>> 
>> https://travis-ci.org/syntheticpp/lyx
>> 
>> Which old compiler you wanna support?
>> 
>> Peter
>> 
> 
> 
> Dear Peter,
> 
> 
> See 
> and subsequent messages. The only concrete example was Jean-Marc's OSX
> 10.7 computer, although in this case there is a straightfoward fix
> according to Google.

Note, I've to pass --disable-cxx11 to configure to build LyX on
my system. LyX 2.1.x an Mac is available for systems back to OS 10.6
for LyX 2.2.0 there isn't any statement for which systems it should
be available.
 
Stephan

> Another argument in favour of keeping C++98 seemed to be that
> backporting from C++11 to C++98 is supposed to be effortless (which
> makes me wonder why C++11 was at all invented). However the discussion
> about allowing Unicode string literals clearly showed the contrary:
> .
> 
> The overall discussion about C++11 was rather unconvincing, and as a
> consequence I have already decided to use C++11 features without
> restraint starting from 2.3, and not to make a single non-trivial effort
> at possible backports into 2.2 of any of my patches. One cannot claim
> one day that LyX is short in developer time, and another day that
> increasing backporting efforts is without consequences. This makes me
> hope that this 2.2 version will be short-lived (however impatient I am
> to see it out).
> 
> 
> 
> Guillaume
> 
>

Re: back to LyX and therefore questions concerning LyX 2.2


Op 23-10-2015 om 9:15 schreef Pavel Sanda:
So back to Uwe's question, it would be good you announce at some point 
- features won't change ( except of bugfixing ) - translatable strings 
are not going to be changed (except obvious bugs/typos). and maybe 
give some hint when this might occur :)


I assume that people will not start changing strings for fun when we are 
in the feature freeze phase. So I expect hardly any string changes then. 
And when there is a serious reason for changing a string, it can 
probably be adjusted anyway in the translations/docs, but maybe with a 
little more effort.


IMO, a separate hard string freeze is not needed as long as we act 
reasonable.


Vincent

Re: Minimum compiler version


Le 23/10/2015 20:27, Stephan Witt a écrit :

Am 23.10.2015 um 20:55 schrieb Guillaume Munch :


Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.


Note, I've to pass --disable-cxx11 to configure to build LyX on
my system. LyX 2.1.x an Mac is available for systems back to OS 10.6
for LyX 2.2.0 there isn't any statement for which systems it should
be available.

Stephan


At least, it seems that you are not entirely out of luck for 2.3 
according to a link that I've posted previously: 
.

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

2015-10-23 Thread Guenter Milde

On 2015-10-23, Scott Kostyshak wrote:
> On Tue, Oct 20, 2015 at 09:10:05PM +, Guenter Milde wrote:
>> On 2015-10-20, Scott Kostyshak wrote:
>> > On Tue, Oct 20, 2015 at 07:16:44PM +0200, Günter Milde wrote:
>> >> commit 1523fc6023440f10ca0d82a681ded5c060d8fd33
>> >> Author: Günter Milde 
>> >> Date:   Tue Oct 20 19:14:39 2015 +0200

>> >> Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

>> >> Fixes output for 3 of the 4 test lyx-files.

>> >> Includes "FIXME"s at places where further action is required to get 
>> >> the XeTeX
>> >> export right but I don't know how.
>> >> ...

>> >> + &&!runparams.isFullUnicode()) { // FIXME: check must be done for 
>> >> useNonTeXFonts!
>> >>   os << "\\inputencoding{utf8}\n"
>> >>  << setEncoding("UTF-8");

>> > So to make sure I understand what you want with this FIXME is you would
>> > like to do something like params().useNonTeXFonts as you do in
>> > Buffer.cpp but in PDFOptions.cpp it's not clear how to access that?

>> It may also be that I misunderstand what is done there, but basically, yes: 
>> I believe that the test at these places must be for "useNonTeXFonts" instead
>> of "isFullUnicode", because XeTeX/LuaTeX with TeX fonts behave more similar
>> to 8-bit TeX regarding the in- and output encodings.

> OK, what about the attached patch? Can you check that it does what you
> want as far as the two FIXMEs in PDFOptions.cpp? 

>From what I see (and with my limited understanding of C++), I believe the
fix to be OK.

To be sure, I'd need a use case for this code. (Maybe the commit message
you found with "blame" tells something helpfull about where it is
needed?) The we could compare the exported file before and after patching
and see which works better.

> If so, hopefully someone else can confirm that it is reasonable to pass
> the buffer parameters in this situation. Then after that I could extend
> the fix to address the other FIXMEs that you have regarding
> useNonTeXFonts.

However, the main problem is ensuring the "latex-encoding" is "ASCII" for
the combination of XeTeX and "TeX fonts".

> Günter are you familiar with "git blame"? It is a useful tool for
> purposes such as these where we might want to check with the person who
> introduced a certain line of code. For example, if before your commit
> (otherwise it will say you are the author of that line because you
> edited it to put the comment) I
> do

> git blame PDFOptions.cpp

> and then I search (with '/') for "isFullUnicode" it takes me to the
> first instance and tells me that Jürgen introduced this line in the
> commit baaceb10. So now we ping Jürgen (now CC'ed) and see what his
> opinion is on this.

Thanks

Günter

Re: Many tex2lyx failing now on master


On 10/23/2015 02:17 PM, Guenter Milde wrote:

On 2015-10-22, Richard Heck wrote:

On 10/22/2015 04:23 PM, Georg Baum wrote:

Guenter Milde wrote:

Maybe a suggestion to provide a minimal example of the new feature
requiring the file format change in form of a *.lyx or *.tex file that
can either be simply added to the test base (if tex2lyx works fine) or
put on in a set of "TODO examples".
Whether we provide a directory for such incoming test examples (so that
test-experts can review them and bring them in line with the other tests)
or ask to send them to the devel list or whatever should be agreed on by
people caring for the test suite.

That would be very useful indeed (also for producing a lyx2lyx testsuite).

This is more difficult, since we in no way guarantee round trip
equivalence. Or am I missing something? (I'm not well informed about
automated testing, etc.)

My suggestion was not (necessarily) about round-trip but in first place
about import (tex2lyx).


Yes, I was just talking about the mention of lyx2lyx, so maybe we are at 
cross purposes. But one certainly could have two format N .lyx files and 
two format N+1 .lyx files---one each for forward and one for backward 
conversion---and test whether lyx2lyx gets you the right results both 
times. Or we could just focus on the forward conversion, which is a lot 
more important to most people.


Richard

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

2015-10-23 Thread Guenter Milde

On 2015-10-21, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding: 8bit --]

> On Tue, Oct 20, 2015 at 09:10:05PM +, Guenter Milde wrote:

>> It may also be that I misunderstand what is done there, but basically, yes: 
>> I believe that the test at these places must be for "useNonTeXFonts" instead
>> of "isFullUnicode", because XeTeX/LuaTeX with TeX fonts behave more similar
>> to 8-bit TeX regarding the in- and output encodings.

> This commit breaks a lot of ctests. 

While I was pretty sure that the partial patch will not fix all these
strange use cases, I did not expect it to break working examples.

> For example, the document
> doc/Development.lyx no longer compiles with XeTeX (with TeX fonts).

So let's have a look at the example.

> I get the following error:

>   Missing character: There is no — in font ecrm1200!

This reports a missing en-dash. Strange, because there is no en-dash in
Development.lyx (otherwise it would fail before the patch with the above
error.

Here I get

  Missing character: There is no � in font ecrm1200!

and this is because of:

  Invalid UTF-8 byte or sequence at line 300 replaced by U+FFFD.
  Missing character: There is no � in font ecrm1200!

> It compiles fine before this commit.

Yes, but only "per accident": Development.lyx only uses some non-ASCII
characters, and these are also at the same place in Unicode and T1.

Before my partial patch, the "latex encoding" was set to "utf-8" for export
to XeTeX and LuaTeX, regardless of the used font encoding. This can lead to
both, now reported errors for missing characters and wrong output for some
non-ACII characters in the "latin extended" block.

If you compile the example file "luatex-without-fontspec-latin9" using
XeTeX with an "unpatched" LyX, you get both, the 

  Missing character: There is no — in font ecrm1200!

for the en-dash and wrong high bit characters:

The input:

  £§¥©®°±²³´µ·½¿÷ø ÂÃÄÖÜ äöüÿß

looks very different in the PDF (starting with "č" and other
east-european Latin characters and ending with "ßSS" (while drag-and-drop
here results in the almost correct "£§¥©®°±23 ́μ·1⁄2¿÷ø ÂÃÄÖÜ äöüÿß").

However, the German umlauts are kept.

And actually the small o-umlaut "ö" is the only non-ASCII character in the
whole file Development.lyx. 

So, in this example the patch indeed broke the XeTeX export, while it may
be that in other "broken" example files export with XeTeX run without error
report but still produced wrong results!

> The commit also fixed a lot of ctests.

Even here, we cannot be sure that XeTeX export is correct now.

> Attached are the lists of tests that fail before this commit and the
> list that fails after this commit. By comparing them you can see which
> ones this commit changed. Let me know if you have any questions.

I wonder, whether we could limit the number of tests for the corner case
"XeTeX/LuaTeX with TeX fonts".

In my view, we should just admit that this is currently broken and the
proper fix would be "automatic" selection of non-TeX fonts for XeTeX/LuaTeX
(if not explicitely set otherwise by the user).

Otherwise, nothing will spare us a close examination of all these files and
the export result "per hand"...

Günter

Re: Minimum compiler version


Le 23/10/2015 20:22, Guillaume Munch a écrit :

Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit :

Op 23-10-2015 om 20:55 schreef Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial effort
at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).

Guillaume


Well, I probably can wake you from your dreams of C++11 quickly when I
try compiling your C++11 features with MSVC2010...

Vincent






I think that your message was meant as an answer Peter's question
explaining that for some reason you need the support of MSVC2010.



(To clarify: I don't doubt it. I know nothing about the situation there.)

Re: Minimum compiler version


Op 23-10-2015 om 21:22 schreef Guillaume Munch:

Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit :

Op 23-10-2015 om 20:55 schreef Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial 
effort

at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).

Guillaume


Well, I probably can wake you from your dreams of C++11 quickly when I
try compiling your C++11 features with MSVC2010...

Vincent





I think that your message was meant as an answer Peter's question 
explaining that for some reason you need the support of MSVC2010.


I think I don't need to tell Peter about MSVC support for C++11 (I guess 
he knows better than me).


The message was really meant for you: if you introduce C++11 features 
that cannot compile on MSVC, you will meet some resistance.


Vincent

Re: Many tex2lyx failing now on master

2015-10-23 Thread Georg Baum

Richard Heck wrote:

> Yes, I was just talking about the mention of lyx2lyx, so maybe we are at
> cross purposes. But one certainly could have two format N .lyx files and
> two format N+1 .lyx files---one each for forward and one for backward
> conversion---and test whether lyx2lyx gets you the right results both
> times. Or we could just focus on the forward conversion, which is a lot
> more important to most people.

Having tests for the forward lyx2lyx conversion would already be a big 
improvement. This would also allow changes in the lyx2lyx infrastructure. 
Those are impossible to do now, because we do not have tests to ensure that 
older conversions do still work.

Georg

Re: [PATCH] Re: Regression in lyx2lyx box alignment

2015-10-23 Thread Georg Baum

Jean-Marc Lasgouttes wrote:

> Actually fixing this for LR boxes (so-called makebox in the code) is not
> difficult because we have the framework for table cells already. I
> propose to put that in master. Would it be OK?

I did not know that mechanism. This looks indeed nice. However, I wonder 
whether the condition for ignoring hor_pos should be the same as the one 
used for LaTeX output. When looking at your patch I could not see whether 
both places are equivalent. Anyway if this is sorted out I think that it 
would be a very nice improvemrnt and should go in.

Georg

Re: back to LyX and therefore questions concerning LyX 2.2

2015-10-23 Thread Pavel Sanda

Vincent van Ravesteijn wrote:
> IMO, a separate hard string freeze is not needed as long as we act 
> reasonable.

I meant it as a part of feature freeze. Whether you are working on documentation
or translation only, you don't want people mess with UI logic and strings.
Pavel

Re: Changebar module file

2015-10-23 Thread Pavel Sanda

Paul A. Rubin wrote:
> Hi all,
>
> Sorry if this breaks any threads, but per Guillaume's request, I'm 
> attaching the changebar.module file here to save anyone from having to 
> navigate the repo menu system.

This would be nice to have, though I am wondering whether such feature doesn't
belong directly to menu, next to 'Show changes in output'. More work, I know...
Pavel

Re: back to LyX and therefore questions concerning LyX 2.2

2015-10-23 Thread Pavel Sanda

Vincent van Ravesteijn wrote:
> >> - Will there be a code-freeze after that strings can still be changed?
> >
> > Is this what is normally done? I'm new at this.
> 
> I've actually no clue what is meant with a code freeze after that
> strings an be changed ?

I think the question was, whether the feature freeze includes string freeze
or there will be separate one.

This question is relevant to both docs and translators because if we
continuously change the translatable strings they can't reasonably work.

My approach to this used to be:
1. summarize all features people want to finish and most critical bugs
   to be solved for release.

2. based on feelings from (1) announce some time schedule for alpha/beta/rc
   (yes, it will be broken but people can synchronize much better when some
   time plan is announced)

3. releasing alphas until features are done or kicked away (or some critical 
bugs).
   then soft freeze - no more new features, people should focus on fixing bugs.
   it's also time to freeze the strings so translators and documentation
   can be done - time to send some suppliant mail to trnaslators & doclist.

4. release beta. if no major bugs found and some reasonable time for testing
   by users was provided go to rc, if no continue with next betas.

5. rc, hard freeze. every commit needs either release manager or two devs
   ack, only docs and translation can still flow in.

So back to Uwe's question, it would be good you announce at some point
- features won't change ( except of bugfixing )
- translatable strings are not going to be changed (except obvious bugs/typos).
and maybe give some hint when this might occur :)

YMMV,
Pavel

Changebar module file

2015-10-23 Thread Paul A. Rubin


Hi all,

Sorry if this breaks any threads, but per Guillaume's request, I'm 
attaching the changebar.module file here to save anyone from having to 
navigate the repo menu system.


Cheers,
Paul

#\DeclareLyXModule[changebar]{Change bars}
#
#DescriptionBegin
#Enables LyX to add vertical change bars in the margin of PDF output
#when change tracking is turned on and pdflatex output format is chosen.
#DescriptionEnd
#
#Author: Paul A. Rubin (ru...@msu.edu)
#Based on code proposed by Juergen Spitzmueller
#(http://comments.gmane.org/gmane.editors.lyx.general/6).
#
# Note: the \providecommand statements are necessary to avoid
# error messages from the \renewcommand statements if change
# tracking is turned off in the document.
#

Format 49

AddToPreamble
  \usepackage{changebar}
  \providecommand{\lyxadded}[3]{}
  \providecommand{\lyxdeleted}{}
  \renewcommand{\lyxadded}[3]{
{\protect\cbstart\color{lyxadded}{}#3\protect\cbend}
  }
  \renewcommand{\lyxdeleted}[3]{%
{\protect\cbstart\color{lyxdeleted}\sout{#3}\protect\cbend}
  }
EndPreamble

Re: Changebars

2015-10-23 Thread Paul A . Rubin

Guillaume Munch  lyx.org> writes:

> 
> Dear Paul,
> 
> I had a look and I had to click a few times before finding the relevant 
> files.

Sorry, I routed you to the project home page so that you would see the
README file. The files are at https://gitlab.msu.edu/LyX/changebars/tree/master.

> Can you please send the files to the list? (I think it's just the 
> .module file right?)

Yes, just the module file (and the README). I can't attach it here, because
I'm using GMANE to reply (I'm not subscribed to the dev list). I'll attach
it to a new email.

> This looks good except that you should use "Require 
> changebar" instead of \usepackage{changebar}. But I am not an expert for 
> layout files for please send it to the list so others can comment.

I thought "Require ..." was for requiring a LyX module; changebar.sty is a
LaTeX package.

Thanks for having a look at it.

Paul

Re: Changebars


Le 24/10/2015 01:09, Paul A. Rubin a écrit :



This looks good except that you should use "Require
changebar" instead of \usepackage{changebar}. But I am not an expert for
layout files for please send it to the list so others can comment.


I thought "Require ..." was for requiring a LyX module; changebar.sty is a
LaTeX package.


I inferred this from the todonotes module where there is no
“\usepackage”. But upon closer inspection it appears indeed that
whatever goes in Requires has to be added by hand to
src/LaTeXFeatures.cpp (because it is only about avoiding duplication but
also getting the order right, if I understand correctly).

If you do not get further feedback for your module I would assume that
it is fine. I would be happy to add your file myself but I do not know
if there is anything special to do for new modules.


Guillaume

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

2015-10-23 Thread Georg Baum

Guenter Milde wrote:

> On 2015-10-21, Scott Kostyshak wrote:
> 
>> It compiles fine before this commit.
> 
> Yes, but only "per accident": Development.lyx only uses some non-ASCII
> characters, and these are also at the same place in Unicode and T1.

It was not by accident. It did compile before correctly because the .tex 
file was encoded in utf8, as XeTeX expects it, and this was explicitly 
programmed. After your change, the file is encoded in latin1, which is 
interpreted as utf8 by XeTeX, which does of course not work and causes the 
"Invalid UTF-8" error above.

The fix is simple: Re-add the deleted lines to set the encoding to utf8-
plain (see attachment). Then Development.lyx compiles again for me. The 
encoding must always be utf8 for full unicode backends if non-TeX fonts are 
used. I guess that you were mislead by the comment, which suggested that 
setting the encoding was done for TeX fonts, but this was only a part of the 
truth: It was done for non-TeX fonts as well.

> Before my partial patch, the "latex encoding" was set to "utf-8" for
> export to XeTeX and LuaTeX, regardless of the used font encoding. This can
> lead to both, now reported errors for missing characters and wrong output
> for some non-ACII characters in the "latin extended" block.

I think the part of the patch that changes the behaviour for XeTeX + TeX 
fonts was fine and I am pretty sure that it fixes many more problems for 
this combination than it creates.

> So, in this example the patch indeed broke the XeTeX export, while it may
> be that in other "broken" example files export with XeTeX run without
> error report but still produced wrong results!

Sure. A passing test after a change does not tell that the change did not 
break anything. For such a stement we would need to keep references of the 
exported files, and this is only possible for selected, small examples, not 
for out complete documentation that does change a lot. Only a test which 
fails after a change and did not fail before tells that something became 
worse (it does not tell that the previous state was ok, onlyx that it was 
less broken).

>> The commit also fixed a lot of ctests.
> 
> Even here, we cannot be sure that XeTeX export is correct now.

But it is quite likely that XeTeX export for non-TeX fonts (the main use 
case for XeTeX) was correct before, since this does simply use utf8 encoding 
throughout the whole file, which can represent every symbol LyX does 
understand.

Georg
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 829616a..1f5f7c4 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -1590,6 +1590,8 @@ bool Buffer::makeLaTeXFile(FileName const & fname,
 	// See #9740 and FIXME in BufferParams::encoding()
 	if (params().useNonTeXFonts && (runparams.flavor == OutputParams::XETEX))
 		runparams.encoding = encodings.fromLyXName("ascii");
+	else if (runparams.isFullUnicode())
+		runparams.encoding = encodings.fromLyXName("utf8-plain");

 	string const encoding = runparams.encoding->iconvName();
 	LYXERR(Debug::LATEX, "makeLaTeXFile encoding: " << encoding << ", fname=" << fname.realPath());

Re: [LyX/master] colored-boxes.lyx: new example file for the tcolorbox.module


Le 23/10/2015 03:38, Uwe Stöhr a écrit :

Concerning the code, I cannot use it in the UserGuide and the
EmbeddedObjects manual for technical reasons. So I can omit it in the
example file if you prefer that.

For the math manual I would keep it unless somebody has compilation
problems because this saves me some work.


Besides portability to other contexts, there is an advantage in reducing 
the amount of ERT: the manuals can be used as demonstration of a LyX 
document. Using lots of ERT just gives the message that LyX support of 
LaTeX is weak. And in some cases I believe that the effect obtained is 
not important enough to justify the tricks.



This is not a big deal, but I think that the benefit of the preamble
code is not that great either so it is just a matter of which little
benefit is more than the other.


It saves some time because I don't need to write all the sime "see
sec._" (where _ is a half space) but only "see ". Furthermore one has a
larger area to click on in the PDF. personally it annoys me to fiddle
around if e.g. the link is behind a single "1" with "sec. 1" you will
always hit it immediately.


What's wrong with formatted references that we already support?

JMarc

Re: back to LyX and therefore questions concerning LyX 2.2