Re: why Babel with dvi3 (LuTeX)?

[Kornel Benko]

Am Freitag, 8. Januar 2016 um 21:47:21, schrieb Guenter Milde 

> On 2016-01-08, Scott Kostyshak wrote:
> > On Fri, Jan 08, 2016 at 06:31:37AM +, Guenter Milde wrote:
> >> On 2016-01-08, Scott Kostyshak wrote:
> 
> > Here is the diff:
> 
> >   $ diff ctests_d7ff8c6e/LastTestsFailed.log
> >   ctests_d7ff8c6e_with_patch/LastTestsFailed.log 
> >   0a1,2
> >  > 218:AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_dvi3_texF
> >  > 
> > 219:INVERTED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi3_systemF
> 
> A typo in the filter pattern.
> 
> >  > 3718:UNRELIABLE.NONSTANDARD_export/templates/kluwer_dvi3_systemF
> 
> This is tagged "unreliable" because it is known to fail st at some places or
> sometimes. 
> 
> Summary: There is no real regression due to the changes introduced by the
> patch. All changes in test results highlighted existing problems with either
> polyglossia or babel.
> 
> My suggestion is to commit the patch and do test filter adaption in a
> cleanup.
> 
> There is a tailback of patches fixing other issues now because of this one
> and I am running out of time.
> 
> Günter

After the last commit, this tests fail:
1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed)
1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed)
1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed)

and also
579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 
(Failed)
580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF 
(Failed)
581 - 
SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed)

Kornel



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

Re: Status on Mac with El Capitan

[Peter Kümmel]

Am 09.01.2016 um 13:12 schrieb Stephan Witt:

Am 08.01.2016 um 13:15 schrieb Kornel Benko :


Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt 

Am 08.01.2016 um 11:53 schrieb Kornel Benko :


Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt 

OR (maybe)
 include_directories((BEFORE
   ${TOP_SRC_DIR}/src/tex2lyx
   ${TOP_SRC_DIR}/src/support/minizip)
 include_directories(${ZLIB_INCLUDE_DIR})


Yes, this works too. BTW, what is "src/support/minizip“ for?
It doesn’t exist in the master checkout.
Why should "src/tex2lyx“ come before other includes?

Stephan


I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.


Yes, but what’s the gain of having "src/tex2lyx“ before other includes?


Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing 
it.


Peter, is the attached patch ok?


Removing the minizip should make no problems.



Stephan


I wanted to change as little as possible.


The removal of the BEFORE keyword did the job too.


Sure.

Re: Status on Mac with El Capitan

[Stephan Witt]

Am 08.01.2016 um 13:15 schrieb Kornel Benko :
> 
> Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt 
>> Am 08.01.2016 um 11:53 schrieb Kornel Benko :
>>> 
>>> Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt 
>>> 
> OR (maybe)
> include_directories((BEFORE
>   ${TOP_SRC_DIR}/src/tex2lyx
>   ${TOP_SRC_DIR}/src/support/minizip)
> include_directories(${ZLIB_INCLUDE_DIR})
 
 Yes, this works too. BTW, what is "src/support/minizip“ for?
 It doesn’t exist in the master checkout.
 Why should "src/tex2lyx“ come before other includes?
 
 Stephan
>>> 
>>> I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.
>> 
>> Yes, but what’s the gain of having "src/tex2lyx“ before other includes?
> 
> Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing 
> it.

Peter, is the attached patch ok?

Stephan

> I wanted to change as little as possible.
> 
>> The removal of the BEFORE keyword did the job too.
> 
> Sure.


tex2lyx-cmake.patch
Description: Binary data

Re: Status on Mac with El Capitan

[Stephan Witt]

Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes :Le 08/01/2016 10:08, Stephan Witt a écrit :Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :Yes, unless somone has a different brilliant idea.Am I right that it makes explicit what is otherwise implicit? So it is safe to commit?Yes, I think so. The question is only maintainability. Guillaume complained that the is fragile because new code can forget to add this explicit lyx::.Scott,I’d like to commit the patch (attached again). Is this ok?StephanThe problem is that libc++ provides std::next even when not in C++11 mode.Is the implementation of std::next compatible to the e.g. ParagraphList::iterator or not?It should. The problem is only that we provide boost::next when not in C++11 mode, but clang already provides the real std::next.The proper fix would be to check at configure time whether std::next exists and react on that. But it is extra work :)This problem will go away in 2.3.How? With your fix? Does it fix wrong LyX code or is it some work around?Because support for c++98 will go away, together with many of our lyx:: wrappers.Georg, do you have a thought on that?

lyx-iter-next-prev.patch
Description: Binary data

Re: Status on Mac with El Capitan

[Stephan Witt]

Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes :
> 
> Le 08/01/2016 10:08, Stephan Witt a écrit :
>> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :
>>> Yes, unless somone has a different brilliant idea.
>> 
>> Am I right that it makes explicit what is otherwise implicit? So it is safe 
>> to commit?
> 
> Yes, I think so. The question is only maintainability. Guillaume complained 
> that the is fragile because new code can forget to add this explicit lyx::.

Scott,

I’d like to commit the patch (attached again). Is this ok?

Stephan

> 
>>> The problem is that libc++ provides std::next even when not in C++11 mode.
>> 
>> Is the implementation of std::next compatible to the e.g. 
>> ParagraphList::iterator or not?
> 
> It should. The problem is only that we provide boost::next when not in C++11 
> mode, but clang already provides the real std::next.
> 
> The proper fix would be to check at configure time whether std::next exists 
> and react on that. But it is extra work :)
> 
>>> This problem will go away in 2.3.
>> 
>> How? With your fix? Does it fix wrong LyX code or is it some work around?
> 
> Because support for c++98 will go away, together with many of our lyx:: 
> wrappers.
> 
> Georg, do you have a thought on that?


lyx-iter-next-prev.patch
Description: Binary data

Re: why Babel with dvi3 (LuTeX)?

[Kornel Benko]

Am Samstag, 9. Januar 2016 um 15:07:32, schrieb Guenter Milde 

> Dear Kornel,
> 
> thank you for the quick test report.
> 
> On 2016-01-09, Kornel Benko wrote:
> 
> > After the last commit, this tests fail:
> > 1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed)
> > 1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed)
> > 1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed)
> 
> They work here. Can you establish the cause for failure and eventually add a
> patter to unreliable?

Manually it works. Compiling the changed file used by test I get

Missing character: There is no ☞ (U+261E) in font 
"FreeSans:mode=node;script=l

This was because of error in test-suite. In contrast to what I said that the 
font would be
replaced only if set to default, it was replaced unconditionally.
Works now.
I will wait for your commit before committing the correction.

> > and also
> > 579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 
> > (Failed)
> > 580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF 
> > (Failed)
> > 581 - 
> > SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed)
> 
> This was a mistake in the pattern, I'll upload a fix soon.
> 
> Günter

Kornel

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

Re: Questions for Uwe?

[Peter Kümmel]

Am 09.01.2016 um 01:32 schrieb Scott Kostyshak:

On Mon, Jan 04, 2016 at 10:58:13AM -0500, Scott Kostyshak wrote:

On Mon, Jan 04, 2016 at 08:56:38AM -0500, Scott Kostyshak wrote:

On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote:

Scott Kostyshak wrote:


I don't understand how installers work for 32-bit vs 64-bit. Normally
does our Windows installer contain both 32-bit and 64-bit binaries? Or
we just release 32-bit and 64-bit systems are fine with it? Same for
Mac?


So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not
switch to 64bit at this time, since this can introduce subtle bugs
(unfortunately the 64 C++ memory model differs on linux and windows, e.g.
long is 64bit on linux but 32bit on windows, so the fact that we have
working 64bit linux builds does not guarantee us working windows 64bit
builds).


I see. Thanks for the explanation. I agree we should not switch now.

Scott


Another question for Uwe. Can you still reproduce these two tickets?
http://www.lyx.org/trac/ticket/9892
http://www.lyx.org/trac/ticket/9900
That is part of the reason why I am curious about Qt 5.6.0beta1. Maybe
it makes those issues go away.

Scott


I have gone through this thread and tried to make a summary of the questions
and discussion for Uwe. Please add more questions if you have any or edit my
misinterpretation of the question/comment.

The following letters refer to the person that asked the question.

G=Georg
R=Richard
S=Scott

S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
and 5.6.0beta1?


There will be no downloadable msvc2010 builds for 5.6. ATM 
only 5.5.1:


http://www.qt.io/download-open-source/#section-2




S2. Can you make the installers from *only* the tar ball (and not use the
git directory at all)? Note that if there is a technical reason why this is 
difficult if you ask on the list I am guessing someone can help.

S3. Richard has been committing updates to po files. Can you confirm that all
translation updates we have received have been merged? Has anyone emailed 
updates to you privately?

R4. Do we also want to try releasing an installer built with mingw?
(G response: IMO, we only need to release one installer. The mingw and MSVC
builds behave exactly the same (modulo bugs). So the question is rather whether
we do trust MSVC or mingw, and who does the build: If it is Uwe, it will be
MSVC, otherwise it will probably be mingw.




G5. Not a question but a prerequisite IMHO: The 2.2.0 release should also build
the prerequisite from the sources Peter added, using exactly the same
compiler as is used to build LyX.


If Uwe tries to build the installer with the mingw build 
from the build bot, and it makes no problems, then a mingw

based installer isn't far away.



S6. Can you still reproduce these two tickets?
http://www.lyx.org/trac/ticket/9892
http://www.lyx.org/trac/ticket/9900
If so, do you think they are beta blockers?
That is part of the reason why I am curious about Qt 5.6.0beta1 (see question
S1). Maybe it makes those issues go away somehow.

Scott

Re: Status on Mac with El Capitan

[Kornel Benko]

Am Samstag, 9. Januar 2016 um 14:27:46, schrieb Stephan Witt 
> Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes :
> > 
> > Le 08/01/2016 10:08, Stephan Witt a écrit :
> >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :
> >>> Yes, unless somone has a different brilliant idea.
> >> 
> >> Am I right that it makes explicit what is otherwise implicit? So it is 
> >> safe to commit?
> > 
> > Yes, I think so. The question is only maintainability. Guillaume complained 
> > that the is fragile because new code can forget to add this explicit lyx::.
> 
> Scott,
> 
> I’d like to commit the patch (attached again). Is this ok?

It applies cleanly, compiles on linux. First tests are OK.

> Stephan

Kornel

> > 
> >>> The problem is that libc++ provides std::next even when not in C++11 mode.
> >> 
> >> Is the implementation of std::next compatible to the e.g. 
> >> ParagraphList::iterator or not?
> > 
> > It should. The problem is only that we provide boost::next when not in 
> > C++11 mode, but clang already provides the real std::next.
> > 
> > The proper fix would be to check at configure time whether std::next exists 
> > and react on that. But it is extra work :)
> > 
> >>> This problem will go away in 2.3.
> >> 
> >> How? With your fix? Does it fix wrong LyX code or is it some work around?
> > 
> > Because support for c++98 will go away, together with many of our lyx:: 
> > wrappers.
> > 
> > Georg, do you have a thought on that?

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

Re: why Babel with dvi3 (LuTeX)?

[Guenter Milde]

Dear Kornel,

thank you for the quick test report.

On 2016-01-09, Kornel Benko wrote:

> After the last commit, this tests fail:
>   1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed)
>   1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed)
>   1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed)

They work here. Can you establish the cause for failure and eventually add a
patter to unreliable?

> and also
>   579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 
> (Failed)
>   580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF 
> (Failed)
>   581 - 
> SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed)

This was a mistake in the pattern, I'll upload a fix soon.

Günter

Re: beta release

[Jean-Marc Lasgouttes]

Le 09/01/2016 01:15, Scott Kostyshak a écrit :

Georg's patch still needs a final +1:
https://www.mail-archive.com/search?l=mid=n6have%24b5i%244%40ger.gmane.org
JMarc did you have any other concerns with it? Does anyone else?


Unfortunately I do not know much about this origin business. My comment 
was about the fact that hardcoding the origin at install time feel wrong 
and I proposed an alternate solution. For later of course.


Beside the fact that I tend to trust Georg, I do not have much useful 
input here.


JMarc

Re: beta release

[Enrico Forestieri]

On Sat, Jan 09, 2016 at 03:36:52PM -0500, Richard Heck wrote:

> On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote:
> > Le 09/01/2016 01:15, Scott Kostyshak a écrit :
> >> Georg's patch still needs a final +1:
> >> https://www.mail-archive.com/search?l=mid=n6have%24b5i%244%40ger.gmane.org
> >>
> >> JMarc did you have any other concerns with it? Does anyone else?
> >
> > Unfortunately I do not know much about this origin business. My
> > comment was about the fact that hardcoding the origin at install time
> > feel wrong and I proposed an alternate solution. For later of course.
> 
> I'm afraid I'm in the same boat. Enrico may be the only other person who
> really understands it.

That would be really unfortunate, but I think that at least Georg understands 
it.
Anyway, I agree with whatever is decided and, FWIW, he has a +1 from me.
I have to say that I regret having introduced that parameter.

-- 
Enrico

Re: beta release

[Scott Kostyshak]

On Sat, Jan 09, 2016 at 11:03:53PM +0100, Enrico Forestieri wrote:
> On Sat, Jan 09, 2016 at 03:36:52PM -0500, Richard Heck wrote:
> 
> > On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote:
> > > Le 09/01/2016 01:15, Scott Kostyshak a écrit :
> > >> Georg's patch still needs a final +1:
> > >> https://www.mail-archive.com/search?l=mid=n6have%24b5i%244%40ger.gmane.org
> > >>
> > >> JMarc did you have any other concerns with it? Does anyone else?
> > >
> > > Unfortunately I do not know much about this origin business. My
> > > comment was about the fact that hardcoding the origin at install time
> > > feel wrong and I proposed an alternate solution. For later of course.
> > 
> > I'm afraid I'm in the same boat. Enrico may be the only other person who
> > really understands it.
> 
> That would be really unfortunate, but I think that at least Georg understands 
> it.
> Anyway, I agree with whatever is decided and, FWIW, he has a +1 from me.
> I have to say that I regret having introduced that parameter.

Just to make it clear, a +1 is worth a lot. It means "commit". Our
current policy is that a developer who posts a patch and gets a "+1" can
commit to master.

Scott


signature.asc
Description: PGP signature

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

[Enrico Forestieri]

On Thu, Dec 17, 2015 at 06:57:23PM +, Guillaume Munch wrote:
> 
> I also have another bug to report (very subtle and better seen in
> combination with the view source panel). There seems to be two cursor
> positions before and after the separator, both being displayed before
> the separator. One cannot access the second position with ← and →, but
> it is possible to do so with ↑ and ↓, and in that case using ← is as if
> it does nothing, but in the source we see that it goes from after the \n
> character to before it. Also, this means that we never know whether we
> must use delete or backspace to remove a separator. I think the
> intension was to hide the "after" position entirely.

The attached patch avoids the "after" position when moving with ↑ and ↓.

-- 
Enrico
diff --git a/src/Cursor.cpp b/src/Cursor.cpp
index c1eb32f..bf667e9 100644
--- a/src/Cursor.cpp
+++ b/src/Cursor.cpp
@@ -1947,6 +1947,8 @@ bool Cursor::upDownInText(bool up, bool & updateNeeded)
 			// Make sure that cur gets back whatever happened to dummy (Lgb)
 			operator=(dummy);
 		}
+		if (pos() && paragraph().isEnvSeparator(pos() - 1))
+		posBackward();
 	} else {
 		// if there is a selection, we stay out of any inset,
 		// and just jump to the right position:

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

[Richard Heck]

On 01/09/2016 05:24 PM, Enrico Forestieri wrote:
> On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote:
>> Le 11/12/2015 22:47, Enrico Forestieri a écrit :
>>> On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote:
> [...]
 • Defect: They tend to accumulate and they are redundant because there
   is only one additional '\n' in the LaTeX source. The problem is the
   one can add one before another. Thus, two such consecutive chars
   should be merged as a single one, like it is done for spaces in LyX.
>>> There were a lot of problems to be solved and this one was escaping me.
>>> Thank you for pointing it out. I will try to address it when I will find
>>> time (and motivation) to work again on LyX. Unfortunately, I will be
>>> unavailable the next weeks.
>> Thanks.
> The attached patch avoids the proliferation of parbreak seaparators.

Yes, this looks fine to me. Officially: +1.

Richard

Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)

[Guenter Milde]

On 2016-01-08, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> On Fri, Jan 08, 2016 at 08:11:19PM +0100, Kornel Benko wrote:
>> Am Freitag, 8. Januar 2016 um 12:21:44, schrieb Scott Kostyshak 
>> 
>> > On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote:

>> > > * FreeSans seems to provide the correct script-support info not to
>> > >   trigger the false-positive error
>> > >   http://www.lyx.org/trac/ticket/8035
>> > >   
>> > >   However, setting all of "mainfont", "sansfont", and "monofont"
>> > >   to FreeSans seems "hackish" to me.

>> No it is not hackish IMHO. The test should show, that with a suitable
>> font this file is compilable. It is a remnant from the times we had
>> defined fonts for texF only. If the non-tex font is defined in the
>> document, it will be used.

> I agree with Kornel that it is not hackish of the tests. 

I agree, that testing with system fonts is not bad. As long as this
requires a hack (like changing fonts or the "useNonTeXfonts" setting
"secretly" in a test script, this is not bad either.

However, it remains a hack and could/should be replaced if a better way of
operating is available.

Currently, if I want to check a failure with .*systemF, I have to

a) change it to use non-TeX fonts,
b) eventually set alternative system fonts
   (which may or may not be the same as the "secretly" used ones by the test
   machinery).
   
Since 2.2, step b) is no longer necessary, we can store alternative system
fonts in the source. 


> I think what Günter's main underlying point (please correct me if I'm
> wrong) is to make it clear that *LyX* (not the tests) should have a
> better framework for encouraging system fonts by default for XeTeX and
> LuaTeX.

This is a different point. With a new config value "automatic" for "use
non-TeX fonts" (second part of ticket #9744), also step a) would no longer
be required.

> But since LyX does not do that, my opinion is that it is a great idea
> for the tests to do the best job they can at testing the use of system
> fonts. 

Yes, as long as LyX cannot do that, we need the workaround.

However, "the best job they can" (for me) does not imply using a sans
serif font for all three:, serif, sans serif, and monospaced. 

I agree that I have a personal interest, as these replacements vitiate
one of the use cases in #8035 (while there are alternative serif fonts
that would work if #8035 were solved).

Günter

Re: beta release

[Richard Heck]

On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote:
> Le 09/01/2016 01:15, Scott Kostyshak a écrit :
>> Georg's patch still needs a final +1:
>> https://www.mail-archive.com/search?l=mid=n6have%24b5i%244%40ger.gmane.org
>>
>> JMarc did you have any other concerns with it? Does anyone else?
>
> Unfortunately I do not know much about this origin business. My
> comment was about the fact that hardcoding the origin at install time
> feel wrong and I proposed an alternate solution. For later of course.

I'm afraid I'm in the same boat. Enrico may be the only other person who
really understands it.

Richard

Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)

[Guenter Milde]

On 2016-01-09, Kornel Benko wrote:
> Am Samstag, 9. Januar 2016 um 17:51:06, schrieb Guenter Milde 
> 
>> On 2016-01-08, Scott Kostyshak wrote:
...

> for the tests to do the best job they can at testing the use of system
>> > fonts. 
...
>> However, "the best job they can" (for me) does not imply using a sans
>> serif font for all three:, serif, sans serif, and monospaced. 

> I wonder what makes you think that the test uses sans serif only? (Yes,
> there is one condition which does it that way, but other cases do not)

The linked discussion on the luatex list had a Hebrew example with "Free
Sans" for serif, sans and mono. As my trials with several serif fonts all
triggered the spurious error described in #8035 but Scott reported a
successfull compilation of our test, I assume that this is due to the
same font settings (hidden to the non-initiated).

Thanks to the recent addition of the test-samples directory, non-hackish
testing of Hebrew with system fonts can now be done with a dedicated
sample document requiring only sans serif fonts (and mentioning this
current limitation).

Günter

Re: Status on Mac with El Capitan

[Scott Kostyshak]

On Sat, Jan 09, 2016 at 02:27:46PM +0100, Stephan Witt wrote:
> Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes :
> > 
> > Le 08/01/2016 10:08, Stephan Witt a écrit :
> >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :
> >>> Yes, unless somone has a different brilliant idea.
> >> 
> >> Am I right that it makes explicit what is otherwise implicit? So it is 
> >> safe to commit?
> > 
> > Yes, I think so. The question is only maintainability. Guillaume complained 
> > that the is fragile because new code can forget to add this explicit lyx::.
> 
> Scott,
> 
> I’d like to commit the patch (attached again). Is this ok?

I do not understand it. I'm fine as long as another developer gives an
explicit +1.

Scott


signature.asc
Description: PGP signature

Please be explicit if giving a +1

[Scott Kostyshak]

Since we now require a +1 from another developer before a patch goes in,
I have seen some confusion because some reviewers have written something
like "looks OK" or "I have tested and nothing broke" and the author of
the patch is understandably not sure if what was written was a +1 or
not. If these statements were intended to be safe and to not give a +1
then good, I think they did their job and I see no problem with
continuing to use such phrases. They provide good feedback for the
daring LyX developer that does want to give a +1 so they still serve a
purpose.

But if you want to give a +1, either write "+1" or "please commit" to
make it clear that you support the author to push the patch for 2.2.0.

Scott


signature.asc
Description: PGP signature

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

[Enrico Forestieri]

On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote:
> Le 11/12/2015 22:47, Enrico Forestieri a écrit :
> >On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote:
[...]
> >>• Defect: They tend to accumulate and they are redundant because there
> >>   is only one additional '\n' in the LaTeX source. The problem is the
> >>   one can add one before another. Thus, two such consecutive chars
> >>   should be merged as a single one, like it is done for spaces in LyX.
> >
> >There were a lot of problems to be solved and this one was escaping me.
> >Thank you for pointing it out. I will try to address it when I will find
> >time (and motivation) to work again on LyX. Unfortunately, I will be
> >unavailable the next weeks.
> 
> Thanks.

The attached patch avoids the proliferation of parbreak seaparators.

-- 
Enrico
diff --git a/src/Text3.cpp b/src/Text3.cpp
index 9edda1b..ca6ec5b 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1097,6 +1097,8 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
 		cap::replaceSelection(cur);
 		pit_type pit = cur.pit();
 		Paragraph const & par = pars_[pit];
+		bool lastpar = (pit == pit_type(pars_.size() - 1));
+		Paragraph const & nextpar = lastpar ? par : pars_[pit + 1];
 		pit_type prev = pit;
 		if (pit > 0) {
 			if (!pars_[pit - 1].layout().isEnvironment())
@@ -1105,10 +1107,13 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
 prev = pit - 1;
 		}
 		if (prev < pit && cur.pos() == par.beginOfBody()
-		&& !par.isEnvSeparator(cur.pos())
+		&& !par.isEnvSeparator(par.size() ? par.size() - 1 : 0)
 		&& !par.layout().isCommand()
 		&& pars_[prev].layout() != par.layout()
-		&& pars_[prev].layout().isEnvironment()) {
+		&& pars_[prev].layout().isEnvironment()
+		&& (!nextpar.isEnvSeparator(nextpar.size() ? nextpar.size() - 1 : 0)
+			|| nextpar.layout().isCommand()
+			|| nextpar.layout().isEnvironment())) {
 			if (par.layout().isEnvironment()
 			&& pars_[prev].getDepth() == par.getDepth()) {
 docstring const layout = par.layout().name();
@@ -1124,6 +1129,8 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
 			Font const f(inherit_font, cur.current_font.language());
 			pars_[cur.pit() - 1].resetFonts(f);
 		} else {
+			if (par.isEnvSeparator(cur.pos()))
+cur.posForward();
 			breakParagraph(cur, cmd.argument() == "inverse");
 		}
 		cur.resetAnchor();

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

[Richard Heck]

On 01/09/2016 05:29 PM, Enrico Forestieri wrote:
> On Thu, Dec 17, 2015 at 06:57:23PM +, Guillaume Munch wrote:
>> I also have another bug to report (very subtle and better seen in
>> combination with the view source panel). There seems to be two cursor
>> positions before and after the separator, both being displayed before
>> the separator. One cannot access the second position with ← and →, but
>> it is possible to do so with ↑ and ↓, and in that case using ← is as if
>> it does nothing, but in the source we see that it goes from after the \n
>> character to before it. Also, this means that we never know whether we
>> must use delete or backspace to remove a separator. I think the
>> intension was to hide the "after" position entirely.
> The attached patch avoids the "after" position when moving with ↑ and ↓.

Also looks good to commit.

Richard

Re: beta release

[Scott Kostyshak]

On Sat, Jan 09, 2016 at 03:36:52PM -0500, Richard Heck wrote:
> On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote:
> > Le 09/01/2016 01:15, Scott Kostyshak a écrit :
> >> Georg's patch still needs a final +1:
> >> https://www.mail-archive.com/search?l=mid=n6have%24b5i%244%40ger.gmane.org
> >>
> >> JMarc did you have any other concerns with it? Does anyone else?
> >
> > Unfortunately I do not know much about this origin business. My
> > comment was about the fact that hardcoding the origin at install time
> > feel wrong and I proposed an alternate solution. For later of course.
> 
> I'm afraid I'm in the same boat. Enrico may be the only other person who
> really understands it.

Makes sense. I appreciate your hesitancy. I'm CC'ing Enrico.

Scott


signature.asc
Description: PGP signature

Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)

[Scott Kostyshak]

On Sat, Jan 09, 2016 at 09:23:43PM +, Guenter Milde wrote:
> On 2016-01-09, Kornel Benko wrote:
> > Am Samstag, 9. Januar 2016 um 17:51:06, schrieb Guenter Milde 
> > 
> >> On 2016-01-08, Scott Kostyshak wrote:
> ...
> 
> > for the tests to do the best job they can at testing the use of system
> >> > fonts. 
> ...
> >> However, "the best job they can" (for me) does not imply using a sans
> >> serif font for all three:, serif, sans serif, and monospaced. 
> 
> > I wonder what makes you think that the test uses sans serif only? (Yes,
> > there is one condition which does it that way, but other cases do not)
> 
> The linked discussion on the luatex list had a Hebrew example with "Free
> Sans" for serif, sans and mono. As my trials with several serif fonts all
> triggered the spurious error described in #8035 but Scott reported a
> successfull compilation of our test, I assume that this is due to the
> same font settings (hidden to the non-initiated).
> 
> Thanks to the recent addition of the test-samples directory, non-hackish
> testing of Hebrew with system fonts can now be done with a dedicated
> sample document requiring only sans serif fonts (and mentioning this
> current limitation).

Would you suggest testing Hebrew documents with FreeSerif for Roman,
FreeSans for sans, and FreeMono for typewriter? I think the reason why I
supported using FreeSans for all three was because I wanted to simplify
things as much as possible. In particular, I was worried about the case
where Freesans contains a glyph but FreeMono does not. I do not have a
preference though and using the other Free variants is indeed more
realistic, and I think this is what Kornel wanted to do before anyway.

Scott


signature.asc
Description: PGP signature

Re: why Babel with dvi3 (LuTeX)?

[Guenter Milde]

On 2016-01-09, Kornel Benko wrote:
> Am Samstag, 9. Januar 2016 um 15:07:32, schrieb Guenter Milde 
> 
>> On 2016-01-09, Kornel Benko wrote:

>> > After the last commit, this tests fail:
>> >1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed)
>> >1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed)
>> >1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed)

>> They work here. Can you establish the cause for failure and eventually add a
>> patter to unreliable?

> Manually it works. Compiling the changed file used by test I get

>   Missing character: There is no ☞ (U+261E) in font 
> "FreeSans:mode=node;script=l

> This was because of error in test-suite. In contrast to what I said
> that the font would be replaced only if set to default, it was replaced
> unconditionally. Works now. I will wait for your commit before
> committing the correction.

>> > and also
>> >579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 
>> > (Failed)
>> >580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF 
>> > (Failed)
>> >581 - 
>> > SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed)

>> This was a mistake in the pattern, I'll upload a fix soon.

Done (710f284f1/lyxgit)

Now it is your turn.

Thanks,
Günter

Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)

[Kornel Benko]

Am Samstag, 9. Januar 2016 um 17:51:06, schrieb Guenter Milde 

> On 2016-01-08, Scott Kostyshak wrote:
> 
> > [-- Type: text/plain, Encoding: quoted-printable --]
> 
> > On Fri, Jan 08, 2016 at 08:11:19PM +0100, Kornel Benko wrote:
> >> Am Freitag, 8. Januar 2016 um 12:21:44, schrieb Scott Kostyshak 
> >> 
> >> > On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote:
> 
> >> > > * FreeSans seems to provide the correct script-support info not to
> >> > >   trigger the false-positive error
> >> > >   http://www.lyx.org/trac/ticket/8035
> >> > >   
> >> > >   However, setting all of "mainfont", "sansfont", and "monofont"
> >> > >   to FreeSans seems "hackish" to me.
> 
> >> No it is not hackish IMHO. The test should show, that with a suitable
> >> font this file is compilable. It is a remnant from the times we had
> >> defined fonts for texF only. If the non-tex font is defined in the
> >> document, it will be used.
> 
> > I agree with Kornel that it is not hackish of the tests. 
> 
> I agree, that testing with system fonts is not bad. As long as this
> requires a hack (like changing fonts or the "useNonTeXfonts" setting
> "secretly" in a test script, this is not bad either.
> 
> However, it remains a hack and could/should be replaced if a better way of
> operating is available.
> 
> Currently, if I want to check a failure with .*systemF, I have to
> 
> a) change it to use non-TeX fonts,
> b) eventually set alternative system fonts
>(which may or may not be the same as the "secretly" used ones by the test
>machinery).
>
> Since 2.2, step b) is no longer necessary, we can store alternative system
> fonts in the source. 
> 
> 
> > I think what Günter's main underlying point (please correct me if I'm
> > wrong) is to make it clear that *LyX* (not the tests) should have a
> > better framework for encouraging system fonts by default for XeTeX and
> > LuaTeX.
> 
> This is a different point. With a new config value "automatic" for "use
> non-TeX fonts" (second part of ticket #9744), also step a) would no longer
> be required.
> 
> > But since LyX does not do that, my opinion is that it is a great idea
> > for the tests to do the best job they can at testing the use of system
> > fonts. 
> 
> Yes, as long as LyX cannot do that, we need the workaround.
> 
> However, "the best job they can" (for me) does not imply using a sans
> serif font for all three:, serif, sans serif, and monospaced. 

I wonder what makes you think that the test uses sans serif only?
(Yes, there is one condition which does it that way, but other cases do not)

> I agree that I have a personal interest, as these replacements vitiate
> one of the use cases in #8035 (while there are alternative serif fonts
> that would work if #8035 were solved).
> 
> Günter

Kornel


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

Re: Questions for Uwe?

[Guenter Milde]

On 2016-01-09, Scott Kostyshak wrote:

> I have gone through this thread and tried to make a summary of the questions
> and discussion for Uwe. Please add more questions if you have any or edit my
> misinterpretation of the question/comment.

> The following letters refer to the person that asked the question.

> G=Georg
> R=Richard
> S=Scott

> S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
> and 5.6.0beta1?

> S2. Can you make the installers from *only* the tar ball (and not use the
> git directory at all)? Note that if there is a technical reason why this is 
> difficult if you ask on the list I am guessing someone can help.

> S3. Richard has been committing updates to po files. Can you confirm that all
> translation updates we have received have been merged? Has anyone emailed 
> updates to you privately?

> R4. Do we also want to try releasing an installer built with mingw?
> (G response: IMO, we only need to release one installer. The mingw and MSVC
> builds behave exactly the same (modulo bugs). So the question is rather 
> whether
> we do trust MSVC or mingw, and who does the build: If it is Uwe, it will be
> MSVC, otherwise it will probably be mingw.

> G5. Not a question but a prerequisite IMHO: The 2.2.0 release should also 
> build
> the prerequisite from the sources Peter added, using exactly the same
> compiler as is used to build LyX.

> S6. Can you still reproduce these two tickets?
> http://www.lyx.org/trac/ticket/9892
> http://www.lyx.org/trac/ticket/9900
> If so, do you think they are beta blockers?
> That is part of the reason why I am curious about Qt 5.6.0beta1 (see question
> S1). Maybe it makes those issues go away somehow.

GM1: could we add a line
 \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
 to the user-preamble of doc/es/UserGuide.lyx?

 This would work around a bug in babel-spanish preventing
 compilation with non-TeX fonts without affecting the default
 pdflatex output.
 
GM2: may we define alternative "non-TeX fonts" in the manuals containing
 characters missing in the default LatinModern Unicode fonts?
 
 Again, this would help compilation with non-TeX fonts without affecting
 the default output.
  
Günter

Re: Questions for Uwe?

[Scott Kostyshak]

On Sat, Jan 09, 2016 at 11:58:16AM +0100, Peter Kümmel wrote:
> 
> 
> Am 09.01.2016 um 01:32 schrieb Scott Kostyshak:

> >S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
> >and 5.6.0beta1?
> 
> There will be no downloadable msvc2010 builds for 5.6. ATM only 5.5.1:
> 
> http://www.qt.io/download-open-source/#section-2

I see, good to know. I will remove this question then.

> >G5. Not a question but a prerequisite IMHO: The 2.2.0 release should also 
> >build
> >the prerequisite from the sources Peter added, using exactly the same
> >compiler as is used to build LyX.
> 
> If Uwe tries to build the installer with the mingw build from the build bot,
> and it makes no problems, then a mingw
> based installer isn't far away.

This is great news! Let's replace my S1 question with the following
question then:

S1 Can you build beta1 installers with both your original way and also
using the mingw build from Peter's build bot? From what I understand,
this involves downloading the zip from:
https://github.com/syntheticpp/LyX-bleeding-edge/archive/LyX-master-win32.zip

Scott


signature.asc
Description: PGP signature

Re: [patch] origin again

[Enrico Forestieri]

On Thu, Dec 31, 2015 at 09:13:02PM +0100, Georg Baum wrote:

> Sorry for opening a new thread, but gmane did already expire the old thread 
> in the nntp interface, and I do not keep lyx-devel mails.
> 
> The attached patch implements the third option I described in the starting 
> message of the original thread:
> 
> > - Do not change the paths in general if the files can be found using the
> > relative paths. Has the additional benefit that this is also the wanted
> > behaviour if I copy a whole directory of LyX files (including referenced
> > graphics) to a new location. Disadvantage would be that the machinery does
> > now depend on the presence of external files, and it is not guaranteed
> > that the file that is found is the correct one.

I am fine with this and you have a +1 from me. However, note that the origin
handling is currently broken. Indeed, allowing to save the document directory
in the preferences, after creating a new file and saving it, the path in the
origin tag is missing the trailing slash and thus it will not work.
This was working fine until not so long ago, hence it must have been broken
recently, most probably by the patches for dealing with symlinks.

-- 
Enrico

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

[Enrico Forestieri]

On Sat, Jan 09, 2016 at 05:31:37PM -0500, Richard Heck wrote:

> On 01/09/2016 05:24 PM, Enrico Forestieri wrote:
> > On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote:
> >> Le 11/12/2015 22:47, Enrico Forestieri a écrit :
> >>> On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote:
> > [...]
>  • Defect: They tend to accumulate and they are redundant because there
>    is only one additional '\n' in the LaTeX source. The problem is the
>    one can add one before another. Thus, two such consecutive chars
>    should be merged as a single one, like it is done for spaces in LyX.
> >>> There were a lot of problems to be solved and this one was escaping me.
> >>> Thank you for pointing it out. I will try to address it when I will find
> >>> time (and motivation) to work again on LyX. Unfortunately, I will be
> >>> unavailable the next weeks.
> >> Thanks.
> > The attached patch avoids the proliferation of parbreak seaparators.
> 
> Yes, this looks fine to me. Officially: +1.

Thanks. Committed at c8aaaff1.

-- 
Enrico

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

[Enrico Forestieri]

On Sat, Jan 09, 2016 at 05:32:17PM -0500, Richard Heck wrote:

> On 01/09/2016 05:29 PM, Enrico Forestieri wrote:
> > On Thu, Dec 17, 2015 at 06:57:23PM +, Guillaume Munch wrote:
> >> I also have another bug to report (very subtle and better seen in
> >> combination with the view source panel). There seems to be two cursor
> >> positions before and after the separator, both being displayed before
> >> the separator. One cannot access the second position with ← and →, but
> >> it is possible to do so with ↑ and ↓, and in that case using ← is as if
> >> it does nothing, but in the source we see that it goes from after the \n
> >> character to before it. Also, this means that we never know whether we
> >> must use delete or backspace to remove a separator. I think the
> >> intension was to hide the "after" position entirely.
> > The attached patch avoids the "after" position when moving with ↑ and ↓.
> 
> Also looks good to commit.

Thanks. Committed at bbb5a1a2.

-- 
Enrico

Re: [patch] origin again

[Enrico Forestieri]

On Sun, Jan 10, 2016 at 12:44:12AM +0100, Enrico Forestieri wrote:

> On Thu, Dec 31, 2015 at 09:13:02PM +0100, Georg Baum wrote:
> 
> > Sorry for opening a new thread, but gmane did already expire the old thread 
> > in the nntp interface, and I do not keep lyx-devel mails.
> > 
> > The attached patch implements the third option I described in the starting 
> > message of the original thread:
> > 
> > > - Do not change the paths in general if the files can be found using the
> > > relative paths. Has the additional benefit that this is also the wanted
> > > behaviour if I copy a whole directory of LyX files (including referenced
> > > graphics) to a new location. Disadvantage would be that the machinery does
> > > now depend on the presence of external files, and it is not guaranteed
> > > that the file that is found is the correct one.
> 
> I am fine with this and you have a +1 from me. However, note that the origin
> handling is currently broken. Indeed, allowing to save the document directory
> in the preferences, after creating a new file and saving it, the path in the
> origin tag is missing the trailing slash and thus it will not work.
> This was working fine until not so long ago, hence it must have been broken
> recently, most probably by the patches for dealing with symlinks.

The attached patch fixes the above issue.

BTW, your patch works very well :)

-- 
Enrico
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index fe47c05..8024d4a 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1015,11 +1015,11 @@ void BufferParams::writeFile(ostream & os, Buffer const 
* buf) const
// The top of the file is written by the buffer.
// Prints out the buffer info into the .lyx file given by file
 
-   // the document directory
-   // use realPath() instead of absFileName() for comparing
-   // so we can catch also eventually used symbolic parts of the path.
-   string filepath = buf->fileName().onlyPath().realPath();
-   string const sysdir = package().system_support().realPath();
+   // the document directory (must end with a path separator)
+   // realPath() is used to resolve symlinks, while addPath(..., "")
+   // ensures a trailing path separator.
+   string filepath = addPath(buf->fileName().onlyPath().realPath(), "");
+   string const sysdir = addPath(package().system_support().realPath(), 
"");
string const relpath =
to_utf8(makeRelPath(from_utf8(filepath), from_utf8(sysdir)));
if (!prefixIs(relpath, "../") && !FileName::isAbsolute(relpath))

Re: Index made by texindy: log available?

[Jürgen Spitzmüller]

Am Donnerstag, den 03.12.2015, 02:23 +0100 schrieb Jürgen Lange:
> log.idx is not very informative (No error report). So implementing
> this is  
> not useful.

It can be implemented with some effort, see
http://www.lyx.org/trac/ticket/2569

Jürgen

> 
> Regards