Re: [LyX/master] New layout tags for better counter handling

[Richard Heck]

On 10/27/2017 01:54 PM, Scott Kostyshak wrote:
>
>> Note that this commit would cause a lot of runs of layout2layout, since
>> the formats of the layout files themselves had not yet been updated.
> Perhaps this is what made it slow for me. So a 2 to 3 second delay
> compared to the previous commit is not surprising?

I've heard of that sort of thing. E.g., people upgrade to some new major
version and their documents open slowly. It turns out that layout2layout
can be quite slow. Just reading article.layout can require opening and
converting several files. If a number of modules are used, then it is
even more files.

Richard

Re: PATCH for 2.3, use frescobaldi as preferred editor for lilypond material

[Richard Heck]

On 10/27/2017 01:53 PM, Scott Kostyshak wrote:
> On Fri, Oct 27, 2017 at 03:23:52PM +, Richard Heck wrote:
>> On 10/27/2017 02:25 AM, Scott Kostyshak wrote:
>>> On Wed, Oct 25, 2017 at 05:31:35PM +, Scott Kostyshak wrote:
 On Sat, Oct 14, 2017 at 02:40:32AM +, Scott Kostyshak wrote:
> On Fri, Oct 13, 2017 at 06:34:46PM +, Richard Heck wrote:
>
>> It can certainly go to master. I don't see why we shouldn't do it for
>> 2.3.x myself, so I'd give it the necessary +1, but I guess I feel like
>> Scott should probably chime in on this.
> Thanks, yes, for feature patches I like to be involved.
>
> This feature is fine with me, so since Richard +1'd it, go ahead for
> 2.3.0. Thanks for the patch, Helge.
 Helge or Richard, please commit as soon as possible if you would like
 this in 2.3.0rc1.
>>> I committed to master at c4b4305f and to 2.3.x at c480b5bd. I'm still
>>> curious about thoughts on centralizing the list of text editors.
>> It'd be easy just to do it with a variable that held the list, as in the
>> attached. What might be better would be to run the check on text editors
>> only once, and then be able to use the results whenever. But that would
>> be more work.
> I agree. I had brought that up also and came to the same conclusion
> (nice but more work).
>
> I suggest you commit your current patch to master. 

Done.

> If you think it makes sense to put it in 2.3.x after rc1 so that backporting 
> other potential configure.py changes in the future is easier, then that's 
> fine with me.

I doubt it matters very much, but if I think of it.

rh

Lyx on Mac bug: document tabs disappearing in fullscreen mode

[Zhexuan Gong]

Dear Lyx developers,

I'm not sure if any of you are aware of this bug. I'm using the latest
2.2.3 Lyx on Mac. And whenever Lyx is in macOS' native full screen mode
(using the green button on the title bar, not the View->Full Screen), the
document tab row will disappear mysteriously whenever a new document is
created or the current tab is closed. This is annoying since one cannot
switch between tabs any more. The problem will persist even if one exit the
full screen mode. The only way to make the tab row reappear is to first
exit the full screen mode, then enter the full screen mode using View->Full
Screen, and then do View->Full Screen again (uncheck).

To me, this bug has to do with the fact that there are two full screen
modes. The native one by clicking the full screen icon at the title bar
will not hide the toolbars nor the tab bar, but the full screen mode via
the View menu will hide everything except the document itself. The bug
yields a messed-up situation where all the tool bars are showing, but the
document tab bar is hidden, which belongs to neither of the two full screen
modes.

P. S. I'm not talking about the Tab Bar under the View menu that is
introduced by macOS Sierra. I'm talking about the tabs enabled in
Preferences->Document Handling.

Can anyone look into this?

Thanks a lot!

Zhexuan

Re: Tars for 2.3.0rc1

[Uwe Stöhr]

El 28.10.2017 a las 02:18, Uwe Stöhr escribió:


I found it: the file

ReplaceValues.cmake

is missing in your tar.


the reason is a missing entry in a Makefile. I fixed this now in master:

http://www.lyx.org/trac/changeset/3d4358f1/lyxgit


regards Uwe

Re: Tars for 2.3.0rc1

[Uwe Stöhr]

El 28.10.2017 a las 02:14, Scott Kostyshak escribió:


But Kornel is not to blame here. There is simply a difference in the folder
development\cmake
between branch and your tar.


I found it: the file

ReplaceValues.cmake

is missing in your tar.

regards Uwe

Re: Tars for 2.3.0rc1

[Scott Kostyshak]

On Sat, Oct 28, 2017 at 12:09:52AM +, Uwe Stöhr wrote:
> El 28.10.2017 a las 02:07, Scott Kostyshak escribió:
> 
> > Kornel, do you have an idea for a fix?
> 
> But Kornel is not to blame here. There is simply a difference in the folder
> development\cmake
> between branch and your tar.

I certainly was not blaming Kornel. I was just asking him for help since
he is a CMake wizard. But if you think I can figure it out without much
CMake knowledge, I will take a look. I don't have time now though. I
will look at it as soon as I can.

Scott


signature.asc
Description: PGP signature

Re: Tars for 2.3.0rc1

[Uwe Stöhr]

El 28.10.2017 a las 02:07, Scott Kostyshak escribió:


Kornel, do you have an idea for a fix?


But Kornel is not to blame here. There is simply a difference in the folder
development\cmake
between branch and your tar.

regards Uwe

Re: Tars for 2.3.0rc1

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 11:54:36PM +, Uwe Stöhr wrote:
> El 27.10.2017 a las 20:33, Scott Kostyshak escribió:
> 
> > Here are the tars for 2.3.0rc1:...
> 
> Hi Scott,
> 
> I cannot compile from that TAR because ReplaceValues strikes back:
> 
>   Building Custom Rule D:/LyXGit/LyX23/development/cmake/doc/CMakeLists.txt
>   CMake does not need to re-run because
> D:/LyXGit/LyX23/compile-2015/doc/CMakeFiles/generate.stamp is up-to-date.
>   Generating Additional.lyx
> CUSTOMBUILD : CMake error : Error processing file:
> D:/LyXGit/LyX23/development/cmake/doc/ReplaceValues.cmake
> [D:\LyXGit\LyX23\compile-2015\doc\doc.vcxproj]
> 
> But I can compile current 2.3.x branch. So there must be a difference
> between current 2.3.x branch and your tarball. And indeed, if I copy the
> whole folder
> development\cmake
> from the 2.3.x branch to the folder where I extracted the tar, I can compile
> it successfully. Can you therefore please have a look what is the difference
> in this folder between branch and tar?

Kornel, do you have an idea for a fix?

Scott


signature.asc
Description: PGP signature

Re: Tars for 2.3.0rc1

[Uwe Stöhr]

El 27.10.2017 a las 20:33, Scott Kostyshak escribió:


Here are the tars for 2.3.0rc1:...


Hi Scott,

I cannot compile from that TAR because ReplaceValues strikes back:

  Building Custom Rule D:/LyXGit/LyX23/development/cmake/doc/CMakeLists.txt
  CMake does not need to re-run because 
D:/LyXGit/LyX23/compile-2015/doc/CMakeFiles/generate.stamp is up-to-date.

  Generating Additional.lyx
CUSTOMBUILD : CMake error : Error processing file: 
D:/LyXGit/LyX23/development/cmake/doc/ReplaceValues.cmake 
[D:\LyXGit\LyX23\compile-2015\doc\doc.vcxproj]


But I can compile current 2.3.x branch. So there must be a difference 
between current 2.3.x branch and your tarball. And indeed, if I copy the 
whole folder

development\cmake
from the 2.3.x branch to the folder where I extracted the tar, I can 
compile it successfully. Can you therefore please have a look what is 
the difference in this folder between branch and tar?


thanks and regards
Uwe

Re: [LyX/master] Fix remaining path

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 11:20:06PM +, Uwe Stöhr wrote:
> El 27.10.2017 a las 06:02, Scott Kostyshak escribió:
> 
> > I don't see the file for Japanese.
> 
> Oh, sorry. Yes the file was missing in Japanese. I added them now in master
> and will do it after RC1 was released also in 2.3.x if you agree.

Thanks, looks good. Yes, after RC1 go ahead.

Scott


signature.asc
Description: PGP signature

Go forward with 2.3.0rc1 despite potential data loss from changes to dashes?

[Scott Kostyshak]

Dear all,

Because of the dashes and ZWSP situation, we do not produce an
equivalent document in some cases (I'm still curious for a definition of
what an "equivalent" document specifically means). For more information,
see:

https://www.mail-archive.com/search?l=mid=osunpo%249f%241%40blaine.gmane.org

This issue could be interpreted as data loss, and in the past we have
had a rule of not releasing an rc if there is known data loss.

My current opinion is that we should make an exception and just go
forward with rc1 to get it out of the door. This way, we can get more
testing while we debate more about the best way to resolve this issue
after rc1.

Do you support going forward with rc1 despite this data loss issue? I
would need some explicit support before going forward, since we would be
making an exception to an important rule.

If instead you prefer to address the data loss issue before rc1 is
released, please let me know if you suppport delaying rc1 until we at
least provide a minimum fix for the issue.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: Update on the 2.3.0rc1 situation

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 07:30:37PM +, Guenter Milde wrote:
> Dear Scott,
> 
> thank you for the fast answer. Sorry to bother you again.

It is not a bother. I appreciate your persistence and all of the time
that you have spent on this issue.

> This is the minimum requirement for *reversion* (i.e. backward
> conversion). For (forward) *conversion*, the requirement is "to produce a
> document that is equivalent to the old version".
> 
> The current code satisfies the minimal requirement for reversion but it
> fails the requirement for conversion: some old documents are not equivalent
> to the old version after converting to 2.3!

I see now what you mean. Thanks for the clarification. In this case, I
suppose this could be interpreted as "data loss", which I believe in the
past has been a blocker for rc1. I'm going to start a new thread to
discuss whether we should hold up rc1. My opinion is that we should just
go forward with the rc1 pre-release as it is, but that we should
consider a patch after rc1. I'm not sure if others share my opinion
though so I will check and wait for feedback before going forward.

Also, what does it exactly mean that "the conversion routine is required
to produce a document that is equivalent to the old version". What does
it mean for a LyX document to be equivalent to another LyX document?

> >> I can propose a medium and a minimal patch:
> 
> >> The minimal patch just removes the ZWSP hack,
> >> the medium patch also sets the new setting based on content.
> 
> > Thanks for your new proposal. If the new proposal gets support after
> > rc1, I am fine to consider it, and as I said I could spend some time
> > helping with the testing.
> 
> > If other LyX developers are in favor, we can even wait a couple of days
> > to fix this before rc1. I will not push the tag yet (I will tag and tar
> > locally and send the resulting tars to our packagers). So if we decide
> > as a group that there is an important fix we need in rc1, then I can
> > retar and send new tars to the packagers and they can make new binaries.
> > For now, I'm planning to go forward with rc1 unless others speak up,
> > since the only other opinions that I interpret are that Enrico does not
> > think any patch is worth addressing this issue at this point, and that
> > Richard also looked and did not propose delaying rc1.
> 
> I see. Thank you for the explanations and offer to test.
> 
> Would it help to put the remaining issues in a new bug report (closing the
> all to verbose current one)?

I think that is a good idea, and will clean things up in case anyone
else would like to jump into this discussion and get caught up.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Fix remaining path

[Uwe Stöhr]

El 27.10.2017 a las 06:02, Scott Kostyshak escribió:


I don't see the file for Japanese.


Oh, sorry. Yes the file was missing in Japanese. I added them now in 
master and will do it after RC1 was released also in 2.3.x if you agree.


regards Uwe

Re: [LyX/master] Cmake export tests: Make test fail if there is some non-existant sub-file

[Kornel Benko]

Am Freitag, 27. Oktober 2017 um 19:31:50, schrieb Guenter Milde 

> On 2017-10-27, Kornel Benko wrote:
> 
> > [-- Type: text/plain, Encoding: 7bit --]
> 
> > Am Freitag, 27. Oktober 2017 um 13:52:36, schrieb Scott Kostyshak 
> > 
> >> On Fri, Oct 27, 2017 at 01:46:38PM +, Guenter Milde wrote:
> 
> >> > > So, remove the eu_UserGuide.lyx from export test or correct the paths 
> >> > > and add again LaTeX.png?
> >> > 
> >> > I propose to remove (ignore) the export test.
> 
> >> I'm fine with either way.
> 
> >> Scott
> 
> > I'd like to keep it as a testfile. For this it has to be without wrong
> > references.
> 
> In this case, feel free to fix the document, whatever suits best.
> 
> Günter

Done at 7e18756.

Kornel

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

Re: [LyX/master] Cmake export tests: Make test fail if there is some non-existant sub-file

[Guenter Milde]

On 2017-10-27, Kornel Benko wrote:

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

> Am Freitag, 27. Oktober 2017 um 13:52:36, schrieb Scott Kostyshak 
> 
>> On Fri, Oct 27, 2017 at 01:46:38PM +, Guenter Milde wrote:

>> > > So, remove the eu_UserGuide.lyx from export test or correct the paths 
>> > > and add again LaTeX.png?
>> > 
>> > I propose to remove (ignore) the export test.

>> I'm fine with either way.

>> Scott

> I'd like to keep it as a testfile. For this it has to be without wrong
> references.

In this case, feel free to fix the document, whatever suits best.

Günter

Re: Update on the 2.3.0rc1 situation

[Guenter Milde]

Dear Scott,

thank you for the fast answer. Sorry to bother you again.

On 2017-10-27, Scott Kostyshak wrote:
> On Fri, Oct 27, 2017 at 07:38:32AM +, Guenter Milde wrote:

...

>> > Indeed, our "Development" manual covers this:

>> >   While the conversion routine is required to produce a document that
>> >   is equivalent to the old version, the requirements of the reversion
>> >   are not that strict. If possible, try to produce a proper reversion,
>> >   using ERT if needed, but for some features this might be too
>> >   complicated. In this case, the minimum requirement of the reversion
>> >   routine is that it produces a valid document which can be read by an
>> >   older LyX. If absolutely needed, even data loss is allowed for the
>> >   reversion.

>> > The current code (without the patch) clearly already satisfies the
>> > "minimum requirement".

>> The current conversion routine does *not* produce a document that is
>> equivalent to the old version:

> The minimum requirement, as quoted above, is that a valid document is
> producecd that can be read by an older LyX. I interpret this to mean
> just that a .lyx file is produced that can be opened in older LyX
> without parser errors. In any case, equivalence is not the minimum
> requirement.

This is the minimum requirement for *reversion* (i.e. backward
conversion). For (forward) *conversion*, the requirement is "to produce a
document that is equivalent to the old version".

The current code satisfies the minimal requirement for reversion but it
fails the requirement for conversion: some old documents are not equivalent
to the old version after converting to 2.3!

...

>> I can propose a medium and a minimal patch:

>> The minimal patch just removes the ZWSP hack,
>> the medium patch also sets the new setting based on content.

> Thanks for your new proposal. If the new proposal gets support after
> rc1, I am fine to consider it, and as I said I could spend some time
> helping with the testing.

> If other LyX developers are in favor, we can even wait a couple of days
> to fix this before rc1. I will not push the tag yet (I will tag and tar
> locally and send the resulting tars to our packagers). So if we decide
> as a group that there is an important fix we need in rc1, then I can
> retar and send new tars to the packagers and they can make new binaries.
> For now, I'm planning to go forward with rc1 unless others speak up,
> since the only other opinions that I interpret are that Enrico does not
> think any patch is worth addressing this issue at this point, and that
> Richard also looked and did not propose delaying rc1.

I see. Thank you for the explanations and offer to test.

Would it help to put the remaining issues in a new bug report (closing the
all to verbose current one)?

Thanks again,

Günter
G

Re: [LyX/master] Cmake export tests: Make test fail if there is some non-existant sub-file

[Kornel Benko]

Am Freitag, 27. Oktober 2017 um 13:52:36, schrieb Scott Kostyshak 

> On Fri, Oct 27, 2017 at 01:46:38PM +, Guenter Milde wrote:
> 
> > > So, remove the eu_UserGuide.lyx from export test or correct the paths and 
> > > add again LaTeX.png?
> > 
> > I propose to remove (ignore) the export test.
> 
> I'm fine with either way.
> 
> Scott

I'd like to keep it as a testfile. For this it has to be without wrong 
references.

Kornel

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

Re: Freeze 2.3.x on Wednesday for rc1?

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 06:35:04PM +, Scott Kostyshak wrote:
> On Sun, Oct 22, 2017 at 06:08:03PM +, Scott Kostyshak wrote:
> > Dear all,
> > 
> > I would like to propose to freeze the 2.3.x branch at 23:59 UTC on
> > Wednesday, for releasing rc1. On Thursday I would do some final commits,
> > tag and tar for packagers, and if everything goes well with building the
> > binaries, we would release rc1 accordingly. Packagers, please let me
> > know if that plan does not work with your schedules.
> 
> I've tagged and tarred locally, and sent the tars to our packagers. If
> there is no issue while building from the tar, and if no rc1-blocker is
> proposed on the list, I will proceed with the release accordingly and
> push the tag after I receive binaries back.

Hi Liviu,

Is everything set for you to update the PPA to rc1 when we are ready to
proceed?

Scott


signature.asc
Description: PGP signature

Re: Freeze 2.3.x on Wednesday for rc1?

[Scott Kostyshak]

On Sun, Oct 22, 2017 at 06:08:03PM +, Scott Kostyshak wrote:
> Dear all,
> 
> I would like to propose to freeze the 2.3.x branch at 23:59 UTC on
> Wednesday, for releasing rc1. On Thursday I would do some final commits,
> tag and tar for packagers, and if everything goes well with building the
> binaries, we would release rc1 accordingly. Packagers, please let me
> know if that plan does not work with your schedules.

I've tagged and tarred locally, and sent the tars to our packagers. If
there is no issue while building from the tar, and if no rc1-blocker is
proposed on the list, I will proceed with the release accordingly and
push the tag after I receive binaries back.

Please do not commit anything to the 2.3.x branch.

Thanks for all of your help,

Scott


signature.asc
Description: PGP signature

Re: Initial view of document (master)

[Jean-Marc Lasgouttes]

Le 23/10/2017 à 22:26, Pavel Sanda a écrit :

And I have reproducible crash:
1. start new document
2. write "ambititious ", spellcheck correctly underlies text.
3. try to fix spelling via context menu, choose "ambitious"
4. kaboom


Here is a patch, that raises as many question as is solves. The issue is 
that lyxreplace uses Buffer::update, which does an update in the middle 
of a dispatch operation (it is necessary to look at the full backtrace 
to see what happens). This is of course terribly dangerous.


The patch does the right thing by using Cursor::message instead (so that 
the message is set at the end), but I am sure that there are other 
places where this may happen. I'd be grateful for ideas that would make 
buffer::message and BufferView::message safer. It might be enough to 
just delay the setting of the message in GuiView.


JMarc

PS: I will be in vacation for the next week, so don't expect more than 
replying to some mail during this time.
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 4e2428d7d7..c6c0cf17f7 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -82,6 +82,7 @@
 #include "support/lassert.h"
 #include "support/lstrings.h"
 #include "support/Package.h"
+#include "support/RefChanger.h"
 #include "support/types.h"
 
 #include 
@@ -2763,6 +2764,7 @@ void BufferView::updatePosCache()
 	// this is the "nodraw" drawing stage: only set the positions of the
 	// insets in metrics cache.
 	frontend::NullPainter np;
+	Changer chg = make_change(d->update_strategy_, FullScreenUpdate);
 	draw(np, false);
 }
 
diff --git a/src/Cursor.h b/src/Cursor.h
index 6c5e5e6783..955c702655 100644
--- a/src/Cursor.h
+++ b/src/Cursor.h
@@ -274,9 +274,9 @@ public:
 	bool getStatus(FuncRequest const & cmd, FuncStatus & flag) const;
 	/// dispatch from innermost inset upwards
 	void dispatch(FuncRequest const & cmd);
-	/// display a message
+	/// set a message to display after getStatus/dispatch
 	void message(docstring const & msg) const;
-	/// display an error message
+	/// set an error  message to display after getStatus/dispatch
 	void errorMessage(docstring const & msg) const;
 	/// get the resut of the last dispatch
 	DispatchResult const & result() const;
diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
index 4b8da77ac0..b5b3b7d921 100644
--- a/src/lyxfind.cpp
+++ b/src/lyxfind.cpp
@@ -391,19 +391,19 @@ bool lyxreplace(BufferView * bv,
 			replace_count = rv.second;
 		}
 
-		Buffer const & buf = bv->buffer();
+		Cursor & cur = bv->cursor();
 		if (!update) {
 			// emit message signal.
-			buf.message(_("String not found."));
+			cur.message(_("String not found."));
 		} else {
 			if (replace_count == 0) {
-buf.message(_("String found."));
+cur.message(_("String found."));
 			} else if (replace_count == 1) {
-buf.message(_("String has been replaced."));
+cur.message(_("String has been replaced."));
 			} else {
 docstring const str =
 	bformat(_("%1$d strings have been replaced."), replace_count);
-buf.message(str);
+cur.message(str);
 			}
 		}
 	} else if (findnext) {
@@ -412,7 +412,7 @@ bool lyxreplace(BufferView * bv,
 		if (findOne(bv, search, casesensitive, matchword, forward, true, findnext))
 			update = true;
 		else
-			bv->message(_("String not found."));
+			bv->cursor().message(_("String not found."));
 	}
 	return update;
 }

Re: Update on the 2.3.0rc1 situation

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 07:38:32AM +, Guenter Milde wrote:

> Actually, the patch deals with both, forward conversion and backward
> conversion. In tend to summarize both conversions under the tag "backwards
> compatibility".

I see, thanks for the correction.

> > Indeed, our "Development" manual covers this:
> 
> >   While the conversion routine is required to produce a document that
> >   is equivalent to the old version, the requirements of the reversion
> >   are not that strict. If possible, try to produce a proper reversion,
> >   using ERT if needed, but for some features this might be too
> >   complicated. In this case, the minimum requirement of the reversion
> >   routine is that it produces a valid document which can be read by an
> >   older LyX. If absolutely needed, even data loss is allowed for the
> >   reversion.
> 
> > The current code (without the patch) clearly already satisfies the
> > "minimum requirement".
> 
> I don't agree:
> 
> The current conversion routine does *not* produce a document that is
> equivalent to the old version:

The minimum requirement, as quoted above, is that a valid document is
producecd that can be read by an older LyX. I interpret this to mean
just that a .lyx file is produced that can be opened in older LyX
without parser errors. In any case, equivalence is not the minimum
requirement.

>   * If you used literal em- and en-dashes in pre-2.2 documents,
> you must manually unselect
> "Document->Settings->Fonts->Output em- and en-dash as ligatures"
> to ensure unchanged behaviour.
> 
> 
> OTOH, the backwards conversion hack for 2.2 adding ZWSP
> 
> * needs to be reverted on forward conversion,
> * prevents proper back-conversion to 2.1 and older,
> * makes documents uncompilable with LyX 2.0 or earlier
> 
> I replaced the ZWSP with preamble code, but we could also just remove it
> (as ERT was voted against and "the requirements of the reversion are not
> that strict"). 
> This would make the patch simpler and less error prone. 
> 
> > All this to say: I don't think the patch is too
> > important for 2.3.0 and in my opinion I'm fine if we do not put it in.
> 
> Literal dashes may be less common than "ligature dashes" in pre-2.2
> documents, however 
> * the UserGuide documents Insert>Symbols als method to insert dashes since
>   several LyX versions,
> * there is evidence in mailing list threads that users were inserting
>   literal dashes via system keyboard shortcuts years ago.
> 
> The problem here is, that we cannot know for sure how large the number of
> affected users is: the changes in 2.2 did not affect them and they will only
> speak up once the new damage is done.
> 
> 
> I can propose a medium and a minimal patch:
> 
> The minimal patch just removes the ZWSP hack,
> the medium patch also sets the new setting based on content.

Thanks for your new proposal. If the new proposal gets support after
rc1, I am fine to consider it, and as I said I could spend some time
helping with the testing.

If other LyX developers are in favor, we can even wait a couple of days
to fix this before rc1. I will not push the tag yet (I will tag and tar
locally and send the resulting tars to our packagers). So if we decide
as a group that there is an important fix we need in rc1, then I can
retar and send new tars to the packagers and they can make new binaries.
For now, I'm planning to go forward with rc1 unless others speak up,
since the only other opinions that I interpret are that Enrico does not
think any patch is worth addressing this issue at this point, and that
Richard also looked and did not propose delaying rc1.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] New layout tags for better counter handling

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 03:48:32PM +, Richard Heck wrote:
> On 10/27/2017 03:24 AM, Jürgen Spitzmüller wrote:
> > Am Freitag, den 27.10.2017, 02:35 -0400 schrieb Scott Kostyshak:
> >> On Fri, Oct 14, 2016 at 06:10:22PM +, Juergen Spitzmueller wrote:
> >>> commit 0eb651a2cf6c8c4d39e461748292ffe4e69f2386
> >>> Author: Juergen Spitzmueller 
> >>> Date:   Fri Oct 14 20:08:12 2016 +0200
> >>>
> >>> New layout tags for better counter handling
> >>> 
> >>> * ResumeCounter: allow to resume an (enumerate) counter
> >>> * StepMasterCounter: allow to increase a master counter
> >> LyX 2.3.x is opening some files slower than older LyX versions for
> >> me.
> >> After this commit, the Embedded Objects manual opens about 2 or 3
> >> seconds slower for me than before this commit, on average.
> > I fail to see how this is caused by this patch, though. Do these files
> > have resuming counters?
> 
> I looked over the commit and also find it hard to see how it could be at
> fault. Since the changes to the modules themselves were only committed
> in the next two commits, the code committed here should have had
> essentially no effect. The only new code that actually gets used is:
> 
> --- a/src/Buffer.cpp
> +++ b/src/Buffer.cpp
> @@ -4673,7 +4673,7 @@ static bool needEnumCounterReset(ParIterator const
> & it)
>     --prev_it.top().pit();
>     Paragraph const & prev_par = *prev_it;
>     if (prev_par.getDepth() <= cur_depth)
> -   return  prev_par.layout().labeltype !=
> LABEL_ENUMERATE;
> +   return prev_par.layout().name() !=
> par.layout().name();
>     }
>     // start of nested inset: reset
>     return true;
> 
> But par.layout().name() is not expensive. So I think something else must
> be happening.

OK, thanks for taking a look Jürgen and Richard.

> Note that this commit would cause a lot of runs of layout2layout, since
> the formats of the layout files themselves had not yet been updated.

Perhaps this is what made it slow for me. So a 2 to 3 second delay
compared to the previous commit is not surprising?

Scott


signature.asc
Description: PGP signature

Re: [LyX/2.3.x] Make math options loading automatic, see ticket 10661

[Scott Kostyshak]

On Mon, Oct 23, 2017 at 07:24:05AM +, jpc wrote:
> commit 95f60915a73219e1fcf549b292b17f5307f94078
> Author: jpc 
> Date:   Mon Oct 23 09:18:56 2017 +0200
> 
>   Make math options loading automatic, see ticket 10661
> 
>  lib/doc/LFUNs.lyx  |   12 ++--

This file is automatically generated. I'm about to push a commit that
will thus revert your changes (since the command I run before release
regenerates this file). We can look into fixing the root source after
rc1, but for now I checked that LFUNs.lyx compiled and I don't want to
look into changing the root source now.

Scott


signature.asc
Description: PGP signature

Re: PATCH for 2.3, use frescobaldi as preferred editor for lilypond material

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 03:23:52PM +, Richard Heck wrote:
> On 10/27/2017 02:25 AM, Scott Kostyshak wrote:
> > On Wed, Oct 25, 2017 at 05:31:35PM +, Scott Kostyshak wrote:
> >> On Sat, Oct 14, 2017 at 02:40:32AM +, Scott Kostyshak wrote:
> >>> On Fri, Oct 13, 2017 at 06:34:46PM +, Richard Heck wrote:
> >>>
>  It can certainly go to master. I don't see why we shouldn't do it for
>  2.3.x myself, so I'd give it the necessary +1, but I guess I feel like
>  Scott should probably chime in on this.
> >>> Thanks, yes, for feature patches I like to be involved.
> >>>
> >>> This feature is fine with me, so since Richard +1'd it, go ahead for
> >>> 2.3.0. Thanks for the patch, Helge.
> >> Helge or Richard, please commit as soon as possible if you would like
> >> this in 2.3.0rc1.
> > I committed to master at c4b4305f and to 2.3.x at c480b5bd. I'm still
> > curious about thoughts on centralizing the list of text editors.
> 
> It'd be easy just to do it with a variable that held the list, as in the
> attached. What might be better would be to run the check on text editors
> only once, and then be able to use the results whenever. But that would
> be more work.

I agree. I had brought that up also and came to the same conclusion
(nice but more work).

I suggest you commit your current patch to master. If you think it makes
sense to put it in 2.3.x after rc1 so that backporting other potential
configure.py changes in the future is easier, then that's fine with me.

Thanks for taking a look,

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Cmake export tests: Make test fail if there is some non-existant sub-file

[Scott Kostyshak]

On Fri, Oct 27, 2017 at 01:46:38PM +, Guenter Milde wrote:

> > So, remove the eu_UserGuide.lyx from export test or correct the paths and 
> > add again LaTeX.png?
> 
> I propose to remove (ignore) the export test.

I'm fine with either way.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] New layout tags for better counter handling

[Richard Heck]

On 10/27/2017 03:24 AM, Jürgen Spitzmüller wrote:
> Am Freitag, den 27.10.2017, 02:35 -0400 schrieb Scott Kostyshak:
>> On Fri, Oct 14, 2016 at 06:10:22PM +, Juergen Spitzmueller wrote:
>>> commit 0eb651a2cf6c8c4d39e461748292ffe4e69f2386
>>> Author: Juergen Spitzmueller 
>>> Date:   Fri Oct 14 20:08:12 2016 +0200
>>>
>>> New layout tags for better counter handling
>>> 
>>> * ResumeCounter: allow to resume an (enumerate) counter
>>> * StepMasterCounter: allow to increase a master counter
>> LyX 2.3.x is opening some files slower than older LyX versions for
>> me.
>> After this commit, the Embedded Objects manual opens about 2 or 3
>> seconds slower for me than before this commit, on average.
> I fail to see how this is caused by this patch, though. Do these files
> have resuming counters?

I looked over the commit and also find it hard to see how it could be at
fault. Since the changes to the modules themselves were only committed
in the next two commits, the code committed here should have had
essentially no effect. The only new code that actually gets used is:

--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -4673,7 +4673,7 @@ static bool needEnumCounterReset(ParIterator const
& it)
    --prev_it.top().pit();
    Paragraph const & prev_par = *prev_it;
    if (prev_par.getDepth() <= cur_depth)
-   return  prev_par.layout().labeltype !=
LABEL_ENUMERATE;
+   return prev_par.layout().name() !=
par.layout().name();
    }
    // start of nested inset: reset
    return true;

But par.layout().name() is not expensive. So I think something else must
be happening.

Note that this commit would cause a lot of runs of layout2layout, since
the formats of the layout files themselves had not yet been updated.

Richard



signature.asc
Description: OpenPGP digital signature

Re: PATCH for 2.3, use frescobaldi as preferred editor for lilypond material

[Richard Heck]

On 10/27/2017 02:25 AM, Scott Kostyshak wrote:
> On Wed, Oct 25, 2017 at 05:31:35PM +, Scott Kostyshak wrote:
>> On Sat, Oct 14, 2017 at 02:40:32AM +, Scott Kostyshak wrote:
>>> On Fri, Oct 13, 2017 at 06:34:46PM +, Richard Heck wrote:
>>>
 It can certainly go to master. I don't see why we shouldn't do it for
 2.3.x myself, so I'd give it the necessary +1, but I guess I feel like
 Scott should probably chime in on this.
>>> Thanks, yes, for feature patches I like to be involved.
>>>
>>> This feature is fine with me, so since Richard +1'd it, go ahead for
>>> 2.3.0. Thanks for the patch, Helge.
>> Helge or Richard, please commit as soon as possible if you would like
>> this in 2.3.0rc1.
> I committed to master at c4b4305f and to 2.3.x at c480b5bd. I'm still
> curious about thoughts on centralizing the list of text editors.

It'd be easy just to do it with a variable that held the list, as in the
attached. What might be better would be to run the check on text editors
only once, and then be able to use the results whenever. But that would
be more work.

Richard

diff --git a/lib/configure.py b/lib/configure.py
index c55580e..41960a2 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -592,6 +592,10 @@ def checkModule(module):
   return False
 
 
+texteditors = ['xemacs', 'gvim', 'kedit', 'kwrite', 'kate', 
+   'nedit', 'gedit', 'geany', 'leafpad', 'mousepad', 
+   'xed', 'notepad', 'WinEdt', 'WinShell', 'PSPad']
+
 def checkFormatEntries(dtl_tools):
 ''' Check all formats (\Format entries) '''
 checkViewerEditor('a Tgif viewer and editor', ['tgif'],
@@ -636,9 +640,7 @@ def checkFormatEntries(dtl_tools):
 ['gimp-remote', 'gimp'], rc_entry = [imageformats])
 addToRC(imageformats % ((iv, ie)*10))
 #
-checkViewerEditor('a text editor',
-['xemacs', 'gvim', 'kedit', 'kwrite', 'kate',
- 'nedit', 'gedit', 'geany', 'leafpad', 'mousepad', 'xed', 'notepad'],
+checkViewerEditor('a text editor', texteditors,
 rc_entry = [r'''\Format asciichess asc"Plain text (chess output)"  
"" ""   "%%"""  ""
 \Format docbooksgmlDocBookB  """%%"
"document,menu=export"  ""
 \Format docbook-xml xml   "DocBook (XML)" "" """%%"
"document,menu=export"  "application/docbook+xml"
@@ -666,8 +668,7 @@ def checkFormatEntries(dtl_tools):
 \Format beamer.info pdf.info   "Info (Beamer)" "" ""   "%%"
"document,menu=export"  ""''' ])
#Lilypond files have special editors, but fall back to plain text editors
 checkViewerEditor('a lilypond editor',
-['frescobaldi', 'xemacs', 'gvim', 'kedit', 'kwrite', 'kate',
- 'nedit', 'gedit', 'geany', 'leafpad', 'mousepad', 'xed', 'notepad'],
+['frescobaldi'] + texteditors,
 rc_entry = [r'''\Format lilypond   ly "LilyPond music""" 
"""%%""vector""text/x-lilypond"''' ])
#Spreadsheets using ssconvert from gnumeric
 checkViewer('gnumeric spreadsheet software', ['gnumeric'],
@@ -682,10 +683,8 @@ def checkFormatEntries(dtl_tools):
  #
 checkEditor('a BibTeX editor', ['jabref', 'JabRef',
 'pybliographic', 'bibdesk', 'gbib', 'kbib',
-'kbibtex', 'sixpack', 'bibedit', 'tkbibtex'
-'xemacs', 'gvim', 'kedit', 'kwrite', 'kate',
-'jedit', 'TeXnicCenter', 'WinEdt', 'WinShell', 'PSPad',
-'nedit', 'gedit', 'notepad', 'geany', 'leafpad', 'mousepad'],
+'kbibtex', 'sixpack', 'bibedit', 'tkbibtex', 'TeXnicCenter'] +
+texteditors,
 rc_entry = [r'''\Format bibtex bib"BibTeX" "" ""   "%%"
""  "text/x-bibtex"''' ])
 #
 #checkProg('a Postscript interpreter', ['gs'],


signature.asc
Description: OpenPGP digital signature

Re: Initial view of document (master)

[Jean-Marc Lasgouttes]

Le 27/10/2017 à 15:14, Kornel Benko a écrit :

BTW, I get the same crash also with QT4.
Every time the word to correct is 2 chars longer as the wrong spelled.
For instance using 'tesest' and correct to 'test'. I used Hunspell,
but using Enchant or Aspell made no difference.


2 characters, of course ! I was typing "ambititous" instead.

I see it now.

JMarc

Re: [LyX/master] Cmake export tests: Make test fail if there is some non-existant sub-file

[Guenter Milde]

On 2017-10-27, Kornel Benko wrote:
> Am Donnerstag, 26. Oktober 2017 um 17:04:41, schrieb Scott Kostyshak 
> 
>> On Thu, Oct 26, 2017 at 08:44:34PM +, Kornel Benko wrote:

>> > > > Thanks, Kornel. Why not put the string inside "diestack" instead of
>> > > > separate print?
>> > > 
>> > > I did it at first, but the string did not appear in the output. Will 
>> > > investigate why.
>> > > 
>> > > > Scott
>> > > 
>> > 
>> > Hm, must have been blinded.

>> Thanks for checking it out.

>> Scott

> The new export test shows *many* wrong paths in attic/eu_UserGuide_pdf2.
> Most of them can be corrected using extension 'svgz' instead of 'png'.

> Only LaTeX.png is totally missing. (But still exists in lyx2.1).

> So, remove the eu_UserGuide.lyx from export test or correct the paths and add 
> again LaTeX.png?

I propose to remove (ignore) the export test.

Re: Initial view of document (master)

[Kornel Benko]

Am Freitag, 27. Oktober 2017 um 14:37:08, schrieb Kornel Benko 
> > > I can reproduce with continuous spellcheck enabled. Qt5.
> > > 
> > > It crashes on LASSERT(LASSERT(end > start && end <= size() + 1, return 
> > > false);
> > >   at src/Paragraph.cpp:612
> > 
> > I still can't reproduce (with qt5). Can I have a backtrace? (I doubt 
> > that it will help, to be frank).
> > 
> > JMarc
> 

BTW, I get the same crash also with QT4.
Every time the word to correct is 2 chars longer as the wrong spelled.
For instance using 'tesest' and correct to 'test'. I used Hunspell,
but using Enchant or Aspell made no difference.

Kornel

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

Re: Initial view of document (master)

[Kornel Benko]

Am Freitag, 27. Oktober 2017 um 14:07:35, schrieb Jean-Marc Lasgouttes 

> Le 25/10/2017 à 20:35, Kornel Benko a écrit :
> > Am Dienstag, 24. Oktober 2017 um 19:51:41, schrieb Jean-Marc Lasgouttes 
> > 
> >> Le 23/10/2017 à 22:26, Pavel Sanda a écrit :
> >>> And I have reproducible crash:
> >>> 1. start new document
> >>> 2. write "ambititious ", spellcheck correctly underlies text.
> >>> 3. try to fix spelling via context menu, choose "ambitious"
> >>> 4. kaboom
> >>
> >> I can't reproduce. Qt4 or Qt5?
> > 
> > I can reproduce with continuous spellcheck enabled. Qt5.
> > 
> > It crashes on LASSERT(LASSERT(end > start && end <= size() + 1, return 
> > false);
> >   at src/Paragraph.cpp:612
> 
> I still can't reproduce (with qt5). Can I have a backtrace? (I doubt 
> that it will help, to be frank).
> 
> JMarc

Here it comes:
Assertion triggered in void lyx::doAssertWithCallstack(bool) by failing check 
"false" in file /usr2/src/lyx/lyx-git/src/support/lassert.cpp:44
 /home/kornel/newfile1.lyx.emergency

Program received signal SIGABRT, Aborted.
0x75295c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: Adresár alebo súbor neexistuje.
(gdb) bt
#0  0x75295c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x75299028 in __GI_abort () at abort.c:89
#2  0x00d9ff9c in lyx::lyx_exit (exit_code=1) at 
/usr2/src/lyx/lyx-git/src/LyX.cpp:273
#3  0x00e96d81 in boost::assertion_failed (expr=0x19927ae "false", 
function=0x1992940  
"void lyx::doAssertWithCallstack(bool)", 
file=0x1992780 "/usr2/src/lyx/lyx-git/src/support/lassert.cpp", line=44) at 
/usr2/src/lyx/lyx-git/src/boost.cpp:47
#4  0x013dee0d in lyx::doAssertWithCallstack (value=false) at 
/usr2/src/lyx/lyx-git/src/support/lassert.cpp:44
#5  0x013deee9 in lyx::doAssert (expr=0x1460538 "end > start && end <= 
size() + 1", file=0x14604f0 "/usr2/src/lyx/lyx-git/src/Paragraph.cpp", 
line=612) at /usr2/src/lyx/lyx-git/src/support/lassert.cpp:53
#6  0x00dd950e in lyx::Paragraph::isChanged (this=0x2430550, start=0, 
end=11) at /usr2/src/lyx/lyx-git/src/Paragraph.cpp:612
#7  0x00dfde42 in lyx::RowPainter::paintChangeBar (this=0x7fff5320) 
at /usr2/src/lyx/lyx-git/src/RowPainter.cpp:259
#8  0x00e5d8fd in lyx::TextMetrics::drawParagraph (this=0x21552c8, 
pi=..., pit=0, x=0, y=49) at /usr2/src/lyx/lyx-git/src/TextMetrics.cpp:1948
#9  0x00e5cd76 in lyx::TextMetrics::draw (this=0x21552c8, pi=..., x=0, 
y=49) at /usr2/src/lyx/lyx-git/src/TextMetrics.cpp:1806
#10 0x00c8e4e8 in lyx::BufferView::draw (this=0x26d68e0, pain=..., 
paint_caret=true) at /usr2/src/lyx/lyx-git/src/BufferView.cpp:3125
#11 0x01147238 in lyx::frontend::GuiWorkArea::paintEvent 
(this=0x26f4450, ev=0x7fff5d70) at 
/usr2/src/lyx/lyx-git/src/frontends/qt4/GuiWorkArea.cpp:1240
#12 0x76ceef87 in QWidget::event(QEvent*) () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#13 0x76dcf58e in QFrame::event(QEvent*) () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#14 0x7634d181 in 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () 
from /usr/BUILD/BuildQtRoot/lib/libQt5Core.so.5
#15 0x76cab295 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#16 0x76cb2210 in QApplication::notify(QObject*, QEvent*) () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#17 0x010e2a5d in lyx::frontend::GuiApplication::notify 
(this=0x1f54530, receiver=0x2521bb0, event=0x7fff5d70) at 
/usr2/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.cpp:2703
#18 0x7634d2b5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /usr/BUILD/BuildQtRoot/lib/libQt5Core.so.5
#19 0x76ce7dba in QWidgetPrivate::sendPaintEvent(QRegion const&) () 
from /usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#20 0x76ce83aa in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#21 0x76cb9d91 in ?? () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#22 0x76cbafe9 in ?? () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#23 0x76cda0df in QWidgetPrivate::syncBackingStore() () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#24 0x76ceebcd in QWidget::event(QEvent*) () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#25 0x76de4ecb in QMainWindow::event(QEvent*) () from 
/usr/BUILD/BuildQtRoot/lib/libQt5Widgets.so.5
#26 0x011196b9 in lyx::frontend::GuiView::event (this=0x28a3c60, 
e=0x7fff67d0) at /usr2/src/lyx/lyx-git/src/frontends/qt4/GuiView.cpp:1361
#27 0x76cab2bc in 

Re: Initial view of document (master)

[Jean-Marc Lasgouttes]

Le 25/10/2017 à 20:35, Kornel Benko a écrit :

Am Dienstag, 24. Oktober 2017 um 19:51:41, schrieb Jean-Marc Lasgouttes 


Le 23/10/2017 à 22:26, Pavel Sanda a écrit :

And I have reproducible crash:
1. start new document
2. write "ambititious ", spellcheck correctly underlies text.
3. try to fix spelling via context menu, choose "ambitious"
4. kaboom


I can't reproduce. Qt4 or Qt5?


I can reproduce with continuous spellcheck enabled. Qt5.

It crashes on LASSERT(LASSERT(end > start && end <= size() + 1, return false);
  at src/Paragraph.cpp:612


I still can't reproduce (with qt5). Can I have a backtrace? (I doubt 
that it will help, to be frank).


JMarc

Re: [LyX/master] Cmake export tests: Make test fail if there is some non-existant sub-file

[Kornel Benko]

Am Donnerstag, 26. Oktober 2017 um 17:04:41, schrieb Scott Kostyshak 

> On Thu, Oct 26, 2017 at 08:44:34PM +, Kornel Benko wrote:
> 
> > > > Thanks, Kornel. Why not put the string inside "diestack" instead of
> > > > separate print?
> > > 
> > > I did it at first, but the string did not appear in the output. Will 
> > > investigate why.
> > > 
> > > > Scott
> > > 
> > 
> > Hm, must have been blinded.
> 
> Thanks for checking it out.
> 
> Scott

The new export test shows *many* wrong paths in attic/eu_UserGuide_pdf2.
Most of them can be corrected using extension 'svgz' instead of 'png'.

Only LaTeX.png is totally missing. (But still exists in lyx2.1).

So, remove the eu_UserGuide.lyx from export test or correct the paths and add 
again LaTeX.png?

Kornel

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

Re: [PATCH] to avoid crash in misspelled marker painting while deleting table rows fast

[Jean-Marc Lasgouttes]

Le 13/10/2017 à 07:24, Stephan Witt a écrit :

A question: is the 'quickly' important to get the crash? From what I see, 
Cursor::newWord() is not updated to the changes in the document structure. Why 
does this happen?


Sorry for the delay. I tried to reproduce and cannot anymore ATM. I had the 
impression 'quickly‘ was important to get the crash. It didn’t happen on the 
first or second deletion.

I don’t understand your statement regarding the change in document structure 
and the following question.


Sorry, I failed to answer this. My remark is that you have to check 
whether newword does point to a correct text and I thought it was 
because sometimes it is not pointing to what it should. I wonder whether 
this is related to the places where these things are computed.


JMarc

Re: Update on the 2.3.0rc1 situation

[Guenter Milde]

Dear Scott,

On 2017-10-25, Scott Kostyshak wrote:
> On Mon, Oct 23, 2017 at 08:44:07AM +, Enrico Forestieri wrote:
>> On Sun, Oct 22, 2017 at 09:36:56PM -0400, Richard Heck wrote:
>> > On 10/22/2017 06:19 PM, Scott Kostyshak wrote:
>> > > On Sat, Oct 14, 2017 at 06:37:06AM +, Jürgen Spitzmüller wrote:
>> > >
>> > >> Also, I think we should consider Günter's lyx2lyx patch [1], but I
>> > >> didn't have time to thoroughly review it myself.
>> > > Will anyone have time to take a look at the patch by Wednesday?
>> > 
>> > I could look at the code from a code-triaging point of view, but I have
>> > not followed
>> > the controversy about this, so someone would need to tell me what the
>> > code is supposed
>> > to do.

>> I don't think this is a change that should be performed at a RC1 stage,
>> frankly. It is too risky and of dubious utility.

> Thanks for bringing up this concern. The patch is not trivial. Further,
> the patch only deals with backwards compatibility. From what I recall,
> we place a higher importance on forward conversion, and although we do
> make efforts to provide good backward compatibility, I believe that we
> have at times knowingly not implemented certain functionality in our
> backwards conversion. 

Actually, the patch deals with both, forward conversion and backward
conversion. In tend to summarize both conversions under the tag "backwards
compatibility".

> Indeed, our "Development" manual covers this:

>   While the conversion routine is required to produce a document that
>   is equivalent to the old version, the requirements of the reversion
>   are not that strict. If possible, try to produce a proper reversion,
>   using ERT if needed, but for some features this might be too
>   complicated. In this case, the minimum requirement of the reversion
>   routine is that it produces a valid document which can be read by an
>   older LyX. If absolutely needed, even data loss is allowed for the
>   reversion.

> The current code (without the patch) clearly already satisfies the
> "minimum requirement".

I don't agree:

The current conversion routine does *not* produce a document that is
equivalent to the old version:

  * If you used literal em- and en-dashes in pre-2.2 documents,
you must manually unselect
"Document->Settings->Fonts->Output em- and en-dash as ligatures"
to ensure unchanged behaviour.


OTOH, the backwards conversion hack for 2.2 adding ZWSP

* needs to be reverted on forward conversion,
* prevents proper back-conversion to 2.1 and older,
* makes documents uncompilable with LyX 2.0 or earlier

I replaced the ZWSP with preamble code, but we could also just remove it
(as ERT was voted against and "the requirements of the reversion are not
that strict"). 
This would make the patch simpler and less error prone. 

> All this to say: I don't think the patch is too
> important for 2.3.0 and in my opinion I'm fine if we do not put it in.

Literal dashes may be less common than "ligature dashes" in pre-2.2
documents, however 
* the UserGuide documents Insert>Symbols als method to insert dashes since
  several LyX versions,
* there is evidence in mailing list threads that users were inserting
  literal dashes via system keyboard shortcuts years ago.

The problem here is, that we cannot know for sure how large the number of
affected users is: the changes in 2.2 did not affect them and they will only
speak up once the new damage is done.


I can propose a medium and a minimal patch:

The minimal patch just removes the ZWSP hack,
the medium patch also sets the new setting based on content.

> Since I don't think the patch is critical, and since we are so close to
> RC1, I propose that we should only consider this patch if a developer
> gives a confident +1, and if we have an extensive test suite. Although
> an extensive test suite cannot catch all potential issues, it can
> certainly help us be more confident for a patch like this.

> I cannot confidently review the patch, but if another developer
> carefully reviews the patch and gives a confident +1, and if Günter has
> time to help, I can create a test suite of many different scenarios.
> This would consist of different .lyx files created by current LyX 2.3.x,
> and we would check the export to 2.2.x with and without the patch. We
> could also check the loading of the resulting files in e.g. LyX 2.2.x,
> and the LaTeX output from 2.2.x.

> There are a lot of "if's" above and we have a short amount of time, so
> I'm not sure it's worth it at this point. But I will leave it to others
> to decide. If another developer thinks it is worth it enough to spend
> time carefully reviewing the patch, then I volunteer to spend time
> working on the test suite.

I have a bunch of test documents that I can review and provide.

Thanks,
Günter



diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py
index edc5b1ffa9..247934912a 100644
--- a/lib/lyx2lyx/lyx_2_3.py
+++ b/lib/lyx2lyx/lyx_2_3.py
@@ -1841,55 +1841,50 @@ 

Re: [LyX/master] New layout tags for better counter handling

[Jürgen Spitzmüller]

Am Freitag, den 27.10.2017, 02:35 -0400 schrieb Scott Kostyshak:
> On Fri, Oct 14, 2016 at 06:10:22PM +, Juergen Spitzmueller wrote:
> > commit 0eb651a2cf6c8c4d39e461748292ffe4e69f2386
> > Author: Juergen Spitzmueller 
> > Date:   Fri Oct 14 20:08:12 2016 +0200
> > 
> > New layout tags for better counter handling
> > 
> > * ResumeCounter: allow to resume an (enumerate) counter
> > * StepMasterCounter: allow to increase a master counter
> 
> LyX 2.3.x is opening some files slower than older LyX versions for
> me.
> After this commit, the Embedded Objects manual opens about 2 or 3
> seconds slower for me than before this commit, on average.

I fail to see how this is caused by this patch, though. Do these files
have resuming counters?

Jürgen

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

Re: [LyX/master] New layout tags for better counter handling

[Scott Kostyshak]

On Fri, Oct 14, 2016 at 06:10:22PM +, Juergen Spitzmueller wrote:
> commit 0eb651a2cf6c8c4d39e461748292ffe4e69f2386
> Author: Juergen Spitzmueller 
> Date:   Fri Oct 14 20:08:12 2016 +0200
> 
> New layout tags for better counter handling
> 
> * ResumeCounter: allow to resume an (enumerate) counter
> * StepMasterCounter: allow to increase a master counter

LyX 2.3.x is opening some files slower than older LyX versions for me.
After this commit, the Embedded Objects manual opens about 2 or 3
seconds slower for me than before this commit, on average.

Opening times can vary widely on my system, so I took the average of
several trials when doing a git bisect.

Can anyone else reproduce? Note that I'm using Qt 5.

Scott


signature.asc
Description: PGP signature

Re: PATCH for 2.3, use frescobaldi as preferred editor for lilypond material

[Scott Kostyshak]

On Wed, Oct 25, 2017 at 05:31:35PM +, Scott Kostyshak wrote:
> On Sat, Oct 14, 2017 at 02:40:32AM +, Scott Kostyshak wrote:
> > On Fri, Oct 13, 2017 at 06:34:46PM +, Richard Heck wrote:
> > 
> > > It can certainly go to master. I don't see why we shouldn't do it for
> > > 2.3.x myself, so I'd give it the necessary +1, but I guess I feel like
> > > Scott should probably chime in on this.
> > 
> > Thanks, yes, for feature patches I like to be involved.
> > 
> > This feature is fine with me, so since Richard +1'd it, go ahead for
> > 2.3.0. Thanks for the patch, Helge.
> 
> Helge or Richard, please commit as soon as possible if you would like
> this in 2.3.0rc1.

I committed to master at c4b4305f and to 2.3.x at c480b5bd. I'm still
curious about thoughts on centralizing the list of text editors.

Scott


signature.asc
Description: PGP signature