Re: #11203: LyX 2.3, Listings/minted: Document-wide settings yield invalid LaTeX code involving \setminted

[Richard Kimberly Heck]

The bug tracker sent you this email. Replying to it, though, only emails
the development list. You'd do best to reply on the original bug, which
you can do by clicking on the link at the bottom of the email.

Riki


On 07/22/2018 07:59 PM, Virgil L wrote:
> Thank you! It's great to hear that the bug may already have been
> eliminated. However, if I read it correctly, the description of the
> other bug does NOT emphasize or mention \setminted which in my case is
> the real culprit, because it yields errors that BREAK the execution of
> the LaTeX code.
>
> The way the other bug is described it sounds as if the document would
> compile but the wrong syntax highlighter would be used...that is NOT
> what happens in my case...the compilation of the produced LaTeX code
> does NOT conclude successfully.
>
> By the way,  you may want to contact the minted maintainer to ensure
> that in the next release all minted instructions and options are
> invoked as intended. He has been very responsive and probably would be
> even more so, if contacted by developers.
>
> BR
>
> Virgil
>
>
> On Sunday, July 22, 2018 10:36 PM, LyX Ticket Tracker 
> wrote:
>
>
> #11203: LyX 2.3, Listings/minted: Document-wide settings yield invalid
> LaTeX code
> involving \setminted
> +
> Reporter:  Virgilinux  |      Owner:  rikiheck
>     Type:  defect      |      Status:  fixedinmaster
> Priority:  normal      |  Milestone:
> Component:  insets      |    Version:  2.3.0
> Severity:  normal      |  Resolution:
> Keywords:              |
> +
> Changes (by forenr):
>
> * status:  new => fixedinmaster
>
>
> Comment:
>
> Should be fixed in master at [16ca5290/lyxgit].
>
> -- 
> Ticket URL: 
>
> The LyX Project 
> LyX -- The Document Processor
>
>
>
> 
>   Virus-free. www.avast.com
> 
>
>

Re: [LyX/master] Improve DEPM

[Richard Kimberly Heck]

On 07/22/2018 05:35 PM, Jean-Marc Lasgouttes wrote:
> Le 22/07/2018 à 23:23, Jean-Marc Lasgouttes a écrit :
>> commit 20976e81fb25899ee8d3ec5ed941fda6b453f59f
>> Author: Jean-Marc Lasgouttes 
>> Date:   Sun Jul 22 22:13:44 2018 +0200
>>
>>  Improve DEPM
>>   Now any sequence of spaces around old cursor will be
>> removed, even at
>>  start or end of paragraph. Sequences of more than 2 characters are
>>  also taken into account.
>>   The version of DEPM which acts on a sequence of paragraphs
>> is also
>>  rewritten to match the local one.
>
> Hopefully I did not break anything wrt DEPM, but testing is appreciated.
>
> What I would like to do, though is
> 1/ disable DEPM in read-only document
> 2/ use undo to be able to rollback such changes
>
> Would anyone oppose to that. I remember that years ago Vincent for
> example disagreed, but since he is not around anymore... ;)

It sounds good in principle.

Is this a possibility for 2.3.x? If so, you can commit to stable once
2.3.1 is out. Then it should get lots of testing.

Riki

Re: #11203: LyX 2.3, Listings/minted: Document-wide settings yield invalid LaTeX code involving \setminted

[Virgil L]

Thank you! It's great to hear that the bug may already have been eliminated. 
However, if I read it correctly, the description of the other bug does NOT 
emphasize or mention \setminted which in my case is the real culprit, because 
it yields errors that BREAK the execution of the LaTeX code.
The way the other bug is described it sounds as if the document would compile 
but the wrong syntax highlighter would be used...that is NOT what happens in my 
case...the compilation of the produced LaTeX code does NOT conclude 
successfully.
By the way,  you may want to contact the minted maintainer to ensure that in 
the next release all minted instructions and options are invoked as intended. 
He has been very responsive and probably would be even more so, if contacted by 
developers.
BR
Virgil 

On Sunday, July 22, 2018 10:36 PM, LyX Ticket Tracker  wrote:
 

 #11203: LyX 2.3, Listings/minted: Document-wide settings yield invalid LaTeX 
code
involving \setminted
+
 Reporter:  Virgilinux  |      Owner:  rikiheck
    Type:  defect      |      Status:  fixedinmaster
 Priority:  normal      |  Milestone:
Component:  insets      |    Version:  2.3.0
 Severity:  normal      |  Resolution:
 Keywords:              |
+
Changes (by forenr):

 * status:  new => fixedinmaster


Comment:

 Should be fixed in master at [16ca5290/lyxgit].

-- 
Ticket URL: 
The LyX Project 
LyX -- The Document Processor


   

|  | Virus-free. www.avast.com  |

Re: [LyX/master] Improve DEPM

[Jean-Marc Lasgouttes]

Le 22/07/2018 à 23:23, Jean-Marc Lasgouttes a écrit :

commit 20976e81fb25899ee8d3ec5ed941fda6b453f59f
Author: Jean-Marc Lasgouttes 
Date:   Sun Jul 22 22:13:44 2018 +0200

 Improve DEPM
 
 Now any sequence of spaces around old cursor will be removed, even at

 start or end of paragraph. Sequences of more than 2 characters are
 also taken into account.
 
 The version of DEPM which acts on a sequence of paragraphs is also

 rewritten to match the local one.


Hopefully I did not break anything wrt DEPM, but testing is appreciated.

What I would like to do, though is
1/ disable DEPM in read-only document
2/ use undo to be able to rollback such changes

Would anyone oppose to that. I remember that years ago Vincent for
example disagreed, but since he is not around anymore... ;)

JMarc


---
  src/Text.h|4 ---
  src/Text2.cpp |   73 
  2 files changed, 52 insertions(+), 25 deletions(-)

diff --git a/src/Text.h b/src/Text.h
index f09acc8..b54277b 100644
--- a/src/Text.h
+++ b/src/Text.h
@@ -348,10 +348,6 @@ private:
/// The InsetText owner shall have access to everything.
friend class InsetText;
  
-	// fix the cursor `cur' after a characters has been deleted at `where'

-   // position. Called by deleteEmptyParagraphMechanism
-   static void fixCursorAfterDelete(CursorSlice & cur, CursorSlice const & 
where);
-
// At cursor position 0, try to merge the paragraph with the one before 
it.
// Ignore change tracking, i.e., physically remove the end-of-par 
character
bool backspacePos0(Cursor & cur);
diff --git a/src/Text2.cpp b/src/Text2.cpp
index 869684e..d8a9114 100644
--- a/src/Text2.cpp
+++ b/src/Text2.cpp
@@ -780,9 +780,11 @@ bool Text::cursorDownParagraph(Cursor & cur)
  }
  
  
-// fix the cursor `cur' after a characters has been deleted at `where'

+namespace {
+// fix the cursor `cur' after characters has been deleted at `where'
  // position. Called by deleteEmptyParagraphMechanism
-void Text::fixCursorAfterDelete(CursorSlice & cur, CursorSlice const & where)
+void fixCursorAfterDelete(CursorSlice & cur, CursorSlice const & where,
+ pos_type from, pos_type to)
  {
// Do nothing if cursor is not in the paragraph where the
// deletion occurred,
@@ -790,8 +792,8 @@ void Text::fixCursorAfterDelete(CursorSlice & cur, CursorSlice 
const & where)
return;
  
  	// If cursor position is after the deletion place update it

-   if (cur.pos() > where.pos())
-   --cur.pos();
+   if (cur.pos() > from)
+   cur.pos() = max(from, cur.pos() - (to - from));
  
  	// Check also if we don't want to set the cursor on a spot behind the

// pagragraph because we erased the last character.
@@ -799,6 +801,8 @@ void Text::fixCursorAfterDelete(CursorSlice & cur, CursorSlice 
const & where)
cur.pos() = cur.lastpos();
  }
  
+}

+
  
  bool Text::deleteEmptyParagraphMechanism(Cursor & cur,

Cursor & old, bool & need_anchor_change)
@@ -840,23 +844,35 @@ bool Text::deleteEmptyParagraphMechanism(Cursor & cur,
bool const same_par_pos = depth == cur.depth() - 1 && same_par
&& old.pos() == cur[depth].pos();
  
-	// If the chars around the old cursor were spaces, delete one of them.

+   // If the chars around the old cursor were spaces, delete some of
+   // them , but only if the cursor has really moved.
if (!same_par_pos) {
-   // Only if the cursor has really moved.
-   if (old.pos() > 0
-   && old.pos() < oldpar.size()
-   && oldpar.isLineSeparator(old.pos())
-   && oldpar.isLineSeparator(old.pos() - 1)
-   && !oldpar.isDeleted(old.pos() - 1)
-   && !oldpar.isDeleted(old.pos())) {
-   oldpar.eraseChar(old.pos() - 1, 
cur.buffer()->params().track_changes);
+   // find range of spaces around cursors
+   int from = old.pos();
+   while (from > 0
+  && oldpar.isLineSeparator(from - 1)
+  && !oldpar.isDeleted(from - 1))
+   --from;
+   int to = old.pos();
+   while (to < oldpar.size() - 1
+  && oldpar.isLineSeparator(to)
+  && !oldpar.isDeleted(to))
+   ++to;
+
+   // If we are not at the extremity of the paragraph, keep one 
space
+   if (from != to && from > 0 && to < oldpar.size())
+   ++from;
+
+   // Remove spaces and adapt cursor.
+   if (from < to) {
+   oldpar.eraseChars(from, to, 
cur.buffer()->params().track_changes);
  // FIXME: This will not work anymore when we have multiple views of the same 
buffer
  // In this

Re: Failing exports

[Kornel Benko]

Am Sonntag, 22. Juli 2018 20:05:10 CEST schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 22.07.2018, 19:13 +0200 schrieb Jürgen Spitzmüller:
> > > Disallow any inset inside ERT
> > 
> > Yes, I was sure this is the issue.
> 
> fixed.
> 
> Jürgen
> 

Confirmed, ja/Math.lyx tests succeeded now.
Thanks
Kornel 


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

Re: #11201: LyX crashing when adding citation from Zotero using LyZ

[Jean-Marc Lasgouttes]

Le 22/07/2018 à 20:36, Jean-Marc Lasgouttes a écrit :

Le 22/07/2018 à 19:33, Thomas DiPrete a écrit :
I found this in the console from 7/17, which is the date I reported 
the bug.  I hope it is helpful. I've attached to this message the 
several versions.


I am not sure that this contains more information about what LyX is 
doing at this time. I am not a Zotero user, so trying to reproduce the 
problem on my side is a bit complicated.


PS: please do not reply by e-mail, it is better for us if interaction 
takes place on trac.


JMarc

Re: #11201: LyX crashing when adding citation from Zotero using LyZ

[Jean-Marc Lasgouttes]

Le 22/07/2018 à 19:33, Thomas DiPrete a écrit :
I found this in the console from 7/17, which is the date I reported the 
bug.  I hope it is helpful. I've attached to this message the several 
versions.


I am not sure that this contains more information about what LyX is 
doing at this time. I am not a Zotero user, so trying to reproduce the 
problem on my side is a bit complicated.


If you enable View>Message Pane, you will see something like the 
attached image on the bottom of the windows. Click on Settings (the tab 
on the right), then on "(o) Selected" and then double click on lyxserver 
so that it says "yes".


After that, if you reproduce the crashing procedure, you should find the 
relevant lyx messages in Console.app before the crash dump. I do not 
have a mac at hand, I can unfortunately not be more precise.


JMarc

Re: [LyX/master] Draw top/bottom rules heavier for booktab

[Jean-Marc Lasgouttes]

Le 22/07/2018 à 18:59, Daniel a écrit :
But I am a bit lost. You state the widths above as em fractions but say 
that the values are integers. Do you mean that the list of widths widths 
above are as defined in the booktab package but you are using integer 
values to set the line width in LyX?


The em values are indeed what booktabs defines. However, they all 
correspond to <1 pixel values except when dpi is very high. So I have 
hardcoded to 2 pixels for heavy and 1 pixel for thin. A reason for not 
taking dpi into account is that no everybody agree that  lines should 
become thicker with zoom.


JMarc

Re: Failing exports

[Jürgen Spitzmüller]

Am Sonntag, den 22.07.2018, 19:13 +0200 schrieb Jürgen Spitzmüller:
> > Disallow any inset inside ERT
> 
> Yes, I was sure this is the issue.

fixed.

Jürgen


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

Re: Failing exports

[Jürgen Spitzmüller]

Am Sonntag, den 22.07.2018, 14:06 +0200 schrieb Kornel Benko:
> bisect led to
> d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91 is the first bad commit
> commit d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91
> Author: Juergen Spitzmueller 
> Date:   Tue Jul 10 07:11:59 2018 +0200
> 
> Disallow any inset inside ERT

Yes, I was sure this is the issue. Thanks for checking.

Jürgen


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

Re: [LyX/master] Draw top/bottom rules heavier for booktab

[Daniel]

On 21/07/2018 21:13, Jean-Marc Lasgouttes wrote:

Le 21/07/2018 à 19:50, Daniel a écrit :

The widths are:
heavy=0.008em
thin=0.05em
cmid=0.03em

If I do use these values, I can only see a difference between heavy 
and thin beyond 180% zoom (at 100dpi) and the 3 width are different 
only over 300% zoom.


So I do not really see how I could differentiate these 3 values.


So, on HiDPI displays I set 1px, 1.5px, and 2px, and on non HiDPI 
displays 1px, 2px, and 3px. But I worked with pixel so that was easier 
to solve.


For now all our values are integers. It is still possible to do 
something about it, but I am not sure how important it is.


Me neither.

But I am a bit lost. You state the widths above as em fractions but say 
that the values are integers. Do you mean that the list of widths widths 
above are as defined in the booktab package but you are using integer 
values to set the line width in LyX?


Daniel

Re: [LyX/master] Draw top/bottom rules heavier for booktab

[Joel Kulesza]

On Thu, Jul 19, 2018 at 4:28 PM, Jean-Marc Lasgouttes 
wrote:
>
> Please try it out. If people like it, it can be backported.
>
> JMarc


I tried this and though I didn't experiment extensively (or try to break
it), I really like it on its first impression.  Good addition.

Thanks,
Joel

Re: Failing exports

[Kornel Benko]

Am Sonntag, 22. Juli 2018 15:01:06 CEST schrieb Jean-Marc Lasgouttes 
:
> Le 22/07/2018 à 14:57, Jean-Marc Lasgouttes a écrit :
> > Le 22/07/2018 à 14:06, Kornel Benko a écrit :
> >> bisect led to
> >> d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91 is the first bad commit
> >> commit d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91
> >> Author: Juergen Spitzmueller 
> >> Date:   Tue Jul 10 07:11:59 2018 +0200
> >>
> >>  Disallow any inset inside ERT
> > 
> > Not a lyx2lyx issue, then. Good.
> 
> Thanks for the bisect BTW.

:)

> I find them so long and inconvenient to do 
> that I try to avoid them (in this case, I asked you because I thought it 
> was one of the two recent lyx2lyx changes :).
> 
> JMarc

Yes, it looked like lyx2lyx error. But sometimes a bisect is a must :(

Kornel



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

Re: Failing exports

[Jean-Marc Lasgouttes]

Le 22/07/2018 à 14:57, Jean-Marc Lasgouttes a écrit :

Le 22/07/2018 à 14:06, Kornel Benko a écrit :

bisect led to
d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91 is the first bad commit
commit d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91
Author: Juergen Spitzmueller 
Date:   Tue Jul 10 07:11:59 2018 +0200

 Disallow any inset inside ERT


Not a lyx2lyx issue, then. Good.


Thanks for the bisect BTW. I find them so long and inconvenient to do 
that I try to avoid them (in this case, I asked you because I thought it 
was one of the two recent lyx2lyx changes :).


JMarc

Re: Failing exports

[Jean-Marc Lasgouttes]

Le 22/07/2018 à 14:06, Kornel Benko a écrit :

bisect led to
d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91 is the first bad commit
commit d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91
Author: Juergen Spitzmueller 
Date:   Tue Jul 10 07:11:59 2018 +0200

 Disallow any inset inside ERT


Not a lyx2lyx issue, then. Good.

JMarc


 Attempting to do this crashes in master, and is not supported anyway.

:04 04 9a0e94fc78f55cf266b3de53907516b776d51bf7 
e7e6f5812075fbb01963a024f4130050d04a15eb M  src

Kornel

Re: Failing exports

[Kornel Benko]

Am Sonntag, 22. Juli 2018 13:35:23 CEST schrieb Jean-Marc Lasgouttes 
:
> Le 22/07/2018 à 11:08, Kornel Benko a écrit :
> > Am Sonntag, 22. Juli 2018 10:32:59 CEST schrieb Jürgen Spitzmüller 
> > :
> >> Am Sonntag, den 22.07.2018, 09:59 +0200 schrieb Kornel Benko:
> >>> It is \ only. Search for instance for ' sungsmittel', then open the
> >>> ERT to the left.
> >>
> >> Not here. See screenshot. Are you sure yours is a clean checkout?
> > 
> > Yes, checked multiple times.
> > BUT
> > there is something fishy with lyx2lyx probably.
> > Compare orig snippet with converted to 2.4.
> > And, in fact, using lyx2.3 I _can_ compile.
> 
> Can you tell which of the recent lyx2lyx changes is faulty? The relevant 
> ticket is
> https://www.lyx.org/trac/ticket/11200
> 
> JMarc

bisect led to
d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91 is the first bad commit
commit d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91
Author: Juergen Spitzmueller 
Date:   Tue Jul 10 07:11:59 2018 +0200

Disallow any inset inside ERT

Attempting to do this crashes in master, and is not supported anyway.

:04 04 9a0e94fc78f55cf266b3de53907516b776d51bf7 
e7e6f5812075fbb01963a024f4130050d04a15eb M  src

Kornel

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

Re: Failing exports

[Jean-Marc Lasgouttes]

Le 22/07/2018 à 11:08, Kornel Benko a écrit :

Am Sonntag, 22. Juli 2018 10:32:59 CEST schrieb Jürgen Spitzmüller 
:

Am Sonntag, den 22.07.2018, 09:59 +0200 schrieb Kornel Benko:

It is \ only. Search for instance for ' sungsmittel', then open the
ERT to the left.


Not here. See screenshot. Are you sure yours is a clean checkout?


Yes, checked multiple times.
BUT
there is something fishy with lyx2lyx probably.
Compare orig snippet with converted to 2.4.
And, in fact, using lyx2.3 I _can_ compile.


Can you tell which of the recent lyx2lyx changes is faulty? The relevant 
ticket is

https://www.lyx.org/trac/ticket/11200

JMarc

Re: Failing exports

[Kornel Benko]

Am Sonntag, 22. Juli 2018 10:32:59 CEST schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 22.07.2018, 09:59 +0200 schrieb Kornel Benko:
> > It is \ only. Search for instance for ' sungsmittel', then open the
> > ERT to the left.
> 
> Not here. See screenshot. Are you sure yours is a clean checkout?

Yes, checked multiple times.
BUT
there is something fishy with lyx2lyx probably.
Compare orig snippet with converted to 2.4.
And, in fact, using lyx2.3 I _can_ compile.

Kornelberlagerten Signale (Netzwerk, L
\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash

\begin_inset Quotes erd
\end_inset

o
\end_layout

\end_inset

sungsmittel) zu trennen.

berlagerten Signale (Netzwerk, L
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
o
\end_layout

\end_inset

sungsmittel) zu trennen.



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

Re: Failing exports

[Jürgen Spitzmüller]

Am Sonntag, den 22.07.2018, 09:34 +0200 schrieb Jürgen Spitzmüller:
> Am Sonntag, den 22.07.2018, 07:44 +0200 schrieb Kornel Benko:
> > IMHO, the master has some time before release. Pleading for the
> > change.
> 
> We certainly need to do that change, but still there will be this
> backwards compatibility problem we cannot sort out (except if we
> introduce our own definition).
> 
> This is really a flaw in the class itself.

And it's not the only one. Clearly the new maintainer of the class does
not care a bit about (or was not aware of) forward compatibility:
https://github.com/gsilano/EuropeCV/issues/2

This really makes maintenance of this class very hard, if not
impossible.

Jürgen

> 
> Jürgen
> 
> > 
> > Kornel


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

Re: Failing exports

[Kornel Benko]

Am Sonntag, 22. Juli 2018 09:37:45 CEST schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 22.07.2018, 07:38 +0200 schrieb Kornel Benko:
> > I am using the latest master too.
> > Changing the language of both German paragraphs in multicol env to
> > Japanese and substituting
> > \U\a\ss etc to Üäß 
> > then the compilation succeeds.
> 
> Strange. We did the opposite change just recently to fix a problem we
> had (and you reported) with non-Ascii glyphs.
> https://marc.info/?l=lyx-devel&m=153056731819336&w=2
> 
> BTW is it really \U\a rather than \"U\"a?
> 

It is \ only. Search for instance for ' sungsmittel', then open the ERT to the 
left.

Kornel


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

Re: Failing exports

[Jürgen Spitzmüller]

Am Sonntag, den 22.07.2018, 07:38 +0200 schrieb Kornel Benko:
> I am using the latest master too.
> Changing the language of both German paragraphs in multicol env to
> Japanese and substituting
> \U\a\ss etc to Üäß 
> then the compilation succeeds.

Strange. We did the opposite change just recently to fix a problem we
had (and you reported) with non-Ascii glyphs.
https://marc.info/?l=lyx-devel&m=153056731819336&w=2

BTW is it really \U\a rather than \"U\"a?

> 
>   Kornel


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

Re: Failing exports

[Jürgen Spitzmüller]

Am Sonntag, den 22.07.2018, 07:44 +0200 schrieb Kornel Benko:
> IMHO, the master has some time before release. Pleading for the
> change.

We certainly need to do that change, but still there will be this
backwards compatibility problem we cannot sort out (except if we
introduce our own definition).

This is really a flaw in the class itself.

Jürgen

> 
>   Kornel


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