Re: [LyX/master] Refine lang nesting fix

[Scott Kostyshak]

On Sun, Oct 18, 2015 at 09:56:06PM -0400, Scott Kostyshak wrote:
> On Sun, Oct 18, 2015 at 09:42:08PM +0200, Georg Baum wrote:
> 
> Thanks for taking a look at this mess, Georg.
> 
> > Scott, could you please look whether the tests do still produce any 
> > regression?
> 
> Do you mean with the patch in this email? Or do you mean on current
> master, after commit 86325e50?

I'm pretty sure now you meant after your attached patch. I applied your
patch and ran the tests and a quick look (the tests are not all
finished) suggests that your patch is good. Thank you and please commit.

> > Unfortunately I cannot do it myself, since I don't know what is 
> > expected to fail

We are slowly getting the tests back into a stable state, with your
fixes and with inverting some that are expected to fail. I will continue
to revert the expected failures and in a few days I will have an update
for you and document more.

Scott

Re: Translations and 2.2.alpha?

[Pavel Sanda]

Scott Kostyshak wrote:
> On Sun, Oct 18, 2015 at 01:56:57PM -0400, Richard Heck wrote:
> > 
> > Do we want to give our translators a chance to get stuff in for 2.2.alpha?
> > Or has that already been done?
> 
> This has not been done yet. I had thought this was done at a later
> stage. For example it seems for 2.1.0 it was done before beta:
> https://www.mail-archive.com/search?l=mid=50E0.1050404%40lyx.org
> 
> Should we do it before alpha?

New features coming should be officially stop before that and it takes
quite a while to prepare new translation (thousands of lines to fix and test)
so don't expect them to have it in the timefrane of the next week.
So I would say no :)
Pavel

Re: [PATCH] Get rid of ParagraphMetrics::insetDimension

[Jean-Marc Lasgouttes]

Le 16/10/15 02:21, Scott Kostyshak a écrit :

On Thu, Oct 15, 2015 at 03:30:21PM +0200, Jean-Marc Lasgouttes wrote:


Scott, OK?


Yes.


It is in now.

JMarc

Re: Does LyX work with MBP Retina screen?

[Stephan Witt]

Am 19.10.2015 um 02:46 schrieb Scott Kostyshak :
> 
>> On Sat, Oct 17, 2015 at 06:31:27PM +0200, Stephan Witt wrote:
>>> Am 16.10.2015 um 22:49 schrieb Christopher Menzel :
>>> 
>>> Greetings Stephan,
>>> 
>>> One issue: the “Do not swap Apple and Control keys” checkbox does not seem 
>>> to have any effect — whether it’s checked or unchecked, my Control keys — I 
>>> map CapsLock to Ctrl as well — behave as if they are Apple Command keys and 
>>> the Apple Command key behaves as if it’s the Control key.
>> 
>> Hi Chris,
>> 
>> yes, indeed. I didn't notice this until now. I have to check for the details 
>> again, but it looks like a problem with Qt5 introduced with version 5.4 :( - 
>> (See https://github.com/Swordfish90/cool-retro-term/issues/203). I don't 
>> have 5.3 at hand but with 4.8 it works again.
> 
> It would be interesting to know whether this bug exists still with Qt
> 5.6 beta when it is released.
> 
> Scott

I'm not sure I understood the cause of the problem completely. The output in 
message pane looks ok. Perhaps it can be fixed in LyX. I'm on vacation this 
week and havn't any time. 5.6 alpha isn't different from 5.4.2 and 5.3.2 I've 
tried to compare. 

Stephan

Where is the script that posts to lyx-cvs?

[Jean-Marc Lasgouttes]

The title says it all. I'd like to add some header in there that the 
lyx-cvs list can use to allow the message, instead of restricting to 
subscribers.


JMarc

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

[Vincent van Ravesteijn]

On Mon, Oct 19, 2015 at 1:38 PM, Jean-Marc Lasgouttes
 wrote:
>
> The title says it all. I'd like to add some header in there that the lyx-cvs
> list can use to allow the message, instead of restricting to subscribers.
>
> JMarc

It is in a git hook in a script called .git/hooks/post-receive or
post-commit or something like that. This is in the .git directory on
the server.

Vincent

Re: We don't want google to index trac tickets?

[Jean-Marc Lasgouttes]

Le 17/10/15 00:52, Scott Kostyshak a écrit :

I was trying to view a trac ticket and because our server is down I
wanted to find it on google and view the cache.

I entered the following into google:
site:http://www.lyx.org/trac/ticket/

This results in many entries that say:
A description for this result is not available because of this site's
robots.txt


We could use something less brutal as proposed here:
http://trac.edgewall.org/ticket/6124

JMarc

Re: [PATCH] Get rid of ParagraphMetrics::insetDimension

[Jean-Marc Lasgouttes]

Le 16/10/15 02:21, Scott Kostyshak a écrit :

// FIXME (Abdel 23/09/2007): this is a bit messy 
because of the
// elimination of Inset::dim_ cache. This coordOffset() 
method needs
// to be rewritten in light of the new design.
-   Dimension const & dim = parMetrics(dit[i - 1].text(),
-   dit[i - 1].pit()).insetDimension(());
+   Dimension const & dim = 
coordCache().getInsets().dim(());
lastw = dim.wid;
} else {
Dimension const dim = sl.inset().dimension(*this);


I don't suppose your fix addressed the FIXME ?


No, I left that for later.

JMarc

Re: [patches] the last ones before 2.2

[Jean-Marc Lasgouttes]

Le 15/10/15 19:32, Guillaume Munch a écrit :

Jean-Marc's comment seems to be: sometimes we would like the id to
remain the same (which indeed would not be taken into account by the
current patch). Jean-Marc, did I understand you remark correctly and if
so, do you have an example in mind?


We do that for paragraphs. Even when a paragraph gets modified, or we 
use undo, it keeps its id. This allows to address a paragraph in a 
robust way.


JMarc

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

[Jean-Marc Lasgouttes]

Le 17/10/15 17:02, Guenter Milde a écrit :

Dear LyX developers,

On 2015-10-16, Guillaume Munch wrote:

Le 16/10/2015 18:10, Guenter Milde a écrit :

Georg wrote:



We are talking about a one time effort of at most half an hour for
one person only.

...

Please relate this effort to the time which is wasted by requiring
other developers to work around that personal preference.


I see it rather as a one-time effort to get the lyx-cvs permissions right.
The additional loop ("... and, btw., you need to subscribe to this list if
you really want to commit") after finally getting commit rights set up and
working will hit other future contributors, too.


Guenter, you should now be able to post to lyx-cvs. You are not 
subscribed to this list, but just whitelisted.


I am working out a better solution with Máté right now.

JMarc

Re: [PATCH] Get rid of ParagraphMetrics::insetDimension

[Jean-Marc Lasgouttes]

Le 15/10/15 18:07, Richard Heck a écrit :

The only changed behavior is that the CoordCache asserts when
requiring a non existing cache entry, where insetDimension would
return a dummy value. This can lead to some crashes, but I would say
that these are welcome in some cases.


Is there something sensible to do in release mode in this case? rather
than crash?


I updated the patch to return null values and now I wonder whether this 
was a good idea. Currently it throws a buffer exception and saves the 
file before crashing.


We could maybe keep this for 2.2alpha and change our mind if it causes 
too many problems. I do not think that relying on default values is a 
good idea.


JMarc

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

[Guenter Milde]

On 2015-10-19, Jean-Marc Lasgouttes wrote:

> Guenter, you should now be able to post to lyx-cvs. You are not 
> subscribed to this list, but just whitelisted.

> I am working out a better solution with Máté right now.

Thank you very much, Jean-Marc,

Günter

Re: bug 9626: new handling of "LyX" is unintuitive

[Jean-Marc Lasgouttes]

Le 18/10/15 20:01, Georg Baum a écrit :

- the menu to insert logos is shifted to a new menu Insert -> Logos
- adding a tooltip to InsetSpecialChar
- rename the top level menu "Special Characters" to "Special Characters &
Strings"

Shall we do any of the above? Or anything else? I want to close this bug to
get it from my list.


I refer the last possibility. We could also provide a Documenter toolbar 
with logos, Info insets and things like that.


JMarc

Re: Regression in lyx2lyx box alignment

[Jean-Marc Lasgouttes]

Le 18/10/15 17:01, Georg Baum a écrit :

What is wrong with the new alignment handling? It is IMHO confusing and not
needed, we have paragraph alignment. Look at the attached example: I set the
box alignment to centered, and the paragraph alignment to right. This will
produce \centered \begin{flushright} which does not really make sense. I
think we should try to be consistent and not offer different ways to do the
same thing unless there is a very clear advantage (which I do not see in
this case). Has this change been discussed on the list? If yes, then I
missed it.


I'd like to hear about reasons for this feature, but s you describe it, 
I think it should be removed.



I do therefore vote for removing the new aligment handling again. I have no
strong optinion whether we should prefer option 2) or 3). Basically we need
to decide which is more important: Old documents imported into 2.2 during
the last 5 months, or new documents created during the last 5 months? I
slightly tend towards 2), also because it is less work.


How much less work is it?

JMarc

LyX's master is now uncompilable

[Uwe Stöhr]

Dear LyXers,

one of todays' commits broke the compilation for me with MSVC:

 C:\Program Files (x86)\Microsoft Visual Studio 
10.0\VC\include\xstring(982):
error C2491: 'std::numpunct<_Elem>::id': Definition of static data 
member for dllimport is not allowed 
[D:\LyXGit\Master\compile-result\src\LyX.vcxproj]


Georg, Guillaume, could you please have a look?

thanks and regards
Uwe

Re: [LyX/master] Adding TexRow information on math latex output (#4725)

[Jean-Marc Lasgouttes]

Le 19/10/15 15:07, Pavel Sanda a écrit :

Guillaume Munch wrote:

 This finishes adding line tracking for math in the source panel and for 
forward
 search.


Sweet :)


The next thing that we need for line tracking is Sweave support; sweave 
does rewrite some parts of the document, and therefore the line numbers 
are not accurate anymore. It is however possible to ask sweave to output 
a correspondence file, but we have to make use of it...


JMarc

Re: [LyX/master] Adding TexRow information on math latex output (#4725)

[Pavel Sanda]

Guillaume Munch wrote:
> This finishes adding line tracking for math in the source panel and for 
> forward
> search.

Sweet :)
P

Re: bug 9626: new handling of "LyX" is unintuitive

[PhilipPirrip]

On 10/18/2015 02:01 PM, Georg Baum wrote:

- rename the top level menu "Special Characters" to "Special Characters &
Strings"



This is what a programmer would call it, but I think this is just too 
long for a menu entry (and who knows what it'd be in other languages). 
Why not simply Symbols, or if you want it, Special Symbols?


Another possibility is to have an option (local/Document; or global/LyX) 
 to whether these few strings will be translated as before.

Re: back to LyX and therefore questions concerning LyX 2.2

[Jean-Marc Lasgouttes]

Le 19/10/15 16:33, Uwe Stöhr a écrit :

- what is the timetable for LyX 2.2?


Maybe an alpha release next week.


- Will there be a code-freeze after that strings can still be changed?


Don't know


- Who is the release manager for 2.2


Scott.


- A request: could anybody please add all new features, also the small
ones, to http://wiki.lyx.org/LyX/NewInLyX22
This page is not up to date and it would help me a lot with the
documentation. You know: an undocumented feature is an unused feature


I'll take a look.


Today I added my last feature for 2.2 - only a module improvement. I had
2 days time since a long time and could not resist ;-) And yes, it was
fun to write a completely new manual for such an exciting feature like
the fancy boxes. (I wished I had known this feature before.)


Please take a look at Scott's anwsers.

Welcome back!

JMarc

PS: and of course my idea of replacing ugly tables with nice formal 
tables and remove all the spacing hacks you had to do is still waiting 
for your answer ;)

Re: Pixmap cache is broken for master

[Jean-Marc Lasgouttes]

Le 14/10/15 14:22, Stephan Witt a écrit :

Am 14.10.2015 um 10:31 schrieb Jean-Marc Lasgouttes :


Le 14/10/2015 10:16, Stephan Witt a écrit :

Am 14.10.2015 um 09:59 schrieb Jean-Marc Lasgouttes :


Le 14/10/2015 08:02, Stephan Witt a écrit :

But I don't believe the effect of the clipped cached pixmaps is caused by this. 
I gave not enough information - to spare email size the posted screen shots are 
to small to see it - the effect isn't there globally. It happens on some line 
ends and on inset boundaries (e.g. the LyX text logo). I suspect some error in 
LyX's size computations.


Agreed. But if this pixmap rendered text is ugly, we have one more reason for 
getting rid of it. I'll try to make time for some profiling tomorrow.


Yes, another reason might be the memory consumption. In the past the pixmap 
cache held glyphs. Now there are the text fragments LyX draws in the cache.


Indeed. What about just dumping it? :p


I'm all for it.


After much scratching, I fixed it instead. As often, it took a long time 
to find something that was obvious.


So now pixmap caching sort of works (rendering is not as nice IMO). We 
can there fore leave it enabled.


JMarc

Re: [patches] the last ones before 2.2

[Guillaume Munch]

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

Le 15/10/15 19:32, Guillaume Munch a écrit :

Jean-Marc's comment seems to be: sometimes we would like the id to
remain the same (which indeed would not be taken into account by the
current patch). Jean-Marc, did I understand you remark correctly and if
so, do you have an example in mind?


We do that for paragraphs. Even when a paragraph gets modified, or we
use undo, it keeps its id. This allows to address a paragraph in a
robust way.

JMarc




Ok. I tried to go that route, but then figured that I had to adapt the 
code for copy/paste, duplicate row/column, etc. which I tried to avoid.

back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

Dear LyXers,

after some months without time for LyX I want to re-join the 
development. Since my time is very limited I could not browse all the 
many mails in the list and therefore ask for the basic news:


- what is the timetable for LyX 2.2? In May me was told to stop adding 
new features. Now I see that there are constantly some smaller new 
features added. This is OK, I only want to know when there is a hard 
feature-freeze to start updating the docs. 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.


- Will there be a code-freeze after that strings can still be changed?

- Who is the release manager for 2.2

- A request: could anybody please add all new features, also the small 
ones, to http://wiki.lyx.org/LyX/NewInLyX22
This page is not up to date and it would help me a lot with the 
documentation. You know: an undocumented feature is an unused feature


---

Today I added my last feature for 2.2 - only a module improvement. I had 
2 days time since a long time and could not resist ;-) And yes, it was 
fun to write a completely new manual for such an exciting feature like 
the fancy boxes. (I wished I had known this feature before.)


thanks and regards
Uwe

Re: bug 9626: new handling of "LyX" is unintuitive

[PhilipPirrip]

On 10/19/2015 10:25 AM, PhilipPirrip wrote:

Why not simply Symbols, or if you want it, Special Symbols?


There's then Symbols... submenu within Special Character menu now, I 
think this should become

Special Character -> Symbols
Symbols... -> Characters

Re: [LyX/master] Adding TexRow information on math latex output (#4725)

[Guillaume Munch]

Le 19/10/2015 14:37, Jean-Marc Lasgouttes a écrit :

Le 19/10/15 15:07, Pavel Sanda a écrit :

Guillaume Munch wrote:

 This finishes adding line tracking for math in the source panel
and for forward
 search.


Sweet :)


Thanks. Next step is rewrite the algorithm for error reporting and 
reverse search to take advantage of new this information...




The next thing that we need for line tracking is Sweave support; sweave
does rewrite some parts of the document, and therefore the line numbers
are not accurate anymore. It is however possible to ask sweave to output
a correspondence file, but we have to make use of it...

JMarc




Is there a ticket with minimal working examples?

There is now "TexRow concatenation" which allows to write to a string 
buffer and still have the TexRow information, so maybe the first issue 
is easy to fix if it uses that kind of mechanism. (There's now accurate 
reporting for subcaptions thanks to this.)

Re: LyX's master is now uncompilable

[Uwe Stöhr]

Am 19.10.2015 um 16:14 schrieb Uwe Stöhr:


one of todays' commits broke the compilation for me with MSVC:

  C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\include\xstring(982):
error C2491: 'std::numpunct<_Elem>::id': Definition of static data
member for dllimport is not allowed
[D:\LyXGit\Master\compile-result\src\LyX.vcxproj]


The commit to blame is

http://www.lyx.org/trac/changeset/65d61e7a2786172da95ed9433ed0c49a7398f405/lyxgit

Guillaume?

thanks and regards
Uwe

Re: LyX's master is now uncompilable

[Guillaume Munch]

Le 19/10/2015 15:14, Uwe Stöhr a écrit :

Dear LyXers,

one of todays' commits broke the compilation for me with MSVC:

  C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\include\xstring(982):
error C2491: 'std::numpunct<_Elem>::id': Definition of static data
member for dllimport is not allowed
[D:\LyXGit\Master\compile-result\src\LyX.vcxproj]

Georg, Guillaume, could you please have a look?

thanks and regards
Uwe



Dear Uwe,


Here up-to-date master compiles fine with g++ 4.9.2. In addition, I 
tried googling for your error but could not relate it to what I wrote. 
Let's see if Georg or other recent contributors understand this, 
otherwise I suggest that you find the failing commit with git bisect.



Best regards
Guillaume

Re: Translations and 2.2.alpha?

[Jean-Marc Lasgouttes]

Le 19/10/2015 19:14, Scott Kostyshak a écrit :

Well we can adjust the timeframe if necessary (it is already delayed
because of Qt 5.6 beta delay). If this is important or there is
precedence then we can delay a couple of weeks.


I would say it is only important before beta.

JMarc

Re: Many tex2lyx failing now on master

[Georg Baum]

Scott Kostyshak wrote:

> Many tex2lyx tests have started to fail (before it was just 4 and we
> knew why and I think Günter's recent commit might have fixed them?). Now
> 14 are failing.

If you look at the differences between the test references and the actual 
results you see only changed format numbers 497 -> 498. This makes it very 
clear that the failures are caused by ce933b1e. I am not going to find out 
whether the references can simply be updated, or whether tex2lyx does now 
produce a broken file format.

If a certain developer continues to treat LyX development as a one way push 
to git without any feedback path and only comes asking if he has compilation 
problems, I really have to hold my horses not to make git spit back his 
changes (i.e. reverting them).


Georg

Re: LyX's master is now uncompilable

[Georg Baum]

Guillaume Munch wrote:

> The former. If we are supposed to include support/docstream.h to use
> odocstringstream, shouldn't the latter be defined in docstream.h instead
> of strfwd.h? (or the fix be moved to strfwd.h which is already included
> by docstream.h via docstring.h?)

That was the missing bit, now I understand it. I believe that strfwd.h is 
newer than the MSVC fix.

> I am tempted to do the proper fix, but since I do not own MSVC, people
> would have to bear with me if this breaks compilation temporarily.

Please do it. I am 99% sure that moving these lines

#if defined(_MSC_VER) && (_MSC_VER >= 1600) 
// Ugly workaround for MSVC10 STL bug:
// std::numpunct has a hardcoded dllimport in definition, but we wanna it 
with 32 bit 
// so we can't import it and must define it but then the compiler complains.
#include "support/numpunct_lyx_char_type.h"
#endif

to strfwd.h will work. One could also restrict the MSVC version check to == 
1600 (since the bug is supposed to be fixed in later versions), but I would 
not do this part without test.


Georg

Re: Moving towards a 2.2 release

[Guenter Milde]

Dear Scott, dear LyX team,

On 2015-10-10, Scott Kostyshak wrote:
> On Sat, Oct 10, 2015 at 08:23:03PM +, Guenter Milde wrote:

>> Please consider Ticket #9744: "allow parallel configuration of TeX and
>> non-TeX fonts"

>> Try "View>PDF (XeTeX)" with the LyX manuals to see why this is
>> important (compiling fails, because the combination of XeTeX and
>> TeX-fonts is poorly supported by both, LaTeX and LyX).

>> I propose a new config value "automatic" for "use non-TeX fonts". The
>> effect of useNonTeXFonts == "automatic" would be to use TeX fonts with
>> 8-bit engines and non-TeX fonts with Unicode-enabled engines (XeTeX,
>> LuaTeX).

> I agree that this would be nice to fix for 2.2.0. Let's see if we can
> convince someone to work on it. Here is my attempt:

> In LyX 2.2.0 one of the changes that could be noticeable to users is
> that we now report missing characters (#9610). 

I realised that this not only applies to compilation with Xe/LuaTeX which
is a good thing -- it also catches cases like small letters missing in
most math-script fonts (To fix the description in lib/RELEASE-NOTES, just
trim the sentence.)

> Without this fix, users might not be aware that their compiled PDF will
> not show some characters. Although some users might be annoyed by
> seeing errors they did not see before, (1) it is important to give
> these errors to them so they know about the problem and (2) there is a
> "Show Output Anyway" button so if they want to view their PDF as they
> did in 2.1.x, they still can.

This are the two new features I like most.

> Fixing #9744 would have the following advantages:
> 1. It would allow fixing some of the missing glyphs errors. It is not
> clear how many users will run into this particular issue (see Günter's
> comment here: http://www.lyx.org/trac/ticket/9610#comment:18).

> 2. It would fix compilation of the manuals, as well as many of our
> tests. 

I am afraid that while this change will prevent compilation errors, the
result is different from before, so any tests that compare the output (or
the tex file) must be adapted.

I have a partial fix for the "Xe/LuaTeX with TeX-fonts" problem. The fix
prevents compilation errors with luatex and improves he situation a bit
for xetex (the difference is, that there is "luainputenc" but no
"xetexinputenc" in TeXLive and the standard "inputenc" package currently
refuses to work with xetex unless the encoding is utf8).

Should I commit the patch or wait?

Günter

Re: LyX's master is now uncompilable

[Georg Baum]

Guillaume Munch wrote:

> Is that all the information that the compiler gives you? Does it not
> give you the name of the file?

This is the kind of error messages you often get from templates.
The compiler gives the name of the file where the error occurs, but it is a 
system header and not in our code. What I miss however are the 'included 
from...' lines. This is strange. Are we using precompiled headers with MSVC?

> I tried to understand the error message with what comes up on Google and
> I cannot relate it to my code. In addition, one of the first hits on
> Google is about a message on this list
> ,
> so it is possible that the bug is elsewhere (while still fixable by
> adapting my code).

The first hit I get is 
http://stackoverflow.com/questions/11076255/stdbasic-stringstreamunsigned-char-wont-compile-with-msvc-10
 which explains the 
problem quite well IMHO: On windows, wchar_t is 16 bit, and therefore we use 
a custom 32 bit type as char_type. Therefore the std::numpunct facets which 
are defined for char and wchar_t cannot be used, and we need to provide our 
own. Unfortunately MS messed up their STL, which declares 
std::numpunct<_Elem>::id in a template, although it is not (and cannot be) 
provided in the runtime dll for custom character types. Because of the 
awkward way how dlls work (declspec dllexport etc), this declaration 
pretends that the symbol, is exported by a dll (other simply declaring it 
would not be any problem).

The message on the list is related to commit e948caf6, which is supposed to 
fix exactly this issue. What I do not understand it why the fix does not 
work for your recent changes. Maybe you forgot to include docstream.h 
somewhere or got the include order wrong?


Georg

Re: bug 9626: new handling of "LyX" is unintuitive

[Georg Baum]

PhilipPirrip wrote:

> On 10/18/2015 02:01 PM, Georg Baum wrote:
>> - rename the top level menu "Special Characters" to "Special Characters &
>> Strings"
> 
> 
> This is what a programmer would call it, but I think this is just too
> long for a menu entry (and who knows what it'd be in other languages).
> Why not simply Symbols, or if you want it, Special Symbols?

I think the current Symbols menu is well named, since it is like this in 
other applications as well. I agree however that "Special Characters & 
Strings" is a bit technical, so I'll look how a documenters toolbar would 
look like.
 
> Another possibility is to have an option (local/Document; or global/LyX)
>   to whether these few strings will be translated as before.

This has been discussed extensively when the logo change was introduced 
(which was btw a fix for bug 4752). Unfortunately it is not easily possible 
to have such a switch, since the code that did the translation was horribly 
broken.


Georg

Re: LyX's master is now uncompilable

[Guillaume Munch]

Le 19/10/2015 22:01, Georg Baum a écrit :

Guillaume Munch wrote:


The former. If we are supposed to include support/docstream.h to use
odocstringstream, shouldn't the latter be defined in docstream.h instead
of strfwd.h? (or the fix be moved to strfwd.h which is already included
by docstream.h via docstring.h?)


That was the missing bit, now I understand it. I believe that strfwd.h is
newer than the MSVC fix.


I am tempted to do the proper fix, but since I do not own MSVC, people
would have to bear with me if this breaks compilation temporarily.


Please do it. I am 99% sure that moving these lines

#if defined(_MSC_VER) && (_MSC_VER >= 1600)
// Ugly workaround for MSVC10 STL bug:
// std::numpunct has a hardcoded dllimport in definition, but we wanna it
with 32 bit
// so we can't import it and must define it but then the compiler complains.
#include "support/numpunct_lyx_char_type.h"
#endif

to strfwd.h will work. One could also restrict the MSVC version check to ==
1600 (since the bug is supposed to be fixed in later versions), but I would
not do this part without test.


I'll let Vincent decide whether he wants to make this change.

Re: [patches] the last ones before 2.2

[Georg Baum]

Guillaume Munch wrote:

> I hope I did not put you on a wrong track with my reference to the gcc-5
> bug, which was more of a joke (because the the conditions to trigger it
> were *the contrary*).

No problem. It made me think a bit, but I did not waist any time.

> It displays more resemblance with the kind of bugs
> with math macros fixed by Enrico recently. To be sure, I tried in c++98
> mode and it crashes as well. I think it is useless to try with gcc-5
> now. Or do you still want me to?

No.

> Let's be nervous from now on when making changes to mathed/.
> 
> I archive this in a bug report?

Yes please.


Georg

Re: [LyX/master] cmake: Put updatetex2lyxtests in an appropriate folder

[Kornel Benko]

Am Montag, 19. Oktober 2015 um 21:32:21, schrieb Vincent van Ravesteijn 

> Op 19-10-2015 om 18:45 schreef Kornel Benko:
> > Am Montag, 19. Oktober 2015 um 18:02:02, schrieb Vincent van Ravesteijn 
> > 
> >> commit 92b7c5a92f21956f6da19c8ac783cd9132ca82b9
> >> Author: Vincent van Ravesteijn 
> >> Date:   Mon Oct 19 17:50:59 2015 +0200
> >>
> >>  cmake: Put updatetex2lyxtests in an appropriate folder
> >>
> >> diff --git a/src/tex2lyx/test/CMakeLists.txt 
> >> b/src/tex2lyx/test/CMakeLists.txt
> >> index e11b345..c513d6e 100644
> >> --- a/src/tex2lyx/test/CMakeLists.txt
> >> +++ b/src/tex2lyx/test/CMakeLists.txt
> >> @@ -71,3 +71,4 @@ add_custom_command(
> >>   )
> >>   
> >>   add_custom_target(updatetex2lyxtests DEPENDS LyxTestFiles)
> >> +set_target_properties(updatetex2lyxtests PROPERTIES FOLDER 
> >> "tests/tex2lyx")
> > Why is that important? This is only a phony target ..., there should be no 
> > data in the specified "tests/tex2lyx" folder.
> > In fact, there is no such folder on my platform.
> >
> > Kornel
> 
> All (phony) build targets in an MSVC solution are shown in a tree 
> structure. Proper organization of the targets does not clutter everything.
> 
> Vincent

Thanks Vincent. I suspected there must be something special. Good to know.

Kornel

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

Re: [patches] the last ones before 2.2

[Guillaume Munch]

Le 19/10/2015 20:57, Georg Baum a écrit :


I archive this in a bug report?


Yes please.




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

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 19 okt. 2015 22:51 schreef "Guillaume Munch" :
>
> Le 19/10/2015 21:34, Georg Baum a écrit :
>>
>>
>> The message on the list is related to commit e948caf6, which is supposed
to
>> fix exactly this issue. What I do not understand it why the fix does not
>> work for your recent changes. Maybe you forgot to include docstream.h
>> somewhere or got the include order wrong?
>
>
> The former. If we are supposed to include support/docstream.h to use
odocstringstream, shouldn't the latter be defined in docstream.h instead of
strfwd.h? (or the fix be moved to strfwd.h which is already included by
docstream.h via docstring.h?)
>
> I am tempted to do the proper fix, but since I do not own MSVC, people
would have to bear with me if this breaks compilation temporarily.
>

If you post the fix to the list here, I will try it tomorrow, and if it
works, I will commit.

Vincent

Re: LyX's master is now uncompilable

[Guillaume Munch]

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


The message on the list is related to commit e948caf6, which is supposed to
fix exactly this issue. What I do not understand it why the fix does not
work for your recent changes. Maybe you forgot to include docstream.h
somewhere or got the include order wrong?


The former. If we are supposed to include support/docstream.h to use 
odocstringstream, shouldn't the latter be defined in docstream.h instead 
of strfwd.h? (or the fix be moved to strfwd.h which is already included 
by docstream.h via docstring.h?)


I am tempted to do the proper fix, but since I do not own MSVC, people 
would have to bear with me if this breaks compilation temporarily.

Re: LyX's master is now uncompilable

[Guillaume Munch]

Le 19/10/2015 21:59, Vincent van Ravesteijn a écrit :


Op 19 okt. 2015 22:51 schreef "Guillaume Munch" >:
 >
 > Le 19/10/2015 21:34, Georg Baum a écrit :
 >>
 >>
 >> The message on the list is related to commit e948caf6, which is
supposed to
 >> fix exactly this issue. What I do not understand it why the fix does not
 >> work for your recent changes. Maybe you forgot to include docstream.h
 >> somewhere or got the include order wrong?
 >
 >
 > The former. If we are supposed to include support/docstream.h to use
odocstringstream, shouldn't the latter be defined in docstream.h instead
of strfwd.h? (or the fix be moved to strfwd.h which is already included
by docstream.h via docstring.h?)
 >
 > I am tempted to do the proper fix, but since I do not own MSVC,
people would have to bear with me if this breaks compilation temporarily.
 >

If you post the fix to the list here, I will try it tomorrow, and if it
works, I will commit.

Vincent




Thanks
>From 1257cdd84d4ef20740958d49a9d645a94e1b4b7b Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Mon, 19 Oct 2015 22:10:54 +0100
Subject: [PATCH] msvc: Proper fix for compilation of TexRow

This bug in MSVC 10 was fixed at e948caf6, but the workaround belongs to
strfwd.h.

Thanks Vincent and Georg.
---
 src/TexRow.cpp  |  8 
 src/support/docstream.h |  7 ---
 src/support/strfwd.h| 10 ++
 3 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/src/TexRow.cpp b/src/TexRow.cpp
index 60a3539..4bec66e 100644
--- a/src/TexRow.cpp
+++ b/src/TexRow.cpp
@@ -466,12 +466,12 @@ std::pair TexRow::rowFromCursor(Cursor const & cur) const
 ///
 docstring TexRow::asString(RowEntry const & entry)
 {
-	std::ostringstream t;
+	odocstringstream os;
 	if (entry.is_math)
-		t << "(1," << entry.math.id << "," << entry.math.cell << ")";
+		os << "(1," << entry.math.id << "," << entry.math.cell << ")";
 	else
-		t << "(0," << entry.text.id << "," << entry.text.pos << ")";
-	return from_utf8( t.str() );
+		os << "(0," << entry.text.id << "," << entry.text.pos << ")";
+	return os.str();
 }
 
 
diff --git a/src/support/docstream.h b/src/support/docstream.h
index 52916b0..108d00e 100644
--- a/src/support/docstream.h
+++ b/src/support/docstream.h
@@ -14,13 +14,6 @@
 
 #include "support/docstring.h"
 
-#if defined(_MSC_VER) && (_MSC_VER >= 1600) 
-// Ugly workaround for MSVC10 STL bug:
-// std::numpunct has a hardcoded dllimport in definition, but we wanna it with 32 bit 
-// so we can't import it and must define it but then the compiler complains.
-#include "support/numpunct_lyx_char_type.h"
-#endif
-
 #include 
 #include 
 
diff --git a/src/support/strfwd.h b/src/support/strfwd.h
index 8419b51..e0aba82 100644
--- a/src/support/strfwd.h
+++ b/src/support/strfwd.h
@@ -61,6 +61,16 @@ typedef basic_ostringstream ostringst
 
 #endif
 
+
+// Ugly workaround for MSVC10 STL bug:
+// std::numpunct has a hardcoded dllimport in definition, but we wanna it with
+// 32 bit so we can't import it and must define it but then the compiler
+// complains.
+#if defined(_MSC_VER) && (_MSC_VER >= 1600) 
+#include "support/numpunct_lyx_char_type.h"
+#endif
+
+
 namespace lyx {
 
 /**
-- 
2.1.4

Re: Pixmap cache is broken for master

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 04:44:19PM +0200, Jean-Marc Lasgouttes wrote:
> I fixed it instead.

Seems like a reasonable alternative :)

> As often, it took a long time to find something that was obvious.
> 
> So now pixmap caching sort of works (rendering is not as nice IMO). We can
> there fore leave it enabled.

Thanks for doing that!

Scott

Re: Many tex2lyx failing now on master

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 02:12:16PM -0400, Scott Kostyshak wrote:
> Many tex2lyx tests have started to fail (before it was just 4 and we
> knew why and I think Günter's recent commit might have fixed them?). Now
> 14 are failing.

They start failing for me because of ce933b1e.

Uwe are you able to run the tests? By the way, do you use CMake?

Scott

Re: Many tex2lyx failing now on master

[Guillaume Munch]

Le 19/10/2015 19:55, Scott Kostyshak a écrit :


It could be. Please do not spend any time on this right now though.
Let's first see if Uwe has an idea of how to fix them.



Just making sure I'm not responsible for breaking things again :)

Re: [LyX/master] Refine lang nesting fix

[Georg Baum]

Scott Kostyshak wrote:

> Do you mean with the patch in this email? Or do you mean on current
> master, after commit 86325e50?

with the patch, as you found out.

> Yes we will have to discuss this. One issue is that you need a lot of
> dependencies to run all the tests. Another issue is that a couple of
> commits have broken many (100s) of tests:
> 
> edd37de8
> 8bd66109
> 
> Both commits did not introduce bugs themselves (although they might have
> introduced regressions from the perspective of the user) but they did
> expose current LyX bugs. I'm not sure what can be done here. Either we
> turn the tests off in order to get cleaner test output or we fix the
> exposed bugs:
> 
> http://www.lyx.org/trac/ticket/9633

I am a bit confused. I thought my fix which I just submitted would address 
this?

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

I think the automatic part of this should go into 2.2.0. This is easy to do 
and safe and would both help us in testing and the users. I cannot comment 
on the parallel configuration of both font engines, since I do not 
understand the LaTeX font machinery well enough, I think here we should rely 
on Günters judgement since he knows this stuff well.

> Yes, Kornel has improved things a lot for this. To run with 8 cores you
> can do
> ctest -j8

Thanks, I'll try that.

> There are still problems with running the tests in parallel. I run them
> on just one core to be safe, but I think a reasonable approach is to run
> them on multiple cores, then re-run the failed test. So something like:
> 
> ctest -j8
> ctest --rerun-failed
> 
> In other words, I think that there is more of a concern of tests failing
> when they should pass than the other way around, when doing the tests in
> parallel.

OK, one could still use the parallel version for quick testing what a 
particular change does, and the serial one for final verification. This 
would already save time.

LyX is currently not very well suited for doing test driven development, but 
I can tell that (if the infrastructure is there) one gets good results very 
fast, and it even makes fun (despite being a buzz-word). Therefore I am 
trying to push for it.


Georg

Re: [patches] the last ones before 2.2

[Guillaume Munch]

Le 19/10/2015 20:32, Georg Baum a écrit :

Guillaume Munch wrote:


The choice is simple, because just adding a new variable member to math
insets as per the attached (trivial) .diff leads to new segfaults with
math macros. The .diff must be applied to current master (before or
after my upcoming TexRow patches). Compiler is g++ 4.9.2 in C++11 mode
(I did not try with C++98). Then open the attached segv-math-demo.lyx,
select all and hold Ctrl+C until it crashes (not more than a few seconds).


This makes me a bit nervous (not because of your changes of course).


The crash does not occur if we only apply the diff on InsetMath.h, i.e.
if we change the structure of the class but leave the new member
uninitialized. (An ironic twist on the g++-5 crash-on-copy bug which
occurs when some variables are not initialized that I saw passing on the
list, if you want.)


Incidentally this bug was fixed last week:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557. Therefore we should try
this with a fixed gcc. I would very much appreciate it if you have the time
to do so, if not I am going to do that but this may take a week or two.


So it seems in that mathed/ is in a brittle state. This is a deeper
reason for just using pointers for now. This seems serious. Or did
I miss something obvious to C++ experts?


I don't think so. If we are lucky then it is not mathed that is in a brittle
state, but gcc in C++11 mode, and in that case we should warn users not to
use C++11 mode with current gcc.




I hope I did not put you on a wrong track with my reference to the gcc-5 
bug, which was more of a joke (because the the conditions to trigger it 
were *the contrary*). It displays more resemblance with the kind of bugs 
with math macros fixed by Enrico recently. To be sure, I tried in c++98 
mode and it crashes as well. I think it is useless to try with gcc-5 
now. Or do you still want me to?


Let's be nervous from now on when making changes to mathed/.

I archive this in a bug report?


Guillaume

Re: Many tex2lyx failing now on master

[Guillaume Munch]

Le 19/10/2015 19:12, Scott Kostyshak a écrit :

Many tex2lyx tests have started to fail (before it was just 4 and we
knew why and I think Günter's recent commit might have fixed them?). Now
14 are failing.

Scott




I would have liked to help with tests, but when I tried to run "make 
alltests" before committing and tried to read various log files I could 
find, none contained useful informations. It was also before Günter's 
commits, so I assumed that it was normal that some failed. There really 
ought to be some documentation about tests. Did I miss it?



Anyway now I tried it again and before:

  “Converting the following files failed: test.ltx, algo2e.tex, 
box-color-size-space-align.tex, CJK.tex, CJKutf8.tex, test-insets.tex, 
test-insets-basic.tex, test-memoir.tex, test-modules.tex, 
test-refstyle-theorems.tex, test-scr.tex, test-structure.tex, 
verbatim.tex, XeTeX-polyglossia.tex”


I see lots of diffs of the form

 #LyX file created by tex2lyx 2.2
-\lyxformat 497
+\lyxformat 498
 \begin_document
 \begin_header
 \origin roundtrip

and the commit ce933b1e14 has incremented the format to 498. Could that 
alone make the tests fail?





Guillaume

Re: [LyX/master] cmake: Put updatetex2lyxtests in an appropriate folder

[Vincent van Ravesteijn]

Op 19-10-2015 om 18:45 schreef Kornel Benko:

Am Montag, 19. Oktober 2015 um 18:02:02, schrieb Vincent van Ravesteijn 


commit 92b7c5a92f21956f6da19c8ac783cd9132ca82b9
Author: Vincent van Ravesteijn 
Date:   Mon Oct 19 17:50:59 2015 +0200

 cmake: Put updatetex2lyxtests in an appropriate folder

diff --git a/src/tex2lyx/test/CMakeLists.txt b/src/tex2lyx/test/CMakeLists.txt
index e11b345..c513d6e 100644
--- a/src/tex2lyx/test/CMakeLists.txt
+++ b/src/tex2lyx/test/CMakeLists.txt
@@ -71,3 +71,4 @@ add_custom_command(
  )
  
  add_custom_target(updatetex2lyxtests DEPENDS LyxTestFiles)

+set_target_properties(updatetex2lyxtests PROPERTIES FOLDER "tests/tex2lyx")

Why is that important? This is only a phony target ..., there should be no data in the 
specified "tests/tex2lyx" folder.
In fact, there is no such folder on my platform.

Kornel


All (phony) build targets in an MSVC solution are shown in a tree 
structure. Proper organization of the targets does not clutter everything.


Vincent

Re: [patches] the last ones before 2.2

[Georg Baum]

Guillaume Munch wrote:

> The choice is simple, because just adding a new variable member to math
> insets as per the attached (trivial) .diff leads to new segfaults with
> math macros. The .diff must be applied to current master (before or
> after my upcoming TexRow patches). Compiler is g++ 4.9.2 in C++11 mode
> (I did not try with C++98). Then open the attached segv-math-demo.lyx,
> select all and hold Ctrl+C until it crashes (not more than a few seconds).

This makes me a bit nervous (not because of your changes of course).

> The crash does not occur if we only apply the diff on InsetMath.h, i.e.
> if we change the structure of the class but leave the new member
> uninitialized. (An ironic twist on the g++-5 crash-on-copy bug which
> occurs when some variables are not initialized that I saw passing on the
> list, if you want.)

Incidentally this bug was fixed last week: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557. Therefore we should try 
this with a fixed gcc. I would very much appreciate it if you have the time 
to do so, if not I am going to do that but this may take a week or two.

> So it seems in that mathed/ is in a brittle state. This is a deeper
> reason for just using pointers for now. This seems serious. Or did
> I miss something obvious to C++ experts?

I don't think so. If we are lucky then it is not mathed that is in a brittle 
state, but gcc in C++11 mode, and in that case we should warn users not to 
use C++11 mode with current gcc.


Georg

Re: [LyX/master] msvc: Fix compilation of TexRow

[Guillaume Munch]

Le 19/10/2015 20:28, Vincent van Ravesteijn a écrit :

commit 10d7f6d479b05cf101173a8ab036676482b7c251
Author: Vincent van Ravesteijn 
Date:   Mon Oct 19 21:25:26 2015 +0200

 msvc: Fix compilation of TexRow

 The problem was that "odocstringstream << (const char *) ptr" did not
 compile using msvc.





Thanks, Vincent!

Re: Regression in lyx2lyx box alignment

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 18/10/15 17:01, Georg Baum a écrit :
>> What is wrong with the new alignment handling? It is IMHO confusing and
>> not needed, we have paragraph alignment. Look at the attached example: I
>> set the box alignment to centered, and the paragraph alignment to right.
>> This will produce \centered \begin{flushright} which does not really make
>> sense. I think we should try to be consistent and not offer different
>> ways to do the same thing unless there is a very clear advantage (which I
>> do not see in this case). Has this change been discussed on the list? If
>> yes, then I missed it.
> 
> I'd like to hear about reasons for this feature, but s you describe it,
> I think it should be removed.

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 
paragarph 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.

>> I do therefore vote for removing the new aligment handling again. I have
>> no strong optinion whether we should prefer option 2) or 3). Basically we
>> need to decide which is more important: Old documents imported into 2.2
>> during the last 5 months, or new documents created during the last 5
>> months? I slightly tend towards 2), also because it is less work.
> 
> How much less work is it?

2) can be implemented by applying the attached patch. 3) would need the 
attached patch + the one from the last mail + lyx2lyx code to convert the 
alignment options to ERT (I think anything else than ERT would be far too 
much work). If I would do it, it would take me probably a few hours (but 
honestly I currently have zero motivation for doing it, since the next new 
feature that needs to be cleaned up was committed).


Georgdiff --git a/src/insets/InsetBox.cpp b/src/insets/InsetBox.cpp
index 21d7feb..bfa188e 100644
--- a/src/insets/InsetBox.cpp
+++ b/src/insets/InsetBox.cpp
@@ -508,23 +508,6 @@ void InsetBox::latex(otexstream & os, OutputParams const & runparams) const
 		os << "\\begin{shaded}%\n";
 	}
 
-	// \framebox and \makebox handle hor_pos their own way
-	// hor_pos is senseless for \mbox and \fbox
-	if (!params_.use_makebox
-		&& !(btype == Boxed && !params_.inner_box)) {
-			switch (params_.hor_pos) {
-			case 'l':
-// do nothing because this is LaTeX's default
-break;
-			case 'c':
-os << "\\centering ";
-break;
-			case 'r':
-os << "\\raggedleft ";
-break;
-			}
-	}
-
 	InsetText::latex(os, runparams);
 
 	if (btype == Shaded)

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

[Georg Baum]

Guenter Milde wrote:

> I committed the patches for bug #9764, so now the macron below vs. minus
> sign below problem should be fixed.
> http://www.lyx.org/trac/changeset/7e716a26a5e/lyxgit
> 
> tex2lyx test pass again here.

Here as well. The new errors are due to ce933b1e14f.

> Please give it a try.

Thank you very much!


Georg

Re: bug 9626: new handling of "LyX" is unintuitive

[Scott Kostyshak]

On Sun, Oct 18, 2015 at 08:01:47PM +0200, Georg Baum wrote:

> Since this was done intentionally, we will not revert it.

I think a more convincing justification for not reverting is that most
developers (myself included) agree with the change.

> However, 
> the questions whether we can do something to help people who work on our 
> docs (these are the only ones who need the logos very often). This is the 
> reason why the bug has 2.2.0 milestone. There have been several suggestions 
> in trac:
> 
> - the menu to insert logos is shifted to a new menu Insert -> Logos
> - adding a tooltip to InsetSpecialChar
> - rename the top level menu "Special Characters" to "Special Characters & 
> Strings"
> 
> Shall we do any of the above? Or anything else?

> I want to close this bug to get it from my list.

Yes thank you for bringing it to the list and not letting it sit.

I think there are two questions: (1) how to make things easier for the
user and (2) how to make things easier for the developers working on the
documentation.

My personal opinion (which is admittedly just a guess) is that the users
won't care. Most users do not write about LyX or LaTeX so (1) is not an
issue.

As for (2) I think that developers working on the documentation can
create shortcuts. I understand this is a little more of a pain, but I
don't think it is that much worse.

Scott

Re: [LyX/master] Adding TexRow information on math latex output (#4725)

[Guillaume Munch]

Le 19/10/2015 17:58, Jean-Marc Lasgouttes a écrit :

Le 19/10/2015 17:31, Guillaume Munch a écrit :

The next thing that we need for line tracking is Sweave support; sweave
does rewrite some parts of the document, and therefore the line numbers
are not accurate anymore. It is however possible to ask sweave to output
a correspondence file, but we have to make use of it...


Is there a ticket with minimal working examples?


Not yet unfortunately. The R Sweave() function has a "concordance"
option that creates a file giving line concordance. I'll try to create a
bug report.


There is now "TexRow concatenation" which allows to write to a string
buffer and still have the TexRow information, so maybe the first issue
is easy to fix if it uses that kind of mechanism. (There's now accurate
reporting for subcaptions thanks to this.


Not sure. The texrow lines will refer to the Rnw file created by LyX,
and the LaTeX errors will be from the .tex file created by sweave from
the .Rnw file.



So basically like children documents? There is already a mechanism for 
children documents, but it is outside TexRow and my newly acquired 
knowledge of LyX.

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:22:56PM +0200, Kornel Benko wrote:
> Am Montag, 19. Oktober 2015 um 17:00:34, schrieb Guenter Milde 
> 
> > On 2015-10-19, Guenter Milde wrote:
> > > On 2015-10-19, Jean-Marc Lasgouttes wrote:
> > 
> > >> Guenter, you should now be able to post to lyx-cvs. You are not 
> > >> subscribed to this list, but just whitelisted.
> > 
> > >> I am working out a better solution with Máté right now.
> > 
> > > Thank you very much, Jean-Marc,
> > 
> > I committed the patches for bug #9764, so now the macron below vs. minus
> > sign below problem should be fixed. 
> > http://www.lyx.org/trac/changeset/7e716a26a5e/lyxgit
> > 
> > tex2lyx test pass again here.
> 
> Here they do not pass.
>   # ctest -R tex2lyx
> ->
>   The following tests FAILED:
> 6 - tex2lyx/roundtrip/test.ltx (Failed)
> 8 - tex2lyx/roundtrip/algo2e.tex (Failed)
>10 - tex2lyx/roundtrip/box-color-size-space-align.tex (Failed)
>12 - tex2lyx/roundtrip/CJK.tex (Failed)
>14 - tex2lyx/roundtrip/CJKutf8.tex (Failed)
>16 - tex2lyx/roundtrip/test-insets-basic.tex (Failed)
>18 - tex2lyx/roundtrip/test-insets.tex (Failed)
>20 - tex2lyx/roundtrip/test-memoir.tex (Failed)
>22 - tex2lyx/roundtrip/test-modules.tex (Failed)
>24 - tex2lyx/roundtrip/test-refstyle-theorems.tex (Failed)
>26 - tex2lyx/roundtrip/test-scr.tex (Failed)
>28 - tex2lyx/roundtrip/test-structure.tex (Failed)
>30 - tex2lyx/roundtrip/verbatim.tex (Failed)
>32 - tex2lyx/roundtrip/XeTeX-polyglossia.tex (Failed)
> Errors while running CTest
> 
> Do you still have a clean source tree?

Same for me. I only tried on current master and there have been many
other commits besides Günter's so I'm not sure what the cause is.

Scott

Change tracking output issues

[Paul A. Rubin]

Hi all,

I couldn't find an open bug report on either of these, so I thought I'd 
ask for input here. The following apply to LyX 2.1.4.


Issue #1: In the User Guide, section 6.16, the last paragraph says that 
dvipost must be installed to show changes in the output. I've been 
showing changes in output (pdflatex) just fine without it. Is this 
advice out of date?


Issue #2: The /only/ format that lets me show changes as changes is 
pdflatex. All other formats compile the document but give no indication 
where the changes are. Am I missing something?


Thanks,
Paul

Re: Many tex2lyx failing now on master

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:38:12PM +0100, Guillaume Munch wrote:
> Le 19/10/2015 19:12, Scott Kostyshak a écrit :
> >Many tex2lyx tests have started to fail (before it was just 4 and we
> >knew why and I think Günter's recent commit might have fixed them?). Now
> >14 are failing.
> >
> >Scott
> >
> 
> 
> I would have liked to help with tests, but when I tried to run "make
> alltests" before committing and tried to read various log files I could
> find, none contained useful informations. It was also before Günter's
> commits, so I assumed that it was normal that some failed. There really
> ought to be some documentation about tests.

Yes we need better documentation.

> Did I miss it?

There is some at lib/doc/Development.lyx

The tex2lyx tests are the most important and are also very fast to run.
We're still working on getting the export tests in shape and we do need
to document how to run them and how to interpret them.

> Anyway now I tried it again and before:
> 
>   “Converting the following files failed: test.ltx, algo2e.tex,
> box-color-size-space-align.tex, CJK.tex, CJKutf8.tex, test-insets.tex,
> test-insets-basic.tex, test-memoir.tex, test-modules.tex,
> test-refstyle-theorems.tex, test-scr.tex, test-structure.tex, verbatim.tex,
> XeTeX-polyglossia.tex”
> 
> I see lots of diffs of the form
> 
>  #LyX file created by tex2lyx 2.2
> -\lyxformat 497
> +\lyxformat 498
>  \begin_document
>  \begin_header
>  \origin roundtrip
> 
> and the commit ce933b1e14 has incremented the format to 498. Could that
> alone make the tests fail?

It could be. Please do not spend any time on this right now though.
Let's first see if Uwe has an idea of how to fix them.

Scott

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 19-10-2015 om 19:04 schreef Uwe Stöhr:

Am 19.10.2015 um 18:26 schrieb Guillaume Munch:


I fail to see a problem with this commit after reading it again. I would
like to do some trial-and-error but not being able to reproduce makes it
complicated.


It is also not clear to me what triggers the error.


I fixed it at 10d7f6d.

Vincent

Many tex2lyx failing now on master

[Scott Kostyshak]

Many tex2lyx tests have started to fail (before it was just 4 and we
knew why and I think Günter's recent commit might have fixed them?). Now
14 are failing.

Scott

Re: [patches] the last ones before 2.2

[Georg Baum]

Guillaume Munch wrote:

> Le 17/10/2015 21:19, Guillaume Munch a écrit :
>>
>> I thought about that, but I do not want to introduce a divergence in the
>> behaviour of release mode compared to devel mode in a fundamental
>> aspect. This can open the door to a lot of problems: unreproducibility
>> of bugs, etc.
>>
> 
> ...as perfectly exemplified by the segfault that I just described.

Indeed.

BTW, thank you very much for developing this feature and your patience with 
my questions and concerns!


Georg

Re: [LyX/master] tcolorbox.module: uniform whitespace

[Georg Baum]

Scott Kostyshak wrote:

> On Mon, Oct 19, 2015 at 07:15:21AM +0200, Uwe Stöhr wrote:
>> commit 8da453fd30a1df085782ae5a3772a07cea38b77b
>> Author: Uwe Stöhr 
>> Date:   Mon Oct 19 07:15:18 2015 +0200
>> 
>> tcolorbox.module: uniform whitespace
> 
> Uwe can you please catch up on reading the emails on the mailing list
> before making new commits? We need to be on the same page.

And can you please stop submitting new features (and even in a way that does 
not follow the rules and breaks tests) while others are cleaning up behind 
you which you did not yo yourself although several reminders were sent 
during the last 5 months?


Georg

Re: [LyX/master] Add math cell positions to TexRow

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 12:24:24AM +0100, Guillaume Munch wrote:

> >In order to try to compile the file I believe you need to have R
> >installed. Do you have R installed? If not, are you interested in
> >installing it to debug this? I could explain how on Ubuntu. I would not
> >blame you if you are not interested installing a large package just to
> >debug this strange case (all the other four thousand tests are not
> >changed by this commit). Further, my (wild) guess is that the problem is
> >not because of your code directly, but because we probably don't handle
> >Japanese documents as good as we should. I can try to take a deeper look
> >if you don't want to look into it.
> 
> My guess is that the problem is because of my code. Since I cannot test
> directly, please try the attached, I believe it fixes.

I am impressed with your debug skills! I don't know how you could figure
out the problem based on simply "the test times out" but somehow you
did.

The tests that timed out now pass. Please commit. I will do a full run
of the tests tonight to see if anything else changes.

Thanks for the quick fix,

Scott

Re: [LyX/master] Refine lang nesting fix

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 09:24:45PM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > http://www.lyx.org/trac/ticket/9633
> 
> I am a bit confused. I thought my fix which I just submitted would address 
> this?

Ah that is great then. I was focused only on regressions caused by
46aed6d2 but it seems you fixed much more than I thought. Thank you!

If I remember correctly many of the failing tests after edd37de8 were
due to babel-specific code in the preamble. I will take a look to see if
any failures are due to the nested language issue.

> > In other words, I think that there is more of a concern of tests failing
> > when they should pass than the other way around, when doing the tests in
> > parallel.
> 
> OK, one could still use the parallel version for quick testing what a 
> particular change does, and the serial one for final verification. This 
> would already save time.

Yes that should work.

> LyX is currently not very well suited for doing test driven development, but 
> I can tell that (if the infrastructure is there) one gets good results very 
> fast, and it even makes fun (despite being a buzz-word). Therefore I am 
> trying to push for it.

This would be great. But I don't know if the export tests belong in this
category. They are so slow and they are integration tests. I would be
interested in learning more about unit tests. I believe that Vincent has
a unit test framework integrated into LyX somehow but I'm not sure there
were enough votes in favor of putting it in.

Scott

Re: Regression in lyx2lyx box alignment

[Uwe Stöhr]

Am 20.06.2015 um 05:11 schrieb Scott Kostyshak:


The attached file produces a left-aligned box in 2.1.3 but a centered
box for 2.2dev.

Uwe I remember you've done a lot of work on boxes in master. Can you
take a look? I did not do a git bisect (let me know if this would be
useful).


Sorry Scott,

I remember you sent me a mail about this in June when I was working 
abroad and then forgot about this topic.
( I see now in mail-archive.com this thread. It would have been nice to 
send me at least a direct mail to assure that I am informed. In the past 
I could read the list via NNTP but my ISP dropped that feature. When I 
am abroad I don't read mail-archive.com .)


Yes you are right, the lyx2lyx conversion is not correct. It should 
convert to left alignment for existing boxes.


So in my opinion there is nothing to revert but lyx2lyx needs to be adapted.

That new boxes have by default a centered layout is intended to uniform 
the horizontal alignment for all box types.


The new feature to set a horizontal alignment is very useful (at least I 
already use this already) and therefore it would be sad if you remove 
the whole feature.


It would be nice if you give me the chance to fix this in lyx2lyx 
instead of removing the feature.


-

I feel a lot of aggression against me in todays' posts. Maybe it was 
wrong to do again something for LyX. LyX is no longer the project I 
liked. There are now many rules making it hard for people like me, who 
don't program in their job, to follow. I see that I won't be able to 
follow LyX's development in future since even Git is too hard for me to 
handle. I never need a console in my life or work and therefore cannot 
remember all these commands. (E.g. I spent 2 hours to get cherry-picking 
to work before I gave up. - Some months ago I could use this feature but 
forgot it.) For those who use a commit system daily it is not easy to 
understand.
The idea was to document everything to make it possible for people like 
me to follow the development but obviously I am still the only Win 
developer so that the LyX coding docs only reflect how it works on Unix. 
Since my coding abilities are very limited I fear I will sooner or later 
loose track how to compile LyX - which will then also be the end of a 
Windows installer release.


Sorry for changing the topic. If I am nevertheless welcome you should 
know that I will also in future be off completely for weeks (I hope no 
longer for months). In these periods I tried at least to keep the 
installer running.


regards Uwe

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

[Richard Heck]

On 10/19/2015 08:55 AM, Vincent van Ravesteijn wrote:

On Mon, Oct 19, 2015 at 1:38 PM, Jean-Marc Lasgouttes
 wrote:

The title says it all. I'd like to add some header in there that the lyx-cvs 
list can use to allow the message, instead of restricting to subscribers.

JMarc

It is in a git hook in a script called .git/hooks/post-receive or
post-commit or something like that. This is in the .git directory on
the server.


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.


Richard

Re: LyX's master is now uncompilable

[Uwe Stöhr]

Am 19.10.2015 um 21:29 schrieb Vincent van Ravesteijn:


I fixed it at 10d7f6d.


Many thanks Vincent! This fixes the compilation for me.

best regards
Uwe

Re: [LyX/master] tcolorbox.module: uniform whitespace

[Uwe Stöhr]

Am 19.10.2015 um 21:49 schrieb Georg Baum:


And can you please stop submitting new features (and even in a way that does
not follow the rules and breaks tests)


Please not. it is the same than months before - I don't understand what 
I break. I did not even change source code, except of lyx2lyx. I 
promised to follow the Development.lyx file and I did, see my according 
post.



while others are cleaning up behind
you which you did not yo yourself although several reminders were sent
during the last 5 months?


Oh I did not get them. What did I break and never fixed?

regards Uwe

Re: Many tex2lyx failing now on master

[Uwe Stöhr]

Am 19.10.2015 um 20:55 schrieb Scott Kostyshak:


There is some at lib/doc/Development.lyx

I see lots of diffs of the form

  #LyX file created by tex2lyx 2.2
-\lyxformat 497
+\lyxformat 498
and the commit ce933b1e14 has incremented the format to 498. Could that
alone make the tests fail?


I don't understand what I made wrong. I only changed something in a 
module and added a fileformat change for lyx2lyx. I did not change any 
tex2lxy test file nor did I change tex2lyx code.


I also followed lib/doc/Development.lyx sec. 2.3. This references sec. 
3.2.2 and I tried that too, but this is not possible on my PC:


I use CMake. So I opened a MSVC console with all build commands loaded. 
The result is:


D:\LyXGit\Master\src\tex2lyx\test>make updatetex2lyxtests
MAKE Version 5.2  Copyright (c) 1987, 1998 Inprise Corp.
Fatal: Unable to open makefile

So if anybody could please tell me what I should do I will do this and 
also update lib/doc/Development.lyx accordingly.


thanks and regards
Uwe

Re: Regression in lyx2lyx box alignment

[Richard Heck]

On 10/19/2015 03:46 PM, Georg Baum wrote:

Jean-Marc Lasgouttes wrote:


Le 18/10/15 17:01, Georg Baum a écrit :

What is wrong with the new alignment handling? It is IMHO confusing and
not needed, we have paragraph alignment. Look at the attached example: I
set the box alignment to centered, and the paragraph alignment to right.
This will produce \centered \begin{flushright} which does not really make
sense. I think we should try to be consistent and not offer different
ways to do the same thing unless there is a very clear advantage (which I
do not see in this case). Has this change been discussed on the list? If
yes, then I missed it.

I'd like to hear about reasons for this feature, but s you describe it,
I think it should be removed.

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
paragarph 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.


I do therefore vote for removing the new aligment handling again. I have
no strong optinion whether we should prefer option 2) or 3). Basically we
need to decide which is more important: Old documents imported into 2.2
during the last 5 months, or new documents created during the last 5
months? I slightly tend towards 2), also because it is less work.

How much less work is it?

2) can be implemented by applying the attached patch. 3) would need the
attached patch + the one from the last mail + lyx2lyx code to convert the
alignment options to ERT (I think anything else than ERT would be far too
much work). If I would do it, it would take me probably a few hours (but
honestly I currently have zero motivation for doing it, since the next new
feature that needs to be cleaned up was committed).


What was this code supposed to do?

I'm happy with option (2), if we do remove this code. People who use 
2.2.dev for actual work are taking this kind of risk, and it's not that 
terrible.


Richard

Re: [LyX/master] Add math cell positions to TexRow

[Guillaume Munch]

Le 20/10/2015 00:42, Scott Kostyshak a écrit :

On Tue, Oct 20, 2015 at 12:24:24AM +0100, Guillaume Munch wrote:


In order to try to compile the file I believe you need to have R
installed. Do you have R installed? If not, are you interested in
installing it to debug this? I could explain how on Ubuntu. I would not
blame you if you are not interested installing a large package just to
debug this strange case (all the other four thousand tests are not
changed by this commit). Further, my (wild) guess is that the problem is
not because of your code directly, but because we probably don't handle
Japanese documents as good as we should. I can try to take a deeper look
if you don't want to look into it.


My guess is that the problem is because of my code. Since I cannot test
directly, please try the attached, I believe it fixes.


I am impressed with your debug skills! I don't know how you could figure
out the problem based on simply "the test times out" but somehow you
did.


:)



The tests that timed out now pass. Please commit. I will do a full run
of the tests tonight to see if anything else changes.


Done.



Thanks for the quick fix,


Thank you.



Guillaume

Re: [LyX/master] Add math cell positions to TexRow

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:56:13AM +0200, Guillaume Munch wrote:
> commit 65d61e7a2786172da95ed9433ed0c49a7398f405
> Author: Guillaume Munch 
> Date:   Wed Oct 14 00:17:05 2015 +0100
> 
> Add math cell positions to TexRow
> 
> This is preliminary work for extending the cursor<->row tracking to math.
> 
> TexRow used to associate, to each row, a location id/pos where id 
> determines a
> paragraph and pos the position in the paragraph.
> 
> TexRow now associates to each row a list of entries, text or math. A math 
> is a
> pair uid/idx where uid will determine a math inset and idx is the number 
> of the
> cell.
> 
> The analogy id/pos<->inset/idx works better than the analogy 
> id/pos<->idx/pos,
> because what matters for the TexRow algorithm(TM) is the behaviour in 
> terms of
> line breaks.
> 
> This only improves the source view and the forward search, not the error 
> report
> and the reverse search (though this could be easily added now).

The following tests now time out because of this commit (at least a git
bisect suggests this):

export/examples/ja/knitr_pdf2
export/examples/ja/sweave_pdf3
export/examples/ja/knitr_pdf3
export/examples/ja/sweave_pdf
export/examples/ja/knitr_pdf
export/examples/ja/sweave_pdf2

The exports are supposed to fail because for Japanese it seems that
pdflatex does not work. In fact, before this commit, the error message
given from the logs is pretty informative:

! LaTeX Error: This file needs format `pLaTeX2e'
   but this is `LaTeX2e'.

So the problem is not that the compilation does not succeed. The problem
is that after this commit, LyX's export does not finish.

Taking the example
export/examples/ja/sweave_pdf2
this is testing the export of the file lib/examples/ja/sweave.lyx with
pdflatex. When I do this manually (graphically or on command line) LyX
also seems to hang on the export.

In order to try to compile the file I believe you need to have R
installed. Do you have R installed? If not, are you interested in
installing it to debug this? I could explain how on Ubuntu. I would not
blame you if you are not interested installing a large package just to
debug this strange case (all the other four thousand tests are not
changed by this commit). Further, my (wild) guess is that the problem is
not because of your code directly, but because we probably don't handle
Japanese documents as good as we should. I can try to take a deeper look
if you don't want to look into it.

In any case, before we spend any time I think the first step is to see
if anyone else who already has R installed can reproduce this. Kornel,
Liviu, JMarc? Does the export finish for you after this commit?

Scott

Re: Change tracking output issues

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 02:27:54PM -0400, Paul A. Rubin wrote:
> Hi all,
> 
> I couldn't find an open bug report on either of these, so I thought I'd ask
> for input here. The following apply to LyX 2.1.4.
> 
> Issue #1: In the User Guide, section 6.16, the last paragraph says that
> dvipost must be installed to show changes in the output. I've been showing
> changes in output (pdflatex) just fine without it. Is this advice out of
> date?
> 
> Issue #2: The /only/ format that lets me show changes as changes is
> pdflatex. All other formats compile the document but give no indication
> where the changes are. Am I missing something?

Hi Paul, can you send a minimal example to the list so we can see if we
see the changes in other formats? So to confirm, if you compile with
XeTeX or LuaTeX you do not see the changes?

Scott

Re: [LyX/master] Add math cell positions to TexRow

[Guillaume Munch]

Le 19/10/2015 23:58, Scott Kostyshak a écrit :

On Mon, Oct 19, 2015 at 07:56:13AM +0200, Guillaume Munch wrote:

commit 65d61e7a2786172da95ed9433ed0c49a7398f405
Author: Guillaume Munch 
Date:   Wed Oct 14 00:17:05 2015 +0100

 Add math cell positions to TexRow

 This is preliminary work for extending the cursor<->row tracking to math.

 TexRow used to associate, to each row, a location id/pos where id 
determines a
 paragraph and pos the position in the paragraph.

 TexRow now associates to each row a list of entries, text or math. A math 
is a
 pair uid/idx where uid will determine a math inset and idx is the number 
of the
 cell.

 The analogy id/pos<->inset/idx works better than the analogy 
id/pos<->idx/pos,
 because what matters for the TexRow algorithm(TM) is the behaviour in 
terms of
 line breaks.

 This only improves the source view and the forward search, not the error 
report
 and the reverse search (though this could be easily added now).


The following tests now time out because of this commit (at least a git
bisect suggests this):

export/examples/ja/knitr_pdf2
export/examples/ja/sweave_pdf3
export/examples/ja/knitr_pdf3
export/examples/ja/sweave_pdf
export/examples/ja/knitr_pdf
export/examples/ja/sweave_pdf2

The exports are supposed to fail because for Japanese it seems that
pdflatex does not work. In fact, before this commit, the error message
given from the logs is pretty informative:

! LaTeX Error: This file needs format `pLaTeX2e'
but this is `LaTeX2e'.

So the problem is not that the compilation does not succeed. The problem
is that after this commit, LyX's export does not finish.

Taking the example
export/examples/ja/sweave_pdf2
this is testing the export of the file lib/examples/ja/sweave.lyx with
pdflatex. When I do this manually (graphically or on command line) LyX
also seems to hang on the export.

In order to try to compile the file I believe you need to have R
installed. Do you have R installed? If not, are you interested in
installing it to debug this? I could explain how on Ubuntu. I would not
blame you if you are not interested installing a large package just to
debug this strange case (all the other four thousand tests are not
changed by this commit). Further, my (wild) guess is that the problem is
not because of your code directly, but because we probably don't handle
Japanese documents as good as we should. I can try to take a deeper look
if you don't want to look into it.


My guess is that the problem is because of my code. Since I cannot test 
directly, please try the attached, I believe it fixes.



diff --git a/src/TexRow.cpp b/src/TexRow.cpp
index 4bec66e..1d1c80c 100644
--- a/src/TexRow.cpp
+++ b/src/TexRow.cpp
@@ -208,7 +208,7 @@ bool TexRow::getIdFromRow(int row, int & id, int & pos) const
 	if (row <= int(rowlist_.size()))
 		while (row > 0 && isNone(t = rowlist_[row - 1].getTextEntry()))
 			--row;
-	if (row > 0)
+	if (!isNone(t))
 		ret = true;
 	id = t.id;
 	pos = t.pos;

Re: Regression in lyx2lyx box alignment

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:05:07PM -0400, Richard Heck wrote:

> I'm happy with option (2), if we do remove this code. People who use 2.2.dev
> for actual work are taking this kind of risk, and it's not that terrible.

+1

Scott

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

[Uwe Stöhr]

Am 19.10.2015 um 07:47 schrieb Scott Kostyshak:


Is that code in the preample needed, Uwe?


I use the same code in other manuals too. E.g. in the Math manual.

It is useful to save writing things like "section" all the time and one 
can change it easily to "sec." or whatever.



It would be nice to keep the
examples as clean as possible. This example file does not compile with
system fonts (using either XeTeX or LuaTeX).


For me it compiles with pdflatex, XeTeX and LuaTeX.

I don't understand why the same code compiles for you in the Math manual.

regards Uwe

Re: [LyX/master] tcolorbox.module: uniform whitespace

[Uwe Stöhr]

Am 19.10.2015 um 07:50 schrieb Scott Kostyshak:

On Mon, Oct 19, 2015 at 07:15:21AM +0200, Uwe Stöhr wrote:

commit 8da453fd30a1df085782ae5a3772a07cea38b77b
Author: Uwe Stöhr 
Date:   Mon Oct 19 07:15:18 2015 +0200

 tcolorbox.module: uniform whitespace


Uwe can you please catch up on reading the emails on the mailing list
before making new commits? We need to be on the same page.


I had a look before. There was no code freeze announced. Adding new 
styles to a layout file should not harm.


I wonder why the module was added to LyX without any description. Now we 
have a nice description and the feature is now in my opinion very useful 
for real life documents.


regards Uwe

Re: bug 9626: new handling of "LyX" is unintuitive

[PhilipPirrip]

On 10/19/2015 04:48 PM, Georg Baum wrote:

- rename the top level menu "Special Characters" to "Special Characters &
>>Strings"

>
>
>This is what a programmer would call it, but I think this is just too
>long for a menu entry (and who knows what it'd be in other languages).
>Why not simply Symbols, or if you want it, Special Symbols?

I think the current Symbols menu is well named, since it is like this in
other applications as well. I agree however that "Special Characters &
Strings" is a bit technical, so I'll look how a documenters toolbar would
look like.




LibreOffice has it as "Special Characters". Fedora Linux has an 
application called "Character Map" that lists characters by, I believe, 
unicode blocks.
And all those are just single characters. Symbols, though, can be one or 
more: Greek alpha or \LaTeX

Just my 5 cents.

Re: When to court Qt 5.6?

[Uwe Stöhr]

Am 15.10.2015 um 01:18 schrieb Scott Kostyshak:


Uwe can you confirm that shipping our alpha with Qt 5.6 beta is
feasible for you?


Hi Scott,

I am open for anything. I think that i will need in any case some help 
from Vincent - in the past some Win-only changes were required to be 
able to compile with new Qt versions.


Besides this I am still using MSVC 2010. I need to update to MSVC 2012 
or newer and this is another challenge. I already tested MSVC 2012 with 
Qt 5.5 with success. Let's see what Qt 5.6 supports and if I can then 
still compile LyX 2.1.x with Qt 4.x and MSVC 2010 on the same PC.


regards Uwe

Re: When to court Qt 5.6?

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 02:32:05AM +0200, Uwe Stöhr wrote:
> Am 15.10.2015 um 01:18 schrieb Scott Kostyshak:
> 
> >Uwe can you confirm that shipping our alpha with Qt 5.6 beta is
> >feasible for you?
> 
> Hi Scott,
> 
> I am open for anything. I think that i will need in any case some help from
> Vincent - in the past some Win-only changes were required to be able to
> compile with new Qt versions.

Good point. This is indeed a possible and we've had to make several
changes on Linux and Mac to take into account platform-specific issues
with Qt 5, I believe.

> Besides this I am still using MSVC 2010. I need to update to MSVC 2012 or
> newer and this is another challenge. I already tested MSVC 2012 with Qt 5.5
> with success.

Great! Hopefully Qt 5.6 won't change much as far as compilation.

Have you tried on a recent master? We've made a lot of changes, some of
them having to do with Qt. It would be good to know that Qt 5.5 still
works well for you.

By the way, are you aware of any regressions on Windows when using Qt
5.5 over Qt 4.8.6? I think you reported a couple of bugs and I can look
for them, but I was just curious if you had an updated status report on
the general performance of Qt 5.5 and 2.2dev.

> Let's see what Qt 5.6 supports and if I can then still compile
> LyX 2.1.x with Qt 4.x and MSVC 2010 on the same PC.

Indeed, we will know on October 27 when the beta is released.

Scott

Re: [LyX/master] tcolorbox.module: uniform whitespace

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 01:28:52AM +0200, Uwe Stöhr wrote:
> Am 19.10.2015 um 07:50 schrieb Scott Kostyshak:
> >On Mon, Oct 19, 2015 at 07:15:21AM +0200, Uwe Stöhr wrote:
> >>commit 8da453fd30a1df085782ae5a3772a07cea38b77b
> >>Author: Uwe Stöhr 
> >>Date:   Mon Oct 19 07:15:18 2015 +0200
> >>
> >> tcolorbox.module: uniform whitespace
> >
> >Uwe can you please catch up on reading the emails on the mailing list
> >before making new commits? We need to be on the same page.
> 
> I had a look before. There was no code freeze announced. Adding new styles
> to a layout file should not harm.
> 
> I wonder why the module was added to LyX without any description. Now we
> have a nice description and the feature is now in my opinion very useful for
> real life documents.

OK I look forward to the new feature!

Thanks,

Scott

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

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 01:25:25AM +0200, Uwe Stöhr wrote:
> Am 19.10.2015 um 07:47 schrieb Scott Kostyshak:
> 
> >Is that code in the preample needed, Uwe?
> 
> I use the same code in other manuals too. E.g. in the Math manual.

I object to those also :)
But since you are doing the work on the manuals, I think your opinion
should count for more.

> It is useful to save writing things like "section" all the time and one can
> change it easily to "sec." or whatever.
> 
> >It would be nice to keep the
> >examples as clean as possible. This example file does not compile with
> >system fonts (using either XeTeX or LuaTeX).
> 
> For me it compiles with pdflatex, XeTeX and LuaTeX.
> 
> I don't understand why the same code compiles for you in the Math manual.

It compiles for me as well with pdflatex, XeTeX and LuaTeX with TeX
fonts. It does not compile with system fonts. If you are curious (no
need to do this now though), to see if it compiles for you with system
fonts, check the box "Use non-TeX fonts" and choose some fonts, e.g.
FreeSans.

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.

Scott

Re: Regression in lyx2lyx box alignment

[Scott Kostyshak]

After rereading the below email I just realized I often use the term
"we" and "us". Sorry about that. I do not mean to pretend like I am
speaking on behalf of everyone (I do not forget that I am a relative
newcommer here!). Instead of taking the time to correct all the "we" and
"us" I am just issuing this apology in advance.

On Tue, Oct 20, 2015 at 02:11:46AM +0200, Uwe Stöhr wrote:
> Am 20.06.2015 um 05:11 schrieb Scott Kostyshak:
> 
> >The attached file produces a left-aligned box in 2.1.3 but a centered
> >box for 2.2dev.
> >
> >Uwe I remember you've done a lot of work on boxes in master. Can you
> >take a look? I did not do a git bisect (let me know if this would be
> >useful).
> 
> It would have been nice to send me at least a direct mail to assure
> that I am informed.

I CC'ed you on the following emails (it hides that I CC'ed you but if
you search for the message in your email client it should show it):
https://www.mail-archive.com/search?l=mid=20150620031110.GA7412%40VAW70
https://www.mail-archive.com/search?l=mid=CAO7dr0ibT5vdRz_dxEphozZTeNOZJLn%3DkXpk%3DwVGWSMERfTyMw%40mail.gmail.com
https://www.mail-archive.com/search?l=mid=20151010175502.GA6939%40cotopaxi
https://www.mail-archive.com/search?l=mid=20151016193502.GA6689%40cotopaxi

And you responded to one here:
https://www.mail-archive.com/search?l=mid=55872177.2040708%40web.de
and I really appreciate that you took the time to do that.
I thought you would make a note so that when you did have time to work
on LyX that would be the first thing you worked on since it was
considered a possible regression.

Which email address is best?
uwesto...@web.de or uwesto...@lyx.org ? I tried both.

Perhaps I misunderstand what you mean by a "direct" email---Is there a
difference on your end whether I CC you or put you in the "to" header?
Which do you prefer?

> The new feature to set a horizontal alignment is very useful (at least I
> already use this already) and therefore it would be sad if you remove the
> whole feature.

I don't understand how it is useful. Why can't use you use the paragraph
alignment? Please respond to Georg's email on this matter.

> I feel a lot of aggression against me in todays' posts.

I see what you mean, but I would say if anything there is aggression
towards your *work flow*. LyX developers are a team and we want to be on
the same page as much as possible. Everyone will work differently and
that is fine, but when those differences affect other people that is
when frustration happens. Just to take the recent example of the tex2lyx
tests failing. Because of your commit, I spent time tracking down the
problem, Kornel spent time running the tests and reporting the failure,
Georg spent time confirming your commit was the issue, Guillaume spent
time trying to fix the issue, and Gűnter had finally fixed the tests
that he broke but there was confusion because at the same time you broke
the tests so it wasn't clear whether it was his commit or your commit.
I'm not necessarily saying it's your fault, but I'm saying that because
of something you did a lot of people lost time on a not-so-fun activity.
So this is why we have rules. I think if you tried to understand how
this could be frustrating for a lot of us then that might help
understand why sometimes we get upset.

What if no one fixed the commit that was causing master to fail to
compile for you on master? What if Guillaume, the one who introduced the
issue, went away for 5 months and none of the other developers did
anything about it because we all use Linux and it compiles fine for us?
And what if Guillaume came back after a few months and the first thing
he did was work on a bunch of issues that had nothing to do with the
compilation failure? Would you be frustrated? I think this example also
shows how many developers today wanted to fix an issue that is affecting
you even if it isn't affecting them. Guillaume, Georg, and Vincent all
kindly jumped in to help and fix the problem that only you were affected
by.

So in summary, I think that this is all just a bunch of failed
communication. You have communicated to us why some things are difficult
for you (e.g. the tex2lyx tests, Git). We need to make a sincere effort
at understanding that it is difficult for you and doing our best to make
it easier. And on your end I think it would help if you understood how
some of the things that you do cause other developers wasted time and
frustration. I know that you do not do it intentionally, but whether it
is intentional or not, it causes frustration.

I have a few ideas that could make things better:

1. It seems a good idea to me that whenever you (or anyone else of
course) make a file format change, run the tex2lyx tests. If a test
fails, then do not commit. If you don't know how to proceed, send an
email to lyx-devel *before you commit* asking for help.

2. Let's work together to find a way so that we can notify you and get
your responses. What email client do you use? How can we set up 

Re: [LyX/master] Adding TexRow information on math latex output (#4725)

[Jean-Marc Lasgouttes]

Le 19/10/2015 17:31, Guillaume Munch a écrit :

The next thing that we need for line tracking is Sweave support; sweave
does rewrite some parts of the document, and therefore the line numbers
are not accurate anymore. It is however possible to ask sweave to output
a correspondence file, but we have to make use of it...


Is there a ticket with minimal working examples?


Not yet unfortunately. The R Sweave() function has a "concordance" 
option that creates a file giving line concordance. I'll try to create a 
bug report.



There is now "TexRow concatenation" which allows to write to a string
buffer and still have the TexRow information, so maybe the first issue
is easy to fix if it uses that kind of mechanism. (There's now accurate
reporting for subcaptions thanks to this.


Not sure. The texrow lines will refer to the Rnw file created by LyX, 
and the LaTeX errors will be from the .tex file created by sweave from 
the .Rnw file.


JMarc

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

[Guenter Milde]

On 2015-10-19, Guenter Milde wrote:
> On 2015-10-19, Jean-Marc Lasgouttes wrote:

>> Guenter, you should now be able to post to lyx-cvs. You are not 
>> subscribed to this list, but just whitelisted.

>> I am working out a better solution with Máté right now.

> Thank you very much, Jean-Marc,

I committed the patches for bug #9764, so now the macron below vs. minus
sign below problem should be fixed. 
http://www.lyx.org/trac/changeset/7e716a26a5e/lyxgit

tex2lyx test pass again here.

Please give it a try.

Günter

Re: Regression in lyx2lyx box alignment

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 11:01:37AM +0200, Jean-Marc Lasgouttes wrote:
> Le 18/10/15 17:01, Georg Baum a écrit :
> >What is wrong with the new alignment handling? It is IMHO confusing and not
> >needed, we have paragraph alignment. Look at the attached example: I set the
> >box alignment to centered, and the paragraph alignment to right. This will
> >produce \centered \begin{flushright} which does not really make sense. I
> >think we should try to be consistent and not offer different ways to do the
> >same thing unless there is a very clear advantage (which I do not see in
> >this case). Has this change been discussed on the list? If yes, then I
> >missed it.
> 
> I'd like to hear about reasons for this feature, but s you describe it, I
> think it should be removed.

+1

Scott

Re: LyX's master is now uncompilable

[Uwe Stöhr]

Am 19.10.2015 um 18:26 schrieb Guillaume Munch:


I fail to see a problem with this commit after reading it again. I would
like to do some trial-and-error but not being able to reproduce makes it
complicated.


It is also not clear to me what triggers the error.


Is that all the information that the compiler gives you?


Unfortunately yes.


Does it not give you the name of the file?


No, what I posted is all I get.

regards Uwe

Re: We don't want google to index trac tickets?

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 11:06:03AM +0200, Jean-Marc Lasgouttes wrote:
> Le 17/10/15 00:52, Scott Kostyshak a écrit :
> >I was trying to view a trac ticket and because our server is down I
> >wanted to find it on google and view the cache.
> >
> >I entered the following into google:
> >site:http://www.lyx.org/trac/ticket/
> >
> >This results in many entries that say:
> >A description for this result is not available because of this site's
> >robots.txt
> 
> We could use something less brutal as proposed here:
> http://trac.edgewall.org/ticket/6124

That would be nice. A good time to look into that might be if/when we
upgrade trac.

Scott

Re: [PATCH] Get rid of ParagraphMetrics::insetDimension

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 12:16:58PM +0200, Jean-Marc Lasgouttes wrote:
> Le 15/10/15 18:07, Richard Heck a écrit :
> >>The only changed behavior is that the CoordCache asserts when
> >>requiring a non existing cache entry, where insetDimension would
> >>return a dummy value. This can lead to some crashes, but I would say
> >>that these are welcome in some cases.
> >
> >Is there something sensible to do in release mode in this case? rather
> >than crash?
> 
> I updated the patch to return null values and now I wonder whether this was
> a good idea. Currently it throws a buffer exception and saves the file
> before crashing.
> 
> We could maybe keep this for 2.2alpha and change our mind if it causes too
> many problems. I do not think that relying on default values is a good idea.

Sounds like a good plan.

Scott

Re: Translations and 2.2.alpha?

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 05:54:32AM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > On Sun, Oct 18, 2015 at 01:56:57PM -0400, Richard Heck wrote:
> > > 
> > > Do we want to give our translators a chance to get stuff in for 2.2.alpha?
> > > Or has that already been done?
> > 
> > This has not been done yet. I had thought this was done at a later
> > stage. For example it seems for 2.1.0 it was done before beta:
> > https://www.mail-archive.com/search?l=mid=50E0.1050404%40lyx.org
> > 
> > Should we do it before alpha?
> 
> New features coming should be officially stop before that and it takes
> quite a while to prepare new translation (thousands of lines to fix and test)
> so don't expect them to have it in the timefrane of the next week.
> So I would say no :)
> Pavel

Well we can adjust the timeframe if necessary (it is already delayed
because of Qt 5.6 beta delay). If this is important or there is
precedence then we can delay a couple of weeks.

Scott

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

[Kornel Benko]

Am Montag, 19. Oktober 2015 um 17:00:34, schrieb Guenter Milde 

> On 2015-10-19, Guenter Milde wrote:
> > On 2015-10-19, Jean-Marc Lasgouttes wrote:
> 
> >> Guenter, you should now be able to post to lyx-cvs. You are not 
> >> subscribed to this list, but just whitelisted.
> 
> >> I am working out a better solution with Máté right now.
> 
> > Thank you very much, Jean-Marc,
> 
> I committed the patches for bug #9764, so now the macron below vs. minus
> sign below problem should be fixed. 
> http://www.lyx.org/trac/changeset/7e716a26a5e/lyxgit
> 
> tex2lyx test pass again here.

Here they do not pass.
# ctest -R tex2lyx
->
The following tests FAILED:
  6 - tex2lyx/roundtrip/test.ltx (Failed)
  8 - tex2lyx/roundtrip/algo2e.tex (Failed)
 10 - tex2lyx/roundtrip/box-color-size-space-align.tex (Failed)
 12 - tex2lyx/roundtrip/CJK.tex (Failed)
 14 - tex2lyx/roundtrip/CJKutf8.tex (Failed)
 16 - tex2lyx/roundtrip/test-insets-basic.tex (Failed)
 18 - tex2lyx/roundtrip/test-insets.tex (Failed)
 20 - tex2lyx/roundtrip/test-memoir.tex (Failed)
 22 - tex2lyx/roundtrip/test-modules.tex (Failed)
 24 - tex2lyx/roundtrip/test-refstyle-theorems.tex (Failed)
 26 - tex2lyx/roundtrip/test-scr.tex (Failed)
 28 - tex2lyx/roundtrip/test-structure.tex (Failed)
 30 - tex2lyx/roundtrip/verbatim.tex (Failed)
 32 - tex2lyx/roundtrip/XeTeX-polyglossia.tex (Failed)
Errors while running CTest

Do you still have a clean source tree?

> Please give it a try.
> 
> Günter

Kornel


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

Re: Moving towards a 2.2 release

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 08:18:30PM +, Guenter Milde wrote:

> I realised that this not only applies to compilation with Xe/LuaTeX which
> is a good thing -- it also catches cases like small letters missing in
> most math-script fonts (To fix the description in lib/RELEASE-NOTES, just
> trim the sentence.)

I made the change (although you are most welcome to edit the
RELEASE-NOTES).

> > Without this fix, users might not be aware that their compiled PDF will
> > not show some characters. Although some users might be annoyed by
> > seeing errors they did not see before, (1) it is important to give
> > these errors to them so they know about the problem and (2) there is a
> > "Show Output Anyway" button so if they want to view their PDF as they
> > did in 2.1.x, they still can.
> 
> This are the two new features I like most.
> 
> > Fixing #9744 would have the following advantages:
> > 1. It would allow fixing some of the missing glyphs errors. It is not
> > clear how many users will run into this particular issue (see Günter's
> > comment here: http://www.lyx.org/trac/ticket/9610#comment:18).
> 
> > 2. It would fix compilation of the manuals, as well as many of our
> > tests. 
> 
> I am afraid that while this change will prevent compilation errors, the
> result is different from before, so any tests that compare the output (or
> the tex file) must be adapted.

Actually the tests are not that sophisticated. They just check whether
the compilation runs without error (ie it checks the exit code from
command-line export)

> I have a partial fix for the "Xe/LuaTeX with TeX-fonts" problem. The fix
> prevents compilation errors with luatex and improves he situation a bit
> for xetex (the difference is, that there is "luainputenc" but no
> "xetexinputenc" in TeXLive and the standard "inputenc" package currently
> refuses to work with xetex unless the encoding is utf8).
> 
> Should I commit the patch or wait?

Please commit.

And if you ever want to experiment and know the results of the tests
before committing, let me or Kornel know (or both).

Scott

Re: [patches] the last ones before 2.2

[Jean-Marc Lasgouttes]

Le 19/10/2015 17:21, Guillaume Munch a écrit :

Ok. I tried to go that route, but then figured that I had to adapt the
code for copy/paste, duplicate row/column, etc. which I tried to avoid.


I can understand that :)

JMarc

Re: LyX's master is now uncompilable

[Guillaume Munch]

Le 19/10/2015 16:50, Uwe Stöhr a écrit :

Am 19.10.2015 um 16:14 schrieb Uwe Stöhr:


one of todays' commits broke the compilation for me with MSVC:

  C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\include\xstring(982):
error C2491: 'std::numpunct<_Elem>::id': Definition of static data
member for dllimport is not allowed
[D:\LyXGit\Master\compile-result\src\LyX.vcxproj]


The commit to blame is

http://www.lyx.org/trac/changeset/65d61e7a2786172da95ed9433ed0c49a7398f405/lyxgit


Guillaume?

thanks and regards
Uwe



I fail to see a problem with this commit after reading it again. I would 
like to do some trial-and-error but not being able to reproduce makes it 
complicated.


Is that all the information that the compiler gives you? Does it not
give you the name of the file?

I tried to understand the error message with what comes up on Google and 
I cannot relate it to my code. In addition, one of the first hits on 
Google is about a message on this list 
, 
so it is possible that the bug is elsewhere (while still fixable by 
adapting my code).


I expect something trivial that I have never encountered yet. Anybody 
else sees the problem?



Guillaume

Re: [LyX/master] cmake: Put updatetex2lyxtests in an appropriate folder

[Kornel Benko]

Am Montag, 19. Oktober 2015 um 18:02:02, schrieb Vincent van Ravesteijn 

> commit 92b7c5a92f21956f6da19c8ac783cd9132ca82b9
> Author: Vincent van Ravesteijn 
> Date:   Mon Oct 19 17:50:59 2015 +0200
> 
> cmake: Put updatetex2lyxtests in an appropriate folder
> 
> diff --git a/src/tex2lyx/test/CMakeLists.txt b/src/tex2lyx/test/CMakeLists.txt
> index e11b345..c513d6e 100644
> --- a/src/tex2lyx/test/CMakeLists.txt
> +++ b/src/tex2lyx/test/CMakeLists.txt
> @@ -71,3 +71,4 @@ add_custom_command(
>  )
>  
>  add_custom_target(updatetex2lyxtests DEPENDS LyxTestFiles)
> +set_target_properties(updatetex2lyxtests PROPERTIES FOLDER "tests/tex2lyx")

Why is that important? This is only a phony target ..., there should be no data 
in the specified "tests/tex2lyx" folder.
In fact, there is no such folder on my platform.

Kornel


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