Re: Regression in lyx2lyx box alignment

[Jean-Marc Lasgouttes]

Le 20/10/2015 04:39, Scott Kostyshak a écrit :

Many developers pop in and out. I think JMarc is the only developer who
is consistent. It is a wonder how he has not gone insane yet (or maybe
he is pushing his commits from the inside of an insane asylum?).


Am I supposed to resent this? (don't worry, I don't :)

Indeed, I can confirm that working long-term with LyX (like any project, 
I guess) leads to intermittent frustration. It can only be balanced by a 
personal satisfaction given by what you create by your work. Or the 
satisfaction of seeing that your work is helpful to others.


However, the team is an ecosystem and keeping this ecosystem alive and 
well is a necessity to be able to be able to do your own creation. This 
is why it is so important to care this interaction.

JMarc

Re: Many tex2lyx failing now on master

[Kornel Benko]

Am Dienstag, 20. Oktober 2015 um 01:04:36, schrieb 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.

It is this 'fileformat change'. The files (*.lyx.lyx) created now by 
tex2lyx are now different
(the first 2 lines of a created file reads
#LyX file created by tex2lyx 2.2
\lyxformat 497
)

> 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

You should use the correct target for your platform.
This 'make updatetex2lyxtests' is meant for linux.
For Windows it may be something with appropriate solution, e.g. 'msbuild 
updatetex2lyxtests.sln' (I am guessing here, Vincent will know)

> 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

Kornel

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

Re: Many tex2lyx failing now on master

[Guenter Milde]

On 2015-10-19, Uwe Stöhr wrote:
> 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.

A fileformat change is IMO a "big" change that should be agreed with the
release manage so short before an alpha release.

As the tex2lyx tests compare the result of converting a *.tex file with a
stored example of the expected LyX file, they need updating with every
change to the default settings and bits in these LyX files, including the
fileformat number.

> 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:

If the hint that a fileformat change requires adapting the test examples is
missing there, this is a documentation bug.

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

If there is agreement to the fileformat change, replacing the fileformat
number in the *.lyx and *.lyx.lyx files in the tex2lyx tests would
(hopefully) solve the issue. I can confirm that before these changes but
applying my patches for "combining lines below", tests passed.

In addition, adding the "change the fileformat numer for tests" requirement
to Development.lyx would help prevent others to fall in this trap and
frustration by others frentically trying to get the tests in shape before a
release.

Günter

Re: [LyX/master] Refine lang nesting fix

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:59:59PM -0400, Scott Kostyshak wrote:
> 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.

I think I found a few more. I do not know enough to say whether it is
worth your time to look into them. You have already explained that this
part of the code needs to be redesigned from the ground up. In any case,
here are the others I found:

These two have errors of the type you've been fixing
(e.g. "\begin{otherlanguage} on input line 377 ended by \end{itemize}")
They both compile well when "always babel" is selected.
export/doc/nb/Intro_pdf5_systemF
export/doc/sk/Intro_pdf5_systemF

The following seems like a different case:
export/doc/fr/UserGuide_pdf5_systemF
It compiles fine with "Always babel". With polyglossia it gives the following 
error:
! Undefined control sequence.
\in@ #1#2->\begingroup \def \in@@ 
  ##1#1{}\toks@ \expandafter {\in@@ #2{}{}#1...

I don't know if that is related to the type of bugs you've been fixing.

Let me know if you want me to look for more.

Scott

Re: LyX's master is now uncompilable

[Georg Baum]

Guillaume Munch wrote:

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

Sure, our messages crossed each other, I would not have suggested that if I 
knew that he had time to test.

The compilation error could btw easily be fixed by moving the implementation 
of the methods in a .cpp file (I would suggest to use 
src/support/docstream.cpp where id is already implemented, since adding a 
new .cpp would not be trivial: It would not need to be compiled on unix for 
example).


Georg

Re: Regression in lyx2lyx box alignment

[Georg Baum]

Scott Kostyshak wrote:

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

As far as I am concerned, the "we" is fine. I could not have expressed the 
reasons for my frustration in a better way.

> You are very valuable to the development of LyX, Uwe. I don't think
> there is any doubt about that. Without you, I sincerely think LyX would
> suffer in many dimensions. I hope that development of LyX will become
> fun again for you as I think it once was. Let me know if there's
> anything I can do to help with that.

Let me second that. I would not want to loose you.


Georg

Re: Moving towards a 2.2 release

[Guenter Milde]

On 2015-10-20, Scott Kostyshak wrote:
> 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).

It is the same change that I did here locally, thanks.

...

> 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)

Except for the tex2lyx tests.

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

Done. tex2lyx test still pass.

There are some more "easyfix" patches in the pipeline:

#9770   unicodesymbols replacements for wasysym text symbols

and a symbols-invdiameter.patch:

diff --git a/lib/symbols b/lib/symbols
index 89fc41a..992f556 100644
--- a/lib/symbols
+++ b/lib/symbols
@@ -695,8 +695,7 @@ hexstarwasy  65  0 x
 varhexstar wasy  66  0 x
 davidsstar wasy  67  0 x
 diameter   wasy  31  0 x
-# Unicode is wrong, but a true alternate doesn't seem available.
-invdiameterwasy  21  0 x
+invdiameterwasy  21  0 x
 varangle   wasy  30  0 x
 wasylozengewasy  53  0 x
 kreuz  wasy  54  0 x


Commit?


Günter

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 19-10-2015 om 23:36 schreef 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.


Unfortunately, the patch doesn't work.

"docstring.h" includes "strfwd.h", which now includes 
"numpunct_lyx_char_type.h", which uses "from_ascii", which is defined in 
"docstring.h".


Vincent

LyX 2.2 testing OS X 10.11 / retina display

[Ian Weiner]

Hi,

This is in response to a post by Scott Kosty on latex-community.org.

I'd be interested in testing out an OS X build of LyX 2.2 when it's reached
the appropriate development stage. Drop me a line with more info when the
time comes.

Thanks,
Ian

Re: Many tex2lyx failing now on master

[Georg Baum]

Guenter Milde wrote:

> I updated the lyxformat number in the src/tex2lyx/test/*.lyx.lyx files and
> now all tex2lyx tests pass here.

Very good.

Just to avoid future errors: I assume that you did check before that a 
simple update of the format number is OK, and that no tex2lyx source code 
changes are needed? How to do such checks in described in section 2.3 of 
Development.lyx, item 5.


Georg

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

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 07:16:44PM +0200, Günter Milde wrote:
> commit 1523fc6023440f10ca0d82a681ded5c060d8fd33
> Author: Günter Milde 
> Date:   Tue Oct 20 19:14:39 2015 +0200
> 
> Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
> 
> Fixes output for 3 of the 4 test lyx-files.
> 
> Includes "FIXME"s at places where further action is required to get the 
> XeTeX
> export right but I don't know how.
> ...

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

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

Scott

Re: Form is function

[Scott Kostyshak]

On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
> Scott asked not long ago what could be done to make it easier for
> newcomers. It is now clear to me that having a clearer bug tracker
> is an aspect that can be improved. In addition, the initial question
> was to know what to do with tickets with an unmet milestone.
> 
> 
> Taking into account what has been said, here are three proposition:
> 
> 
> 1. Milestones remain the main recipient of triaging information
>   + Unmet milestones are reverted to ".x", which are given more
> visibility.
>   + Severity is the secondary information used to order the lists.
>   + Color is supposed to distinguish enhancements from defects, though
> it is not really observed currently (indeed this colour code was
> kept secret!).
>   - As I see it, it leads to an information which is fragmented between
> three different milestones, which is maybe why it did not work in
> the past.
> 
> 
> or:
> 
> 
> 2. Priority (colour) becomes the main recipient of the triaging
>information.
>+ A list of all "important" defects regardless of milestone is
>  given visbility in addition to what we have already.
>+ "Important" enhancement are shown as well in a list separate from
>  the previous one; the colour do not means the same for
>  enhancements and defects.
>+ An unmet milestone can be removed safely: bump the priority if
>  necessary.
>- While colouring is attractive, it is against pre-existing
>  conventions. The colour code should be similar for defects
>  (yellow/red) but would differ for enhancements (essentially all
>  light blue enhancements would become untriaged).
>- Also, severity was already used to rate tickets on a scale.
> 
> 
> or a new proposition:
> 
> 
> 3. Severity becomes the main recipient of the triaging information.
>   + A list of all important defects regardless of milestone
> (major/critical/blocker) is given the visibility.
>   + A list of all consensual enhancements regardless of milestone is
> found at the end of the front page (e.g. major/critical).
>   + An unmet milestone can be removed safely; bump the severity if
> necessary.
>   + Does not invalidate the color convention which we can explain
> separately, and is consistent with the previous use of severity.
 
>From what I understand there has been no preference expressed by anyone
besides Guillaume on this. Does anyone else prefer one of the three
options (or a different one)? Liviu since you have been involved earlier
in the discussion, can you summarize your opinion with respect to the
propositions Guillaume outlined (or a new proposition) ?

Guillaume (and others), I would like to go through the bugs with
milestone 2.2 soon. My only goal will be to figure out which tickets
should keep 2.2 as a milestone and which should not. I'll make some
decisions about moving some tickets to 2.3 or 2.2.x but I do not plan on
thinking carefully about the severity or importance. I will assume that
anyone who cares about the particular ticket will modify it accordingly.
If someone prefers a different plan, please let me know.

Scott

Re: Many tex2lyx failing now on master

[Georg Baum]

Guenter Milde wrote:

> On 2015-10-19, Uwe Stöhr wrote:
> 
>> 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.

It is all documented in Development.lyx.
 
>> 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:

If a procedure that is documented to be required for certain changes does 
not work, then I would expect every developer to ask on the list for help 
_before submitting_ instead of ignoring the issue.
 
> If the hint that a fileformat change requires adapting the test examples
> is missing there, this is a documentation bug.

The hint is there, in section 2.3.

> In addition, adding the "change the fileformat numer for tests"
> requirement to Development.lyx would help prevent others to fall in this
> trap and frustration by others frentically trying to get the tests in
> shape before a release.

It is already in. The only thing which is indeed missing is a description 
how running the tests and updating the test references works with MSVC. 
Unfortunately I don't know that, otherwise I would have documented it. 
Vincent, maybe you can find that out?

If you think that anything else is missing in the documentation of file 
format changes or concerning the tex2lyx tests, then please tell what you'd 
expect, and we can improve the docs.


Georg

Re: When to court Qt 5.6?

[Georg Baum]

Uwe Stöhr wrote:

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

I would suggest to use the newest stable version, with is currently MSVC 
2015. Then you need to update and adjust to changes look and feel less 
often.

In general, installing two MSVC versions in parallel is no problem, the same 
is true for qt. The only thing you need to make sure is that none of these 
versions is listed in the PATH or other environment variables. Then you can 
use two build.bat files for the two versions, and set all needed environment 
variables (e.g. adding the qt bin dir to PATH for moc etc) separate in these 
two files.

Furthermore, a new MSVC version requires a new dependency package. As I 
already wrote to David Hyde (who wants to compile LyX with a newer MSVC), I 
think that the current procedure of providing the binaries for a sepcific 
MSVC version produces too much work in the long run. Instead, a python or 
cmake script to download the sources of the dependencies and compile them 
should be written. This is more effort initially, but pays off in the long 
term, and also removes some pressure from you, since others can then create 
the dependencies they need without manual work for you.


Georg

Re: Change tracking output issues

[Kornel Benko]

Am Montag, 19. Oktober 2015 um 14:27:54, schrieb 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

I tried your example, all available pdf formats are displaying the change here.
(E.g. 
PDF (ps2pdf), PDF (pdflatex), PDF (dvipdfm), PDF (XeTeX), PDF (LuaTeX)
)

Exporting to dvi with 'DVI (LuaTex)' is wrong, but export to 'DVI' is OK.

This is with TL2015 and lyx 2.2dev

Kornel



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

Re: Change tracking output issues

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 06:15:13PM +0200, Kornel Benko wrote:
> Am Montag, 19. Oktober 2015 um 14:27:54, schrieb 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
> 
> I tried your example, all available pdf formats are displaying the change 
> here.
> (E.g. 
>   PDF (ps2pdf), PDF (pdflatex), PDF (dvipdfm), PDF (XeTeX), PDF (LuaTeX)
> )
> 
> Exporting to dvi with 'DVI (LuaTex)' is wrong, but export to 'DVI' is OK.
> 
> This is with TL2015 and lyx 2.2dev

I did not test (I assume I get the same result as Kornel since I have a
similar system), but I suppose the next step is to send the .tex files.
e.g. instead of exporting to PDF (pdflatex) export to LaTeX (pdflatex).

Scott

Re: Change tracking output issues

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 03:49:40PM +, Paul A. Rubin wrote:
> Scott Kostyshak  lyx.org> writes:
> 
> 
> > 
> > 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,
> 
> I'm not set up to use LuaTeX (and don't know how to use XeTeX); I'm just
> testing the "old school" formats.

I don't actually know how to use XeTeX either, but LyX takes care of the
necessary XeTeX-specific things so it just works for me. If it doesn't
work for you then it is probably because of a non-trivial preamble.

I'm not suggesting you switch to XeTeX. I also use pdfTeX. I just say
the above in case anyone out there is curious.

Scott

Re: Update on the patches

[Guillaume Munch]

Le 09/10/2015 22:07, Jean-Marc Lasgouttes a écrit :

Le 09/10/2015 22:06, Georg Baum a écrit :

Even more interesting. I always thought that LyX uses the "use tabs for
logical indentation, and spaces for visual alignment" model for C++ code.
This way, it does not matter at all whether you display a tab as 4 or 8
spaces wide or anything else, and this is IMHO a good thing (I have first
hand knowledge for preferenes of 2, 3, 4, and 8 spaces wide).


I would be interested by an emacs configuration that respects this. I
have to do it by hand every time...

JMarc




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

Re: Many tex2lyx failing now on master

[Guenter Milde]

On 2015-10-19, Scott Kostyshak wrote:
> 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.

...

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

I updated the lyxformat number in the src/tex2lyx/test/*.lyx.lyx files and
now all tex2lyx tests pass here.

Commited at a0e2d48a569510dce6f3f288ee7a14e239cd4de2/lyxgit

Hope this helps,

Günter

Re: Change tracking output issues

[Paul A . Rubin]

Scott Kostyshak  lyx.org> writes:


> 
> 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,

I'm not set up to use LuaTeX (and don't know how to use XeTeX); I'm just
testing the "old school" formats.

I'm accessing the list through GMANE, so I can't attach files. Instead, I
zipped up a minimal example and parked it in my public Dropbox folder:
https://www.dropbox.com/s/m84n1te4n2n6c3j/change%20tracking.zip?dl=0. I
included three PDF output files (generated via pdflatex, ps2pdf and dvipdfm)
and one DVI file. They all contain the changes, but only the first one shows
them properly formatted.

Paul

Re: Many tex2lyx failing now on master

[Kornel Benko]

Am Dienstag, 20. Oktober 2015 um 20:18:33, schrieb Georg Baum 

> Guenter Milde wrote:
> 
> > On 2015-10-19, Uwe Stöhr wrote:
> > 
> >> 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.
> 
> It is all documented in Development.lyx.
>  
> >> 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:
> 
> If a procedure that is documented to be required for certain changes does 
> not work, then I would expect every developer to ask on the list for help 
> _before submitting_ instead of ignoring the issue.
>  
> > If the hint that a fileformat change requires adapting the test examples
> > is missing there, this is a documentation bug.
> 
> The hint is there, in section 2.3.
> 
> > In addition, adding the "change the fileformat numer for tests"
> > requirement to Development.lyx would help prevent others to fall in this
> > trap and frustration by others frentically trying to get the tests in
> > shape before a release.
> 
> It is already in. The only thing which is indeed missing is a description 
> how running the tests and updating the test references works with MSVC. 
> Unfortunately I don't know that, otherwise I would have documented it. 
> Vincent, maybe you can find that out?

This is easy, because it is not platform specific.
The command 'ctest' comes together with cmake, so everyone using cmake has it 
too.

> If you think that anything else is missing in the documentation of file 
> format changes or concerning the tex2lyx tests, then please tell what you'd 
> expect, and we can improve the docs.
> 
> 
> Georg


Kornel

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

Re: Regression in lyx2lyx box alignment

[Uwe Stöhr]

Am 20.10.2015 um 04:39 schrieb Scott Kostyshak:


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):


Hm, now I see them. There were automatically moved into the spam folder 
where also all the commit report mails are placed. This is strange but 
it is then no wonder that I overlooked them. (I cannot not follow all 
commits.)



And you responded to one here:
https://www.mail-archive.com/search?l=mid=55872177.2040708%40web.de


This was months ago and the stress is still the same.

it sucks that I cannot plan much. E.g I was just informed that I have to 
work abroad again. And again I can most probably not do anything for LyX 
the next days...



Which email address is best?
uwestoehr-at-web.de or uwestoehr-at-lyx.org ? I tried both.


Both should work.


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.


Since I have to get up in 5 hours and will be off then, I CCed him.

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


That's why I implemented the alignment in LyX 2.2. as non-paragraph via 
\raggedleft etc because a parbox or minibox is already its own paragraph.



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 see. Any you are totally right that it is not OK to steal time from 
others knowing what a high value time is.


Nevertheless one must discuss how useful the tests are if they make so 
many troubled what anybody just changed a layout file without touching 
tex2lyx. I still think that the main purpose of the tex2lyx tests should 
be to test tex2lyx capabilities.


The point is that every new rule increases the barrier to attract new 
developer and to hold developers active. In my case I knew I would have 
maximal 2 days not knowing when I will be able to LyX again. And I of 
course knew that the first LyX 2.2 cannot be far away and then a 
fileformat change for simple things like layout changes are then no 
longer possible. So sometimes just putting things in is sensible. (I 
know Georg hates me for statements like that.) However, now I have the 
situation I feared but my feature is in and there is time to fix 
possible issues in the alpha/beta cycle. I don't see the big problems 
despite that I stole your time with the tex2lyx test issue.


I know that I am very controversial and that I sometimes just can't 
resist. The good point is that It made so much fun that I wanted to 
re-join the development despite I know that it will be a hard task with 
the real-life stress.


So finally apologies to Georg, Guillaume, Kornel and Günter that you 
need to spend time for tex2lyx.
I hope we will find a solution soon that I can do things right also on 
Windows too.


regards Uwe


Box21.lyx
Description: application/lyx


Box22.lyx
Description: application/lyx

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 20-10-2015 om 20:06 schreef Georg Baum:

Guillaume Munch wrote:


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

Sure, our messages crossed each other, I would not have suggested that if I
knew that he had time to test.

The compilation error could btw easily be fixed by moving the implementation
of the methods in a .cpp file (I would suggest to use
src/support/docstream.cpp where id is already implemented, since adding a
new .cpp would not be trivial: It would not need to be compiled on unix for
example).


Ok, that's what I did.

Vincent

Re: Regression in lyx2lyx box alignment

[Georg Baum]

Uwe Stöhr wrote:

> ( 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 .)

Do you mean that your ISP does not provide an NNTP server anymore, or that 
it actively blocks the NNTP ports? The former would not be any problem (just 
use news.gmane.org, which I am doing btw as well). The latter would be a 
strange ISP.

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

I already did that for you: 
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg189325.html However, I 
still think that the paragraph 
alignment can be used instead, and would like to have an explanation what is 
wrong with the paragraph version. If the box alignment is kept, then we need 
a considerable amount of work to finish it (see the other messages in this 
thread), and the question is who would do that.

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

IIRC the rules in the past were more strict. Anybody remembering the old 
changelogs which had much more detailed descriptions of the changes, and the 
requirement to send all patches to the list first? The only exception is the 
rule about the tex2lyx tests, but it has already proven to be very useful, 
because the tests have already detected many bugs which would have gone 
unnoticed for a long time otherwise. The last such case was the wrong symbol 
for 0x0320 in lib/unicodesymbols, which was detected after a recent addition 
by Günter because a) you created a test case with this symbol a long time 
ago and b) we require that the tests do always pass. The other rules listed 
in Development.lyx have basically always been there, but never explicitly 
documented.

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

You are not the only one who has trouble using git: 
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg187328.html

For example, I mainly use git for LyX development like "svn + stash", and 
keep two separate working trees for branch and master. I would recommend a 
similar worflow for you as well, this would also avoid rebasing problems as 
those which were fixed with 741e5267131. Many git features are confusing for 
me as well, and I always have the impression that the defaults are wrong 
(e.g. I always use git cherry-pick -n). Fortunately all this is 
configurable, so if you find out a workflow once you can write it down and 
do not need to understand the details anymore for using it in the future.

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

It all depends on you. Many people are willing to help (me included). If you 
don't know how to do something, please ask, and we will find a solution. I 
do however expect that once a solution has been found, you will remember it 
(by whatever method that works for you) and not ask the same question again. 
I also expect all developers to learn from mistakes. It is no problem if 
something goes wrong, but if the reasons for a mistake have been identified, 
then I expect that they will be avoided in the future.

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

We all have times when real life interferes for a shorter or longer period. 
Sometimes there are also emergencies, so somebody needs to stop all work 
completely for an unforseeable amount of time. IMHO the LyX developers can 
cope well with such cases, and nobody needs to justify if he needs to stop. 
However, if such a period ends, and there is time again for LyX development, 
then I expect that no new fun stuff is started until all leftover stuff from 
previous work is addressed. It is important that there is some balance 
between developers for fun and non-fun work, otherwise those who do most of 
the non-fun stuff will 

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

[Guenter Milde]

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

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

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

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

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

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

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

Günter

Re: When to court Qt 5.6?

[Vincent van Ravesteijn]

Op 15 okt. 2015 08:37 schreef "Jean-Marc Lasgouttes" :
>
> Le 15/10/15 01:06, Scott Kostyshak a écrit :
>
>> LyX 2.2.0 and the following 2.2.x releases will still continue to work
>> well with Qt 4.8.6 but will also support Qt 5.6, which brings some
>> advantages most notably for users with HiDPI displays. Note that if you
>> compile LyX with a Qt 5 release before 5.6 you are likely to run into
>> several regressions with respect to Qt 4.8.6. See #9215 for a list of
>> bugs related to compiling LyX with different versions of Qt.
>
>
> The minimum Qt version is actually 4.5, although I do not know who is
able to check that. I could try to test it in a virtual machine, though.
>
> JMarc
>

I use Qt 4.8.? but I have problems with the code to read icons. I cannot
read svgz pixmaps, and GuiApplication::iconName only looks whether a file
exists but does not take into account whether a certain file is readable.

I want to fix this soon.

Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

Am 19.10.2015 um 16:42 schrieb Jean-Marc Lasgouttes:


Welcome back!


Thanks JMarc for the info.


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 ;)


What do you mean? Apparently I missed your mail too.

regards Uwe

Re: When to court Qt 5.6?

[Vincent van Ravesteijn]

Op 20 okt. 2015 02:32 schreef "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

Why do you need to update to MSVC 2012 ? Qt 5.5 was still released with
2010 libraries. Given the fact that some of our dependencies are also built
with 2010, it looks safest not to switch versions right now.

Vincent

Re: When to court Qt 5.6?

[Vincent van Ravesteijn]

Op 20 okt. 2015 20:35 schreef "Georg Baum" :
>
> Uwe Stöhr wrote:
>
> > 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.
>
> I would suggest to use the newest stable version, with is currently MSVC
> 2015. Then you need to update and adjust to changes look and feel less
> often.
>
> In general, installing two MSVC versions in parallel is no problem, the
same
> is true for qt. The only thing you need to make sure is that none of these
> versions is listed in the PATH or other environment variables. Then you
can
> use two build.bat files for the two versions, and set all needed
environment
> variables (e.g. adding the qt bin dir to PATH for moc etc) separate in
these
> two files.
>
> Furthermore, a new MSVC version requires a new dependency package. As I
> already wrote to David Hyde (who wants to compile LyX with a newer MSVC),
I
> think that the current procedure of providing the binaries for a sepcific
> MSVC version produces too much work in the long run. Instead, a python or
> cmake script to download the sources of the dependencies and compile them
> should be written. This is more effort initially, but pays off in the long
> term, and also removes some pressure from you, since others can then
create
> the dependencies they need without manual work for you.
>
>
> Georg
>

First, it looks like that the 2010 libraries can work with at least MSVC
2012. Is that because MSVC 2010 is or was also installed on the same
machine? If so, releasing such a hybrid might give troubles that won't be
foreseen. So, better to warn Uwe as he claims to have tested with MSVC 2012
and Qt 5.5.

Second, I guess it's up to me to figure out compiling the dependencies. I
remember that Joost had manually changed gettext to be able to make
suitable libraries. Did we get rid of gettext libs completely or do we
still need it (besides the msgmerge and friends applications) ?

It's a good idea to update cmake to download the sources.

Vincent

Re: Form is function

[Liviu Andronic]

On Tue, Oct 20, 2015 at 8:52 PM, Scott Kostyshak  wrote:
> On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
>> Scott asked not long ago what could be done to make it easier for
>> newcomers. It is now clear to me that having a clearer bug tracker
>> is an aspect that can be improved. In addition, the initial question
>> was to know what to do with tickets with an unmet milestone.
>>
>>
>> Taking into account what has been said, here are three proposition:
>>
>>
>> 1. Milestones remain the main recipient of triaging information
>>   + Unmet milestones are reverted to ".x", which are given more
>> visibility.
>>   + Severity is the secondary information used to order the lists.
>>   + Color is supposed to distinguish enhancements from defects, though
>> it is not really observed currently (indeed this colour code was
>> kept secret!).
>>   - As I see it, it leads to an information which is fragmented between
>> three different milestones, which is maybe why it did not work in
>> the past.
>>
>>
>> or:
>>
>>
>> 2. Priority (colour) becomes the main recipient of the triaging
>>information.
>>+ A list of all "important" defects regardless of milestone is
>>  given visbility in addition to what we have already.
>>+ "Important" enhancement are shown as well in a list separate from
>>  the previous one; the colour do not means the same for
>>  enhancements and defects.
>>+ An unmet milestone can be removed safely: bump the priority if
>>  necessary.
>>- While colouring is attractive, it is against pre-existing
>>  conventions. The colour code should be similar for defects
>>  (yellow/red) but would differ for enhancements (essentially all
>>  light blue enhancements would become untriaged).
>>- Also, severity was already used to rate tickets on a scale.
>>
>>
>> or a new proposition:
>>
>>
>> 3. Severity becomes the main recipient of the triaging information.
>>   + A list of all important defects regardless of milestone
>> (major/critical/blocker) is given the visibility.
>>   + A list of all consensual enhancements regardless of milestone is
>> found at the end of the front page (e.g. major/critical).
>>   + An unmet milestone can be removed safely; bump the severity if
>> necessary.
>>   + Does not invalidate the color convention which we can explain
>> separately, and is consistent with the previous use of severity.
>
> From what I understand there has been no preference expressed by anyone
> besides Guillaume on this. Does anyone else prefer one of the three
> options (or a different one)? Liviu since you have been involved earlier
> in the discussion, can you summarize your opinion with respect to the
> propositions Guillaume outlined (or a new proposition) ?
>

I think #1 is more or less what we have now, slightly simplifying the
way we roll milestones (into the .x stack) or drop milestones
altogether ("very" old .x reports can be safely decommissioned).
#2 will allow to much better keep track of "important" tickets, across
major releases, but it will also require some change in bugtracker
habits as well as more or less constant supervision (at least at
first). It will require from devels a conscious triaging effort to
assess importance, but it will allow to not forget important issues or
missing features even when they're very old.
#3 seems to be like the above while keeping our current color
conventions on bugtracker.

In truth, I have only but a small voice in this. Best would be for our
release managers and active developers to signal which scheme they
would be most comfortable with. And as Pavel has already mentioned,
the crucial part for either of Guillaume's proposals---since they
involve more departure from what we are currently doing---would be for
him to become actively involved in the triaging efforts on Bugtracker
for "some" time, so that the new habits stick with the old-timers;
otherwise devels will probably simply revert to what they've been used
to before.

If Guillaume does assume this role, I think either of the proposed
schemes could work just nicely, and maybe we really do need a more
sensible and nuanced way to prioritize the importance of incoming
reports and keep track of them across major releases (as long as it is
indeed the devel team that decides on the priorities, not the
reporters)... And since Guillaume is clearly motivated, I think a
change in bugtracker practices could ultimately prove a positive a
change for the team in terms of moving the project forward.

Regards,
Liviu


> Guillaume (and others), I would like to go through the bugs with
> milestone 2.2 soon. My only goal will be to figure out which tickets
> should keep 2.2 as a milestone and which should not. I'll make some
> decisions about moving some tickets to 2.3 or 2.2.x but I do not plan on
> thinking carefully about the severity or importance. I will assume that
> anyone who cares about the 

LyX 2.2 OSX 10.11 - retina display test

[Mag. Georg Kö]

Dear all,

let me start  let me start by saying kudos to all of you! I is really fantastic 
what Lyx provides especially as an application for scholars around the world. 
As I quit doing development several years ago I won’t be any help in this 
regard. Would be more than willing though to contribute by reporting issues or 
help with translation stuff (German, Dutch and a little bit French …). I’m 
working on a MBP Retina 13“ 2015 with 10.11 (15A282a). If I can be of any help, 
just drop me a note, if not, thanks a bunch for the fab work and good luck for 
the next release.

Cheers, G.

Re: Change tracking output issues

[Paul A . Rubin]

Scott Kostyshak  lyx.org> writes:

> 
> On Tue, Oct 20, 2015 at 06:15:13PM +0200, Kornel Benko wrote:

> > 
> > I tried your example, all available pdf formats are displaying the
change here.
> > (E.g. 
> > PDF (ps2pdf), PDF (pdflatex), PDF (dvipdfm), PDF (XeTeX), PDF (LuaTeX)
> > )
> > 
> > Exporting to dvi with 'DVI (LuaTex)' is wrong, but export to 'DVI' is OK.
> > 
> > This is with TL2015 and lyx 2.2dev

Kornel: Thanks for testing this. I'm using TL2013 and LyX 2.1.4. I wonder if
either of the version differences could be the culprit?

> 
> I did not test (I assume I get the same result as Kornel since I have a
> similar system), but I suppose the next step is to send the .tex files.
> e.g. instead of exporting to PDF (pdflatex) export to LaTeX (pdflatex).
> 

Scott: I exported both pdflatex and "plain" versions, and just for grins I
compiled the plain version in a shell. The DVI file contains no markup.
Comparing the two .tex files, all differences are in the header; the bodies
are identical. I've zipped up both .tex files and the .aux, .dvi and .log
files from the "plain" version here:
https://www.dropbox.com/s/xgv720xpzyt8hh2/change%20tracking%202.zip?dl=0.

Regarding XeTeX, it's installed, and I have the option to export to "LaTeX
(XeTeX)", but there's no option in Document > View (Other Formats) that
mentions XeTeX.

Thanks for the attention.

Paul

Re: Regression in lyx2lyx box alignment

[Richard Heck]

On 10/20/2015 04:07 PM, Georg Baum wrote:
...I mainly use git for LyX development like "svn + stash", and keep 
two separate working trees for branch and master. 


I do the same, just because compiling is faster this way (and disk space 
is cheap).


Many git features are confusing for me as well, and I always have the 
impression that the defaults are wrong (e.g. I always use git 
cherry-pick -n). Fortunately all this is configurable, 


It's particularly configurable via aliases. My own preference is for the 
options -e and -x, hence I have as a git alias:

cp = cherry-pick -e -x
In memory of svn:
ci = commit -a
One can do almost anything with aliases. But, more importantly:

so if you find out a workflow once you can write it down and do not 
need to understand the details anymore for using it in the future. 


This is the important thing, and it could even be put on the wiki.

Richard

Re: Translations and 2.2.alpha?

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 07:30:07PM +0200, Jean-Marc Lasgouttes wrote:
> 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.

OK, my plan is the following:

- 3 weeks before the planned beta, send an email to Uwe to see if he has
  time to copy the translations from 2.1.x to master as he has done for
  previous major releases
- After Uwe is done with that (or if he doesn't have time), send an
  email to lyx-docs and to the translators directly asking them to
  prepare translations.

And then I will do the above for each subsequent beta (if necessary) and
release candidate (perhaps not as long as 3 weeks before because they
probably need less time because they already hopefully translated
everything for the first beta).

Does that seem reasonable?

How do I email the translators directly? Do we have a script to pull the
emails of the current translators from the po files?

Scott

Re: Change tracking output issues

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 10:03:27PM +, Paul A. Rubin wrote:

> > I did not test (I assume I get the same result as Kornel since I have a
> > similar system), but I suppose the next step is to send the .tex files.
> > e.g. instead of exporting to PDF (pdflatex) export to LaTeX (pdflatex).

I do indeed have the same result as Kornel.

> Scott: I exported both pdflatex and "plain" versions, and just for grins I
> compiled the plain version in a shell. The DVI file contains no markup.
> Comparing the two .tex files, all differences are in the header; the bodies
> are identical. I've zipped up both .tex files and the .aux, .dvi and .log
> files from the "plain" version here:
> https://www.dropbox.com/s/xgv720xpzyt8hh2/change%20tracking%202.zip?dl=0.

I think you do actually have dvipost. Your log file suggests that it is
here:
/home/paul/texmf/tex/latex/dvipost/dvipost.sty

I wonder if this could be the critical difference between your setup and
Kornel's/mine. If you are curious enough to take the risk of tweaking
your system, you could try uninstalling dvipost and reconfiguring LyX
and trying again. If it works for you after, then this might be a LyX
bug.

> Regarding XeTeX, it's installed, and I have the option to export to "LaTeX
> (XeTeX)", but there's no option in Document > View (Other Formats) that
> mentions XeTeX.

I find this strange. I did not do anything special to set it up. I would
be *slightly* worried that something is off for your LaTeX installation
(note though that I know little about LaTeX installations). XeTeX is
somewhat mature so it should be in TL 2013. On the command line can you
run

  xelatex --version

Scott

Re: LyX 2.2 testing OS X 10.11 / retina display

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 02:43:39PM -0400, Ian Weiner wrote:
> Hi,
> 
> This is in response to a post by Scott Kosty on latex-community.org.
> 
> I'd be interested in testing out an OS X build of LyX 2.2 when it's reached
> the appropriate development stage. Drop me a line with more info when the
> time comes.

Great, I'll add you to the list of testers I have. Our alpha should be
out soon. Be careful to back everything up, expect it to crash, and to
not do serious work on it.

Scott

Re: LyX 2.2 OSX 10.11 - retina display test

[Scott Kostyshak]

On Wed, Oct 21, 2015 at 12:21:11AM +0200, "Mag. Georg Kö" wrote:
> Dear all,
> 
> let me start  let me start by saying kudos to all of you! I is really 
> fantastic what Lyx provides especially as an application for scholars around 
> the world. As I quit doing development several years ago I won’t be any help 
> in this regard. Would be more than willing though to contribute by reporting 
> issues or help with translation stuff (German, Dutch and a little bit French 
> …). I’m working on a MBP Retina 13“ 2015 with 10.11 (15A282a). If I can be of 
> any help, just drop me a note, if not, thanks a bunch for the fab work and 
> good luck for the next release.

Hi Georg K (there is another Georg active on the list so I will use your
last initial just to make things easier. If you have a nickname or
prefer to be referred to differently, let us know),

You came along at an exciting time! We are just starting the release
process for the next major LyX version, 2.2.0. You can see a list of the
new features here:
http://wiki.lyx.org/LyX.NewInLyX22

2.2.0 Alpha will be released soon. If you would like, testers are always
useful. I could email you directly if you want to be notified of the
alpha release.

Well-written bug reports and enhancements are in my opinion the best way
to contribute to open source. You can register at
http://www.lyx.org/trac
and start giving us feedback there for specific topics. Or drop us an
email at lyx-devel if a certain piece of feedback or question doesn't
fall under the bug/enhancement category. You might also be interested in
hanging out on the lyx-users list, which has a good frequency I think.
Depends on what you're looking for though.

As for translations, our German and French are in pretty good condition
I think, but our Dutch translation seems to be a bit neglected, as you
can see here:
http://www.lyx.org/I18n-trunk
Translation work can be difficult, frustrating, and time-consuming in my
opinion. But it is also one of the most important jobs as it brings LyX
to more users and in their native language. If you think you're up for
the challenge and would find it fun, let us know and someone who knows
more about translations than I do can walk you through the beginning
steps so you can get started.

Welcome and thanks for the email!

Scott

Re: Moving towards a 2.2 release

[Scott Kostyshak]

On Tue, Oct 20, 2015 at 05:27:29PM +, Guenter Milde wrote:
> On 2015-10-20, Scott Kostyshak wrote:
> > 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).
> 
> It is the same change that I did here locally, thanks.

OK good.

> > 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)
> 
> Except for the tex2lyx tests.

Yes true.

> There are some more "easyfix" patches in the pipeline:
> 
> #9770 unicodesymbols replacements for wasysym text symbols

OK.

> and a symbols-invdiameter.patch:
> 
> diff --git a/lib/symbols b/lib/symbols
> index 89fc41a..992f556 100644
> --- a/lib/symbols
> +++ b/lib/symbols
> @@ -695,8 +695,7 @@ hexstarwasy  65  0 x
>  varhexstar wasy  66  0 x
>  davidsstar wasy  67  0 x
>  diameter   wasy  31  0 x
> -# Unicode is wrong, but a true alternate doesn't seem available.
> -invdiameterwasy  21  0 x
> +invdiameterwasy  21  0 x
>  varangle   wasy  30  0 x
>  wasylozengewasy  53  0 x
>  kreuz  wasy  54  0 x
> 
> 
> Commit?

Yes please.

Exception (basic_string) when saving on OSX.

[pdv]

I've been experiencing several exceptions on OSX, using commit 96f64ac0.
Sofar I've tracked down one of them:

A (basic_string) exception occurs when saving a document with a 
sufficient long filename (more than about 18 characters without the 
extension). Take any .lyx file and add characters to the name. Then open 
and save it.
As far as I can see this has been introduced with commit bb34445, which 
contains many changes, including some of the filetools.


Regards,

P. De Visschere