Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 05/12/2016 à 09:50, Jean-Marc Lasgouttes a écrit :

Le 10/11/2016 à 10:19, Jean-Marc Lasgouttes a écrit :

So shall I apply it?


Yes, please.


Done in master at 6dfbab31. Richard, this is candidate for branch too,
since it leads to crashes.


Ping :) Richard, is this OK for branch?


Ping Ping. This is my monthly ping for including this in stable.

Richard, if you do not answer, I warn you that I will do it again on Feb 
9 ;)


JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 10/11/2016 à 10:19, Jean-Marc Lasgouttes a écrit :

So shall I apply it?


Yes, please.


Done in master at 6dfbab31. Richard, this is candidate for branch too,
since it leads to crashes.


Ping :) Richard, is this OK for branch?

JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 10/11/2016 à 10:19, Jean-Marc Lasgouttes a écrit :

Le 09/11/2016 à 21:45, Stephan Witt a écrit :

Am 09.11.2016 um 12:10 schrieb Jean-Marc Lasgouttes :


Le 08/11/2016 à 14:56, Stephan Witt a écrit :

I tested your patch and it works for me. The change of
"lib/unicodesymbols“
leads to proper output. I cannot tell how the impact of the latter
change is.


So shall I apply it?


Yes, please.


Done in master at 6dfbab31. Richard, this is candidate for branch too,
since it leads to crashes.


Richard?

JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 09/11/2016 à 21:45, Stephan Witt a écrit :

Am 09.11.2016 um 12:10 schrieb Jean-Marc Lasgouttes :


Le 08/11/2016 à 14:56, Stephan Witt a écrit :

I tested your patch and it works for me. The change of "lib/unicodesymbols“
leads to proper output. I cannot tell how the impact of the latter change is.


So shall I apply it?


Yes, please.


Done in master at 6dfbab31. Richard, this is candidate for branch too, 
since it leads to crashes.


JMarc

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 09.11.2016 um 12:10 schrieb Jean-Marc Lasgouttes :
> 
> Le 08/11/2016 à 14:56, Stephan Witt a écrit :
>> I tested your patch and it works for me. The change of "lib/unicodesymbols“
>> leads to proper output. I cannot tell how the impact of the latter change is.
> 
> So shall I apply it?

Yes, please.

> I prefer to leave the rest in the hands of somebody who knows what this is 
> all about.

Yes, I can understand this.

Stephan

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 08/11/2016 à 14:56, Stephan Witt a écrit :

I tested your patch and it works for me. The change of "lib/unicodesymbols“
leads to proper output. I cannot tell how the impact of the latter change is.


So shall I apply it? I prefer to leave the rest in the hands of somebody 
who knows what this is all about.


JMarc

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 08.11.2016 um 21:03 schrieb Enrico Forestieri :
> 
> On Tue, Nov 08, 2016 at 02:28:51PM +0100, Stephan Witt wrote:
>> Am 07.11.2016 um 15:34 schrieb Enrico Forestieri :
>>> 
>>> On Mon, Nov 07, 2016 at 01:31:31PM +, Guenter Milde wrote:
 
 As the meaning of LINE SEPARATOR and PARAGRAPH SEPARATOR is clear from
 http://unicode.org/versions/Unicode5.2.0/ch05.pdf
 we can transform them to the corresponding LaTeX representation:
 
 0x2028 ""  "" "" "" "" # LINE SEPARATOR
 0x2029 "\\par" "" "" "" "" # PARAGRAPH SEPARATOR
>>> 
>>> We have insets for both:
>>> 
>>> \begin_inset Newline newline
>>> \end_inset
>>> 
>>> \begin_inset Separator latexpar
>>> \end_inset
>> 
>> That’s ok. But what’s your proposal? Sorry, I didn’t get the message.
>> 
>> The problem is how to deal with LyX-documents containing the mentioned
>> unicode characters. Do you propose to convert them when parsing the
>> documents and pasted text? Would this ensure LyX (and LaTeX) never see
>> the raw unicode characters? E.g. with included material?
> 
> Sorry, I thought it was a copy/paste issue.
> 
> -- 
> Enrico

Ok ;-) Thanks.

Stephan

Re: pasted non-acceptable symbol

[Enrico Forestieri]

On Tue, Nov 08, 2016 at 02:28:51PM +0100, Stephan Witt wrote:
> Am 07.11.2016 um 15:34 schrieb Enrico Forestieri :
> > 
> > On Mon, Nov 07, 2016 at 01:31:31PM +, Guenter Milde wrote:
> >> 
> >> As the meaning of LINE SEPARATOR and PARAGRAPH SEPARATOR is clear from
> >> http://unicode.org/versions/Unicode5.2.0/ch05.pdf
> >> we can transform them to the corresponding LaTeX representation:
> >> 
> >> 0x2028 ""  "" "" "" "" # LINE SEPARATOR
> >> 0x2029 "\\par" "" "" "" "" # PARAGRAPH SEPARATOR
> > 
> > We have insets for both:
> > 
> > \begin_inset Newline newline
> > \end_inset
> > 
> > \begin_inset Separator latexpar
> > \end_inset
> 
> That’s ok. But what’s your proposal? Sorry, I didn’t get the message.
> 
> The problem is how to deal with LyX-documents containing the mentioned
> unicode characters. Do you propose to convert them when parsing the
> documents and pasted text? Would this ensure LyX (and LaTeX) never see
> the raw unicode characters? E.g. with included material?

Sorry, I thought it was a copy/paste issue.

-- 
Enrico

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 07.11.2016 um 10:59 schrieb Jean-Marc Lasgouttes :
> 
> Le 06/11/2016 à 14:30, Jean-Marc Lasgouttes a écrit :
>> This is a more radical approach that what I have in mind, and I do not
>> know whether it is safe. My idea was to modify the Row building code and
>> replace the character with some visual cue (in addition with the row
>> breaking), because I am not confident in sending this character to Qt
>> string rendering functions.
>> 
>> I'll propose something shortly.
> 
> Finally, I convinced myself that your approach is correct if we want to keep 
> the breaks. In the following patch I add some one screen hints of what is 
> going on. I could use a color of the characters, but I am not sure what to 
> do, these are actual characters, not insets. A solution could be to add a 
> frame around the characters.
> 
> The next problem is running LaTeX. By default, these characters are not 
> accepted. Could our local latex+unicode experts tell us whether it makes any 
> sense to handle these characters in LaTeX of whether nobody cares and they 
> should be ignored on output?
> 
> I suspect that adding them to lib/unicodesymbols would do more harm than good.
> 
> I am not sure that the approach of removing them when converting from plain 
> text (paste or insert) is worth it, since we have to handle the characters 
> anyway. But again, at some moments it seems right to me to handle them there.
> 
> For example, this hints that we should handle them like (CR)LF:
> http://stackoverflow.com/questions/3072152/what-is-unicode-character-2028-ls-line-separator-used-for
> 
> JMarc
> 
> <0001-Handle-properly-unicode-paragraph-line-break.patch>

I tested your patch and it works for me. The change of "lib/unicodesymbols“
leads to proper output. I cannot tell how the impact of the latter change is.

Stephan

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 07.11.2016 um 15:34 schrieb Enrico Forestieri :
> 
> On Mon, Nov 07, 2016 at 01:31:31PM +, Guenter Milde wrote:
>> 
>> As the meaning of LINE SEPARATOR and PARAGRAPH SEPARATOR is clear from
>> http://unicode.org/versions/Unicode5.2.0/ch05.pdf
>> we can transform them to the corresponding LaTeX representation:
>> 
>> 0x2028 ""  "" "" "" "" # LINE SEPARATOR
>> 0x2029 "\\par" "" "" "" "" # PARAGRAPH SEPARATOR
> 
> We have insets for both:
> 
> \begin_inset Newline newline
> \end_inset
> 
> \begin_inset Separator latexpar
> \end_inset

That’s ok. But what’s your proposal? Sorry, I didn’t get the message.

The problem is how to deal with LyX-documents containing the mentioned
unicode characters. Do you propose to convert them when parsing the
documents and pasted text? Would this ensure LyX (and LaTeX) never see
the raw unicode characters? E.g. with included material?

Stephan

Re: pasted non-acceptable symbol

[Guenter Milde]

On 2016-11-07, Jean-Marc Lasgouttes wrote:
> Le 07/11/2016 à 14:31, Guenter Milde a écrit :

...

> Converting them is possible in insertStringAsXXX and in tex2lyx, as I 
> wrote. But we cannot forbid the characters to be in our documents (or if 
> we can, it will be a waste of energy to catter for all cases). This is 
> why I was wondering what would be the last-chance solution.

> We have a patch for not crashing. Now an approach for exporting some 
> working LaTeX would be a good complement.

I see.
As we have the precedence with NBSP and similar characters, I recommend to
use replacements in lib/unicodesymbols for the fallback export solution
(as written in my last posting).

Günter

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 07/11/2016 à 14:31, Guenter Milde a écrit :

Finally, I convinced myself that your approach is correct if we want to
keep the breaks. In the following patch I add some one screen hints of
what is going on. I could use a color of the characters, but I am not
sure what to do, these are actual characters, not insets. A solution
could be to add a frame around the characters.


I'd rather convert them to the "usual LyX representations"

  \begin_inset Newline newline
  \end_inset

and

  \begin_layout 


Converting them is possible in insertStringAsXXX and in tex2lyx, as I 
wrote. But we cannot forbid the characters to be in our documents (or if 
we can, it will be a waste of energy to catter for all cases). This is 
why I was wondering what would be the last-chance solution.


We have a patch for not crashing. Now an approach for exporting some 
working LaTeX would be a good complement.


JMarc

Re: pasted non-acceptable symbol

[Enrico Forestieri]

On Mon, Nov 07, 2016 at 01:31:31PM +, Guenter Milde wrote:
> 
> As the meaning of LINE SEPARATOR and PARAGRAPH SEPARATOR is clear from
> http://unicode.org/versions/Unicode5.2.0/ch05.pdf
> we can transform them to the corresponding LaTeX representation:
> 
> 0x2028 ""  "" "" "" "" # LINE SEPARATOR
> 0x2029 "\\par" "" "" "" "" # PARAGRAPH SEPARATOR

We have insets for both:

\begin_inset Newline newline
\end_inset

\begin_inset Separator latexpar
\end_inset

-- 
Enrico

Re: pasted non-acceptable symbol

[Guenter Milde]

On 2016-11-07, Jean-Marc Lasgouttes wrote:
> Le 06/11/2016 à 14:30, Jean-Marc Lasgouttes a écrit :
>> This is a more radical approach that what I have in mind, and I do not
>> know whether it is safe. My idea was to modify the Row building code and
>> replace the character with some visual cue (in addition with the row
>> breaking), because I am not confident in sending this character to Qt
>> string rendering functions.

>> I'll propose something shortly.

> Finally, I convinced myself that your approach is correct if we want to 
> keep the breaks. In the following patch I add some one screen hints of 
> what is going on. I could use a color of the characters, but I am not 
> sure what to do, these are actual characters, not insets. A solution 
> could be to add a frame around the characters.

I'd rather convert them to the "usual LyX representations" 

  \begin_inset Newline newline
  \end_inset

and

  \begin_layout 
  
whenever possible. In my understanding,
http://unicode.org/versions/Unicode5.2.0/ch05.pdf recommends just this:
interpret these characters as unambiguous representations of a line preak
and paragraph break.

> The next problem is running LaTeX. By default, these characters are not 
> accepted. Could our local latex+unicode experts tell us whether it makes 
> any sense to handle these characters in LaTeX of whether nobody cares 
> and they should be ignored on output?

> I suspect that adding them to lib/unicodesymbols would do more harm than 
> good.

We could handle them similar to other characters that have a corresponding
LyX inset, e.g. spaces:

\begin_inset space ~
\end_inset

corresponds to

0x00a0 "~""" "notermination=both" "~" "" # NO-BREAK 
SPACE

or to other special characters like
\SpecialChar nobreakdash or \SpecialChar softhyphen

0x2011 "\\nobreakdash-"   "amsmath" "notermination=text" "" "" # 
NON-BREAKING HYPHEN

0x00ad "\\-"  "" "notermination=text" "" "" # SOFT HYPHEN

In both cases, lib/unicodesymbols has "fallback definitions" in case the
literal Unicode character is still in the document.

As the meaning of LINE SEPARATOR and PARAGRAPH SEPARATOR is clear from
http://unicode.org/versions/Unicode5.2.0/ch05.pdf
we can transform them to the corresponding LaTeX representation:

0x2028 ""  "" "" "" "" # LINE SEPARATOR
0x2029 "\\par" "" "" "" "" # PARAGRAPH SEPARATOR


Günter

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 06/11/2016 à 14:30, Jean-Marc Lasgouttes a écrit :

This is a more radical approach that what I have in mind, and I do not
know whether it is safe. My idea was to modify the Row building code and
replace the character with some visual cue (in addition with the row
breaking), because I am not confident in sending this character to Qt
string rendering functions.

I'll propose something shortly.


Finally, I convinced myself that your approach is correct if we want to 
keep the breaks. In the following patch I add some one screen hints of 
what is going on. I could use a color of the characters, but I am not 
sure what to do, these are actual characters, not insets. A solution 
could be to add a frame around the characters.


The next problem is running LaTeX. By default, these characters are not 
accepted. Could our local latex+unicode experts tell us whether it makes 
any sense to handle these characters in LaTeX of whether nobody cares 
and they should be ignored on output?


I suspect that adding them to lib/unicodesymbols would do more harm than 
good.


I am not sure that the approach of removing them when converting from 
plain text (paste or insert) is worth it, since we have to handle the 
characters anyway. But again, at some moments it seems right to me to 
handle them there.


For example, this hints that we should handle them like (CR)LF:
http://stackoverflow.com/questions/3072152/what-is-unicode-character-2028-ls-line-separator-used-for

JMarc

From 1d5ae75919e70c2b93a471bde9024c3738a9b13f Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Mon, 7 Nov 2016 10:14:39 +0100
Subject: [PATCH] Handle properly unicode paragraph/line break

They are shown on screen by arrow or pilcrow symbol and cause a line break.

They are still not handled in LaTeX output, though.
---
 src/Paragraph.cpp   |5 +
 src/TextMetrics.cpp |   19 ++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 8afa475..05c10b5 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -3147,6 +3147,11 @@ bool Paragraph::isHfill(pos_type pos) const
 
 bool Paragraph::isNewline(pos_type pos) const
 {
+	// U+2028 LINE SEPARATOR
+	// U+2029 PARAGRAPH SEPARATOR
+	char_type const c = d->text_[pos];
+	if (c == 0x2028 || c == 0x2029)
+		return true;
 	Inset const * inset = getInset(pos);
 	return inset && inset->lyxCode() == NEWLINE_CODE;
 }
diff --git a/src/TextMetrics.cpp b/src/TextMetrics.cpp
index 8f7ac82..17ee2e4 100644
--- a/src/TextMetrics.cpp
+++ b/src/TextMetrics.cpp
@@ -864,7 +864,23 @@ bool TextMetrics::breakRow(Row & row, int const right_margin) const
 		} else if (c == '\t')
 			row.addSpace(i, theFontMetrics(*fi).width(from_ascii("")),
  *fi, par.lookupChange(i));
-		else {
+		else if (c == 0x2028 || c == 0x2029) {
+			/**
+			 * U+2028 LINE SEPARATOR
+			 * U+2029 PARAGRAPH SEPARATOR
+
+			 * These are special unicode characters that break
+			 * lines/pragraphs. Not handling them lead to trouble wrt
+			 * Qt QTextLayout formatting. We add a visible character
+			 * on screen so that the user can see that something is
+			 * happening.
+			*/
+			row.finalizeLast();
+			// ⤶ U+2936 ARROW POINTING DOWNWARDS THEN CURVING LEFTWARDS
+			// ¶ U+00B6 PILCROW SIGN
+			char_type const screen_char = (c == 0x2028) ? 0x2936 : 0x00B6;
+			row.add(i, screen_char, *fi, par.lookupChange(i));
+		} else {
 			// FIXME: please someone fix the Hebrew/Arabic parenthesis mess!
 			// see also Paragraph::getUChar.
 			if (fi->language()->lang() == "hebrew") {
@@ -925,6 +941,7 @@ bool TextMetrics::breakRow(Row & row, int const right_margin) const
 		BufferParams const & bparams
 			= text_->inset().buffer().params();
 		f.setLanguage(par.getParLanguage(bparams));
+		// ¶ U+00B6 PILCROW SIGN
 		row.addVirtual(end, docstring(1, char_type(0x00B6)), f, Change());
 	}
 
-- 
1.7.9.5

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 06.11.2016 um 14:30 schrieb Jean-Marc Lasgouttes :
> 
> Le 05/11/2016 à 21:25, Stephan Witt a écrit :
>>> 4/ catch the characters at the level of the row breaking algorithm 
>>> (TextMetrics::breakRow). This should be pretty straightforward to do.
>> 
>> Yes, this would be the best solution. It seems so easy that I tried to
>> come up with a patch myself. See attached. It works for this problem -
>> I don’t know if its covers all possible code paths, though.
> 
> This is a more radical approach that what I have in mind, and I do not know 
> whether it is safe. My idea was to modify the Row building code and replace 
> the character with some visual cue (in addition with the row breaking), 
> because I am not confident in sending this character to Qt string rendering 
> functions.
> 
> I'll propose something shortly.

Ok, Stephan

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 05/11/2016 à 21:25, Stephan Witt a écrit :

4/ catch the characters at the level of the row breaking algorithm 
(TextMetrics::breakRow). This should be pretty straightforward to do.


Yes, this would be the best solution. It seems so easy that I tried to
come up with a patch myself. See attached. It works for this problem -
I don’t know if its covers all possible code paths, though.


This is a more radical approach that what I have in mind, and I do not 
know whether it is safe. My idea was to modify the Row building code and 
replace the character with some visual cue (in addition with the row 
breaking), because I am not confident in sending this character to Qt 
string rendering functions.


I'll propose something shortly.

JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 06/11/2016 à 13:25, Stephan Witt a écrit :

After doing some code analysis and thinking again I came to the conclusion
that my patch is not the best one. One shouldn’t handle U+2028 and U+2029
the same way. To treat LINE SEPARATOR as a new line is ok, IMO.
The PARAGRAPH SEPARATOR needs a different handling and makes more work.
First it shouldn’t go in as is when pasting text. Probably the LyX file
parser can handle the case when the LX file somehow contains a U+2029 already.


This patch is orthogonal to the other one. I am not sure that you want 
to do it in real paste (i.e. when pasting LyX text to LyX text), but 
rather in the insertStringAs(Lines/Paragraphs) methods, when the two 
unicode characters should be interpreted as needed.


Moreover I do not think it is interesting to add a new method in 
textutils.h for testing a single character. The convention we use now is 
like:

 static char_type const thin = 0x2009; // U+2009 THIN SPACE
directly at the place of the source where you use it.

JMarc

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 05.11.2016 um 21:25 schrieb Stephan Witt :
> 
> Am 05.11.2016 um 16:31 schrieb Jean-Marc Lasgouttes :
>> 
>> Le 05/11/2016 à 13:30, Jean-Marc Lasgouttes a écrit :
>>> OK, I can reproduce it now. The problem is with characters
>>> LINE SEPARATOR (U+2028)
>>> PARAGRAPH SEPARATOR (U+2029)
>>> 
>>> Since they break line/character in string display, we get "interesting"
>>> consequences when trying to move cursor. It should not be difficult to
>>> avoid the crash, but the result will not be satisfactory. I see two
>>> possibilities:
>>> 
>>> 1/ replace them with proper line-break or paragraph-break on import
>>> from Unicode text. This is not 100% fail-safe, but it be easy and
>>> help in many cases.
>>> 
>>> 2/ keep them but interpret them as space everywhere for display. This
>>> will not give the same as PDF output, I guess
>>> 
>>> 3/ find a way to replace them with proper line/paragraph breaks in our
>>> document seamlessly. This seems a bit difficult to achieve, actually.
>> 
>> Or;
>> 
>> 4/ catch the characters at the level of the row breaking algorithm 
>> (TextMetrics::breakRow). This should be pretty straightforward to do.
>> 
>> JMarc
>> 
> 
> Yes, this would be the best solution. It seems so easy that I tried to
> come up with a patch myself. See attached. It works for this problem -
> I don’t know if its covers all possible code paths, though.

After doing some code analysis and thinking again I came to the conclusion
that my patch is not the best one. One shouldn’t handle U+2028 and U+2029
the same way. To treat LINE SEPARATOR as a new line is ok, IMO.
The PARAGRAPH SEPARATOR needs a different handling and makes more work.
First it shouldn’t go in as is when pasting text. Probably the LyX file
parser can handle the case when the LX file somehow contains a U+2029 already.

What do you think? Is it possible to test for U+2029 this way? 

I attach the updated patch without the file parser change. I didn’t do this yet.

Stephan


lineForTextPosition-4-crash.patch
Description: Binary data

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 05/11/2016 à 13:30, Jean-Marc Lasgouttes a écrit :

OK, I can reproduce it now. The problem is with characters
  LINE SEPARATOR (U+2028)
  PARAGRAPH SEPARATOR (U+2029)

Since they break line/character in string display, we get "interesting"
consequences when trying to move cursor. It should not be difficult to
avoid the crash, but the result will not be satisfactory. I see two
possibilities:

1/ replace them with proper line-break or paragraph-break on import
  from Unicode text. This is not 100% fail-safe, but it be easy and
  help in many cases.

2/ keep them but interpret them as space everywhere for display. This
  will not give the same as PDF output, I guess

3/ find a way to replace them with proper line/paragraph breaks in our
  document seamlessly. This seems a bit difficult to achieve, actually.


Or;

4/ catch the characters at the level of the row breaking algorithm 
(TextMetrics::breakRow). This should be pretty straightforward to do.


JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 04/11/2016 à 21:08, Stephan Witt a écrit :

I tried to preview the example file Maksim sent to the list (I’ll attach it 
again).
Without the patch the crash happens when LyX is trying to highlight the error
location in the document - the line containing the offending illegal character 
\u2028.


OK, I can reproduce it now. The problem is with characters
  LINE SEPARATOR (U+2028)
  PARAGRAPH SEPARATOR (U+2029)

Since they break line/character in string display, we get "interesting" 
consequences when trying to move cursor. It should not be difficult to 
avoid the crash, but the result will not be satisfactory. I see two 
possibilities:


1/ replace them with proper line-break or paragraph-break on import
  from Unicode text. This is not 100% fail-safe, but it be easy and
  help in many cases.

2/ keep them but interpret them as space everywhere for display. This
  will not give the same as PDF output, I guess

3/ find a way to replace them with proper line/paragraph breaks in our
  document seamlessly. This seems a bit difficult to achieve, actually.

What do you think? 1/ is easy but does not fix existing documents. And 
there are many other ways of adding these characters in a documents, 
actually.


I think it is tiime to open a bug report.

JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 04/11/2016 à 11:58, Stephan Witt a écrit :

JMarc, are you able to make sense of the following facts?


Could you try with the patch at http://www.lyx.org/trac/ticket/10443 ?


I’ve use git update instead and now I’m at 
d207e85cfda2893de4e6c7f419c58aa342395f47.

But - no, the crash is not gone.


What do you have to do to obtain a crash? I just tried with Qt5.6, but 
nothing interesting happened.


Is this a Mac thing?

JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 04/11/2016 à 11:58, Stephan Witt a écrit :

I’ve use git update instead and now I’m at 
d207e85cfda2893de4e6c7f419c58aa342395f47.

But - no, the crash is not gone.

I’ve attached a slightly improved version of my patch.
Obviously, this is a work-around only, I know.


I guess it is Qt5 only, since I cannot reproduce it with my build here. 
I'll try with Qt5.


JMarc

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 04.11.2016 um 10:48 schrieb Jean-Marc Lasgouttes :
> 
> Le 03/11/2016 à 22:06, Stephan Witt a écrit :
>> Hi Maksim,
>> 
>> thank you for sending the example. I can reproduce the crash in the debugger 
>> with LyX 2.3.x master.
>> 
>> JMarc, are you able to make sense of the following facts?
> 
> Could you try with the patch at http://www.lyx.org/trac/ticket/10443 ?

I’ve use git update instead and now I’m at 
d207e85cfda2893de4e6c7f419c58aa342395f47.

But - no, the crash is not gone.

I’ve attached a slightly improved version of my patch.
Obviously, this is a work-around only, I know.

Stephan



lineForTextPosition-2-crash.patch
Description: Binary data

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 03/11/2016 à 22:06, Stephan Witt a écrit :

Hi Maksim,

thank you for sending the example. I can reproduce the crash in the debugger 
with LyX 2.3.x master.

JMarc, are you able to make sense of the following facts?


Could you try with the patch at http://www.lyx.org/trac/ticket/10443 ?

JMarc

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 01.11.2016 um 18:04 schrieb Maksim Isakin :
> 
> 
> Hi Stephan,
> 
> Thanks for your response. The document is attached.
> 
> Maksim.
> 
> 

Hi Maksim,

thank you for sending the example. I can reproduce the crash in the debugger 
with LyX 2.3.x master.

JMarc, are you able to make sense of the following facts?
 
In GuiFontMetrics::pos2x (frame #2) below (full stack attached) the result of 
the QTextLayout lineForTextPosition(pos) is a invalid QTextLine.

The parameters are:

(lldb) print pos
(const int) $1 = 41
(lldb) print s
(lyx::docstring) $2 = L"Long and short forward positions on the \U2028S 
500 index“
(lldb) print s[40]
(std::__1::basic_string::value_type) $3 = L'\U2028'
(lldb) print tl.lineForTextPosition(pos)
(QTextLine) $0 = (index = 0, eng = 0x)

It looks like the special character at s[40] causes QTextLayout to return no 
valid QTextLine.

What would the best strategy to avoid the crash? The attached patch avoids the 
crash and the error message popup appears.

Stephan

Stack Trace is:

(lldb) bt
* thread #1: tid = 0x2a2cb3, 0x000102c5ca03 
QtGui`QTextLine::cursorToX(int*, QTextLine::Edge) const + 51, queue = 
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000102c5ca03 QtGui`QTextLine::cursorToX(int*, 
QTextLine::Edge) const + 51
frame #1: 0x000100d1c385 
LyX`QTextLine::cursorToX(this=0x7fff5fbfab68, cursorPos=41, edge=Leading) 
const + 37 at qtextlayout.h:235
frame #2: 0x000100d1ae2c 
LyX`lyx::frontend::GuiFontMetrics::pos2x(this=0x000155783f20, s=L"Long and 
short forward positions on the \U2028S 500 index", pos=41, rtl=false, 
wordspacing=0) const + 172 at GuiFontMetrics.cpp:209
frame #3: 0x000100544521 
LyX`lyx::Row::Element::pos2x(this=0x00015293e5c0, i=41) const + 385 at 
Row.cpp:75
frame #4: 0x00010061f3e9 
LyX`lyx::TextMetrics::findRowElement(this=0x000159549f08, 
row=0x00015952c720, pos=41, boundary=true, x=0x7fff5fbfad80) const + 
617 at TextMetrics.cpp:1497
frame #5: 0x00010061f5f5 
LyX`lyx::TextMetrics::cursorX(this=0x000159549f08, sl=0x000155790ee0, 
boundary=true) const + 277 at TextMetrics.cpp:1522
frame #6: 0x0001001d32f9 
LyX`lyx::BufferView::coordOffset(this=0x000155791150, 
dit=0x000104a7c698) const + 1449 at BufferView.cpp:2853
frame #7: 0x0001001d2ae4 
LyX`lyx::BufferView::scrollToCursor(this=0x000155791150, 
dit=0x000104a7c698, recenter=false) + 1668 at BufferView.cpp:955
frame #8: 0x0001001d0fb9 
LyX`lyx::BufferView::showCursor(this=0x000155791150, 
dit=0x000104a7c698, recenter=false, update=true) + 73 at BufferView.cpp:866
frame #9: 0x0001001cefd9 
LyX`lyx::BufferView::showCursor(this=0x000155791150) + 41 at 
BufferView.cpp:859
frame #10: 0x0001001cef9b 
LyX`lyx::BufferView::processUpdateFlags(this=0x000155791150, flags=3) + 731 
at BufferView.cpp:503



lineForTextPosition-crash.patch
Description: Binary data


lineForTextPosition-crash.stack
Description: Binary data

Re: pasted non-acceptable symbol

[racoon]

On 01.11.2016 19:37, Maksim Isakin wrote:
>> On Nov 1, 2016, at 2:27 PM, racoon > > wrote:
>>
>> On 01.11.2016 18:04, Maksim Isakin wrote:
>>> Thanks for your response. The document is attached.
>>
>> Hi Maksim,
>>
>> The problem seems to be a number of LS (line separator?) characters. I
>> opened your file with Notepad++ which made them visible. Then did a
>> search and replace and the error was gone.
>>
>> I guess it would be good if LyX would see those symbols and transform
>> them into something that works?
>
> Daniel,
>
> I am not sure what would be the best solution. Perhaps, a reasonable
> thing to do is to filter out the characters that cause problems at the
> moment when one pastes the text from buffer.

Sounds plausible. I am not sure how to to such things but I hope someone 
who knows reads this.


Here is your file back with LS characters removed, so you can try it out.

Daniel


Lecture6.lyx
Description: application/lyx

Re: pasted non-acceptable symbol

[racoon]

On 01.11.2016 18:04, Maksim Isakin wrote:

Thanks for your response. The document is attached.


Hi Maksim,

The problem seems to be a number of LS (line separator?) characters. I 
opened your file with Notepad++ which made them visible. Then did a 
search and replace and the error was gone.


I guess it would be good if LyX would see those symbols and transform 
them into something that works?


Daniel

Re: pasted non-acceptable symbol

[Maksim Isakin]

Hi Stephan,

Thanks for your response. The document is attached.

Maksim.
 


Lecture6.lyx
Description: Binary data


> On Oct 31, 2016, at 9:05 PM, Stephan Witt  wrote:
> 
> Am 31.10.2016 um 18:13 schrieb Maksim Isakin :
>> 
>> Hello,
>> 
>> There is a bug arising from a non-acceptable symbol (the text is copy-pasted 
>> from another document). I cannot find the symbol because it is not 
>> displayed. I couldn’t find an option to filter these symbols out either. The 
>> report is below.
>> 
>> Thanks,
>> Maksim Isakin
> 
> Hello Maksim,
> 
> the call stack is not helpful. Can you send us the document to trigger the 
> crash?
> 
> Thank you,
> Stephan
> 
>> 
>> 
>> 
>> ( 1) 1 lyx 0x000105aac141 
>> _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  : 1 lyx 0x000105aac141 
>> _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  + 138
>> ( 2) 2 lyx 0x000105aac6c2 
>> _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  : 2 lyx 0x000105aac6c2 
>> _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  + 149
>> ( 3) 3 lyx 0x000105844806 _ZN3lyx13error_handlerEi : 3 lyx 
>> 0x000105844806 _ZN3lyx13error_handlerEi + 506
>> ( 4) 4 libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp : 4 
>> libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp + 26
>> ( 5) 5 ??? 0x7fff5a4cae80 0x0 : 5 ??? 0x7fff5a4cae80 0x0 + 
>> 140734708362880
>> ( 6) 6 lyx 0x000105b7008b 
>> _ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
>>  : 6 lyx 0x000105b7008b 
>> _ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
>>  + 153
>> ( 7) 7 lyx 0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl : 7 lyx 
>> 0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl + 226
>> ( 8) 8 lyx 0x0001058eb81b 
>> _ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd : 8 lyx 
>> 0x0001058eb81b _ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd + 235
>> ( 9) 9 lyx 0x0001058eb8de 
>> _ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb : 9 lyx 
>> 0x0001058eb8de _ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb + 152
>> ( 10) 10 lyx 0x0001057a2a5a 
>> _ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE : 10 lyx 
>> 0x0001057a2a5a _ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE + 
>> 682
>> ( 11) 11 lyx 0x00010579fd79 
>> _ZNK3lyx10BufferView6getPosERKNS_11DocIteratorE : 11 lyx 0x00010579fd79 
>> _ZNK3lyx10BufferView6getPosERKNS_11DocIteratorE + 77
>> ( 12) 12 lyx 0x0001057acf73 
>> _ZN3lyx10BufferView23checkCursorScrollOffsetERNS_11PainterInfoE : 12 lyx 
>> 0x0001057acf73 
>> _ZN3lyx10BufferView23checkCursorScrollOffsetERNS_11PainterInfoE + 343
>> ( 13) 13 lyx 0x0001057ad210 
>> _ZN3lyx10BufferView4drawERNS_8frontend7PainterE : 13 lyx 0x0001057ad210 
>> _ZN3lyx10BufferView4drawERNS_8frontend7PainterE + 248
>> ( 14) 14 lyx 0x000105c6ffd6 
>> _ZN3lyx8frontend11GuiWorkArea7Private12updateScreenEv : 14 lyx 
>> 0x000105c6ffd6 _ZN3lyx8frontend11GuiWorkArea7Private12updateScreenEv + 76
>> ( 15) 15 lyx 0x000105c6fed9 _ZN3lyx8frontend11GuiWorkArea6redrawEb : 15 
>> lyx 0x000105c6fed9 _ZN3lyx8frontend11GuiWorkArea6redrawEb + 275
>> ( 16) 16 lyx 0x000105a8e933 
>> _ZN3lyx8frontend15WorkAreaManager9redrawAllEb : 16 lyx 0x000105a8e933 
>> _ZN3lyx8frontend15WorkAreaManager9redrawAllEb + 39
>> ( 17) 17 lyx 0x00010579ff41 
>> _ZN3lyx10BufferView18processUpdateFlagsENS_6Update5flagsE : 17 lyx 
>> 0x00010579ff41 _ZN3lyx10BufferView18processUpdateFlagsENS_6Update5flagsE 
>> + 385
>> ( 18) 18 lyx 0x000105b5dd42 _ZN3lyx8frontend12GuiErrorList4goToEi : 18 
>> lyx 0x000105b5dd42 _ZN3lyx8frontend12GuiErrorList4goToEi + 802
>> ( 19) 19 lyx 0x000105b5d750 _ZN3lyx8frontend12GuiErrorList6selectEv : 19 
>> lyx 0x000105b5d750 _ZN3lyx8frontend12GuiErrorList6selectEv + 64
>> ( 20) 20 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv 
>> : 20 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv + 
>> 3020
>> ( 21) 21 QtWidgets 0x000107413326 
>> _ZN18QListWidgetPrivate25_q_emitCurrentItemChangedERK11QModelIndexS2_ : 21 
>> QtWidgets 0x000107413326 
>> _ZN18QListWidgetPrivate25_q_emitCurrentItemChangedERK11QModelIndexS2_ + 454
>> ( 22) 22 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv 
>> : 22 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv + 
>> 3020
>> ( 23) 23 QtCore 0x000106c1a1e4 
>> _ZN19QItemSelectionModel15setCurrentIndexERK11QModelIndex6QFlagsINS_13SelectionFlagEE
>>  : 23 QtCore 0x000106c1a1e4 
>> _ZN19QItemSelectionModel15setCurrentIndexERK11QModelIndex6QFlagsINS_13SelectionFlagEE
>>  + 260
>> ( 24) 24 

Re: pasted non-acceptable symbol

[Paul Johnson]

Hi Stephan:

You are right. These are hard to find. I have been in this several
times in last semester.  I'm eager to see what the LyX developers say,
but here are tricks I've learned.

I bet one Euro we are talking either about "smart quotes" (angled " or
') . This happens  a lot if I copy out of StackOverflow or similar.
Even if you paste out of a valid LaTeX document into the Web, same
material cannot come back to LaTeX. If you paste slanted quotes into a
listings environment, you usually have invisible characters along with
compiler errors that don't clear it up too much. It may not be
apparent inside LyX. Open the LyX file in Emacs and maybe you can see.

One way I have found to solve this is to place big chunks of the
document into LyX Note and  compile. then add pieces back till the
compile fails. If you think of it like a binary search tree, it can go
pretty fast.

Another workaround is to reconsider encoding. On my Ubuntu systems,
LyX default uses latin9 encoding. I suggest changing that to UTF-8 in
the input encoding panel under document settings. That may make the
problem solve itself because unknown characters become known. If not
fixed, then after that, export the document as tex(pdflatex) and open
it in TexMaker or similar.

If you pasted in a non-printing character like UEFF, then compiler
errors will be more informative if you change input encoding to UTF-8

If you open the LyX file in Emacs, and then set the buffer file
encodings scheme to UTF-8, then save. There's a key combination, but I
forget. I just do M-x set-buffer-file-coding-system and type "utf-8".
I just had a bit of a shock because on a brand new Ubuntu system,
emacs thinks my default buffer file coding is "iso-latin-1" which I've
never seen before.

A student here had this problem last month. We tested some Unix file
encoding tools. iconv or recode will work on the lyx file.  Here are
the notes I wrote down.

This will report on file current encoding

$ file -bi  whatever.lyx

That may hint you in the right direction of what you have now.

#http://unix.stackexchange.com/questions/10241/how-can-i-make-iconv-replace-the-input-file-with-the-converted-output
for i in * ; do iconv $i -f CP1252 -t "utf8" > $i; done

## 
http://stackoverflow.com/questions/7297888/ufeff-character-showing-up-in-files-how-to-remove-them

## perl -pi~ -CSD -e 's/^\x{fffe}//' file1.js path/to/file2.js

Sorry these notes are not more clear. I don't know what I did...


On Mon, Oct 31, 2016 at 8:05 PM, Stephan Witt  wrote:
> Am 31.10.2016 um 18:13 schrieb Maksim Isakin :
>>
>> Hello,
>>
>> There is a bug arising from a non-acceptable symbol (the text is copy-pasted 
>> from another document). I cannot find the symbol because it is not 
>> displayed. I couldn’t find an option to filter these symbols out either. The 
>> report is below.
>>
>> Thanks,
>> Maksim Isakin
>
> Hello Maksim,
>
> the call stack is not helpful. Can you send us the document to trigger the 
> crash?
>
> Thank you,
> Stephan
>
>>
>>
>>
>> ( 1) 1 lyx 0x000105aac141 
>> _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  : 1 lyx 0x000105aac141 
>> _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  + 138
>> ( 2) 2 lyx 0x000105aac6c2 
>> _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  : 2 lyx 0x000105aac6c2 
>> _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>>  + 149
>> ( 3) 3 lyx 0x000105844806 _ZN3lyx13error_handlerEi : 3 lyx 
>> 0x000105844806 _ZN3lyx13error_handlerEi + 506
>> ( 4) 4 libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp : 4 
>> libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp + 26
>> ( 5) 5 ??? 0x7fff5a4cae80 0x0 : 5 ??? 0x7fff5a4cae80 0x0 + 
>> 140734708362880
>> ( 6) 6 lyx 0x000105b7008b 
>> _ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
>>  : 6 lyx 0x000105b7008b 
>> _ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
>>  + 153
>> ( 7) 7 lyx 0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl : 7 lyx 
>> 0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl + 226
>> ( 8) 8 lyx 0x0001058eb81b 
>> _ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd : 8 lyx 
>> 0x0001058eb81b _ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd + 235
>> ( 9) 9 lyx 0x0001058eb8de 
>> _ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb : 9 lyx 
>> 0x0001058eb8de _ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb + 152
>> ( 10) 10 lyx 0x0001057a2a5a 
>> _ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE : 10 lyx 
>> 0x0001057a2a5a _ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE + 
>> 682
>> ( 11) 11 lyx 0x00010579fd79 
>> 

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 31.10.2016 um 18:13 schrieb Maksim Isakin :
> 
> Hello,
> 
> There is a bug arising from a non-acceptable symbol (the text is copy-pasted 
> from another document). I cannot find the symbol because it is not displayed. 
> I couldn’t find an option to filter these symbols out either. The report is 
> below.
> 
> Thanks,
> Maksim Isakin

Hello Maksim,

the call stack is not helpful. Can you send us the document to trigger the 
crash?

Thank you,
Stephan

> 
> 
> 
> ( 1) 1 lyx 0x000105aac141 
> _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>  : 1 lyx 0x000105aac141 
> _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>  + 138
> ( 2) 2 lyx 0x000105aac6c2 
> _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>  : 2 lyx 0x000105aac6c2 
> _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
>  + 149
> ( 3) 3 lyx 0x000105844806 _ZN3lyx13error_handlerEi : 3 lyx 
> 0x000105844806 _ZN3lyx13error_handlerEi + 506
> ( 4) 4 libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp : 4 
> libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp + 26
> ( 5) 5 ??? 0x7fff5a4cae80 0x0 : 5 ??? 0x7fff5a4cae80 0x0 + 
> 140734708362880
> ( 6) 6 lyx 0x000105b7008b 
> _ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
>  : 6 lyx 0x000105b7008b 
> _ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
>  + 153
> ( 7) 7 lyx 0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl : 7 lyx 
> 0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl + 226
> ( 8) 8 lyx 0x0001058eb81b 
> _ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd : 8 lyx 
> 0x0001058eb81b _ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd + 235
> ( 9) 9 lyx 0x0001058eb8de 
> _ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb : 9 lyx 0x0001058eb8de 
> _ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb + 152
> ( 10) 10 lyx 0x0001057a2a5a 
> _ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE : 10 lyx 
> 0x0001057a2a5a _ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE + 682
> ( 11) 11 lyx 0x00010579fd79 
> _ZNK3lyx10BufferView6getPosERKNS_11DocIteratorE : 11 lyx 0x00010579fd79 
> _ZNK3lyx10BufferView6getPosERKNS_11DocIteratorE + 77
> ( 12) 12 lyx 0x0001057acf73 
> _ZN3lyx10BufferView23checkCursorScrollOffsetERNS_11PainterInfoE : 12 lyx 
> 0x0001057acf73 
> _ZN3lyx10BufferView23checkCursorScrollOffsetERNS_11PainterInfoE + 343
> ( 13) 13 lyx 0x0001057ad210 
> _ZN3lyx10BufferView4drawERNS_8frontend7PainterE : 13 lyx 0x0001057ad210 
> _ZN3lyx10BufferView4drawERNS_8frontend7PainterE + 248
> ( 14) 14 lyx 0x000105c6ffd6 
> _ZN3lyx8frontend11GuiWorkArea7Private12updateScreenEv : 14 lyx 
> 0x000105c6ffd6 _ZN3lyx8frontend11GuiWorkArea7Private12updateScreenEv + 76
> ( 15) 15 lyx 0x000105c6fed9 _ZN3lyx8frontend11GuiWorkArea6redrawEb : 15 
> lyx 0x000105c6fed9 _ZN3lyx8frontend11GuiWorkArea6redrawEb + 275
> ( 16) 16 lyx 0x000105a8e933 _ZN3lyx8frontend15WorkAreaManager9redrawAllEb 
> : 16 lyx 0x000105a8e933 _ZN3lyx8frontend15WorkAreaManager9redrawAllEb + 39
> ( 17) 17 lyx 0x00010579ff41 
> _ZN3lyx10BufferView18processUpdateFlagsENS_6Update5flagsE : 17 lyx 
> 0x00010579ff41 _ZN3lyx10BufferView18processUpdateFlagsENS_6Update5flagsE 
> + 385
> ( 18) 18 lyx 0x000105b5dd42 _ZN3lyx8frontend12GuiErrorList4goToEi : 18 
> lyx 0x000105b5dd42 _ZN3lyx8frontend12GuiErrorList4goToEi + 802
> ( 19) 19 lyx 0x000105b5d750 _ZN3lyx8frontend12GuiErrorList6selectEv : 19 
> lyx 0x000105b5d750 _ZN3lyx8frontend12GuiErrorList6selectEv + 64
> ( 20) 20 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv : 
> 20 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv + 3020
> ( 21) 21 QtWidgets 0x000107413326 
> _ZN18QListWidgetPrivate25_q_emitCurrentItemChangedERK11QModelIndexS2_ : 21 
> QtWidgets 0x000107413326 
> _ZN18QListWidgetPrivate25_q_emitCurrentItemChangedERK11QModelIndexS2_ + 454
> ( 22) 22 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv : 
> 22 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv + 3020
> ( 23) 23 QtCore 0x000106c1a1e4 
> _ZN19QItemSelectionModel15setCurrentIndexERK11QModelIndex6QFlagsINS_13SelectionFlagEE
>  : 23 QtCore 0x000106c1a1e4 
> _ZN19QItemSelectionModel15setCurrentIndexERK11QModelIndex6QFlagsINS_13SelectionFlagEE
>  + 260
> ( 24) 24 QtWidgets 0x000107413ad1 _ZN11QListWidget13setCurrentRowEi : 24 
> QtWidgets 0x000107413ad1 _ZN11QListWidget13setCurrentRowEi + 129
> ( 25) 25 lyx 0x000105b5d93e 
> _ZN3lyx8frontend12GuiErrorList14paramsToDialogEv : 25 lyx 0x000105b5d93e 
> _ZN3lyx8frontend12GuiErrorList14paramsToDialogEv + 320
> ( 

pasted non-acceptable symbol

[Maksim Isakin]

Hello,

There is a bug arising from a non-acceptable symbol (the text is copy-pasted 
from another document). I cannot find the symbol because it is not displayed. I 
couldn’t find an option to filter these symbols out either. The report is below.

Thanks,
Maksim Isakin



( 1) 1 lyx 0x000105aac141 
_ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
 : 1 lyx 0x000105aac141 
_ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
 + 138
( 2) 2 lyx 0x000105aac6c2 
_ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
 : 2 lyx 0x000105aac6c2 
_ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
 + 149
( 3) 3 lyx 0x000105844806 _ZN3lyx13error_handlerEi : 3 lyx 
0x000105844806 _ZN3lyx13error_handlerEi + 506
( 4) 4 libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp : 4 
libsystem_platform.dylib 0x7fff9cdaf52a _sigtramp + 26
( 5) 5 ??? 0x7fff5a4cae80 0x0 : 5 ??? 0x7fff5a4cae80 0x0 + 
140734708362880
( 6) 6 lyx 0x000105b7008b 
_ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
 : 6 lyx 0x000105b7008b 
_ZNK3lyx8frontend14GuiFontMetrics5pos2xERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwibd
 + 153
( 7) 7 lyx 0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl : 7 lyx 
0x0001058a1e56 _ZNK3lyx3Row7Element5pos2xEl + 226
( 8) 8 lyx 0x0001058eb81b 
_ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd : 8 lyx 0x0001058eb81b 
_ZNK3lyx11TextMetrics14findRowElementERKNS_3RowElbRd + 235
( 9) 9 lyx 0x0001058eb8de 
_ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb : 9 lyx 0x0001058eb8de 
_ZNK3lyx11TextMetrics7cursorXERKNS_11CursorSliceEb + 152
( 10) 10 lyx 0x0001057a2a5a 
_ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE : 10 lyx 
0x0001057a2a5a _ZNK3lyx10BufferView11coordOffsetERKNS_11DocIteratorE + 682
( 11) 11 lyx 0x00010579fd79 _ZNK3lyx10BufferView6getPosERKNS_11DocIteratorE 
: 11 lyx 0x00010579fd79 _ZNK3lyx10BufferView6getPosERKNS_11DocIteratorE + 77
( 12) 12 lyx 0x0001057acf73 
_ZN3lyx10BufferView23checkCursorScrollOffsetERNS_11PainterInfoE : 12 lyx 
0x0001057acf73 
_ZN3lyx10BufferView23checkCursorScrollOffsetERNS_11PainterInfoE + 343
( 13) 13 lyx 0x0001057ad210 _ZN3lyx10BufferView4drawERNS_8frontend7PainterE 
: 13 lyx 0x0001057ad210 _ZN3lyx10BufferView4drawERNS_8frontend7PainterE + 
248
( 14) 14 lyx 0x000105c6ffd6 
_ZN3lyx8frontend11GuiWorkArea7Private12updateScreenEv : 14 lyx 
0x000105c6ffd6 _ZN3lyx8frontend11GuiWorkArea7Private12updateScreenEv + 76
( 15) 15 lyx 0x000105c6fed9 _ZN3lyx8frontend11GuiWorkArea6redrawEb : 15 lyx 
0x000105c6fed9 _ZN3lyx8frontend11GuiWorkArea6redrawEb + 275
( 16) 16 lyx 0x000105a8e933 _ZN3lyx8frontend15WorkAreaManager9redrawAllEb : 
16 lyx 0x000105a8e933 _ZN3lyx8frontend15WorkAreaManager9redrawAllEb + 39
( 17) 17 lyx 0x00010579ff41 
_ZN3lyx10BufferView18processUpdateFlagsENS_6Update5flagsE : 17 lyx 
0x00010579ff41 _ZN3lyx10BufferView18processUpdateFlagsENS_6Update5flagsE + 
385
( 18) 18 lyx 0x000105b5dd42 _ZN3lyx8frontend12GuiErrorList4goToEi : 18 lyx 
0x000105b5dd42 _ZN3lyx8frontend12GuiErrorList4goToEi + 802
( 19) 19 lyx 0x000105b5d750 _ZN3lyx8frontend12GuiErrorList6selectEv : 19 
lyx 0x000105b5d750 _ZN3lyx8frontend12GuiErrorList6selectEv + 64
( 20) 20 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv : 
20 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv + 3020
( 21) 21 QtWidgets 0x000107413326 
_ZN18QListWidgetPrivate25_q_emitCurrentItemChangedERK11QModelIndexS2_ : 21 
QtWidgets 0x000107413326 
_ZN18QListWidgetPrivate25_q_emitCurrentItemChangedERK11QModelIndexS2_ + 454
( 22) 22 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv : 
22 QtCore 0x000106c95b4c _ZN11QMetaObject8activateEP7QObjectiiPPv + 3020
( 23) 23 QtCore 0x000106c1a1e4 
_ZN19QItemSelectionModel15setCurrentIndexERK11QModelIndex6QFlagsINS_13SelectionFlagEE
 : 23 QtCore 0x000106c1a1e4 
_ZN19QItemSelectionModel15setCurrentIndexERK11QModelIndex6QFlagsINS_13SelectionFlagEE
 + 260
( 24) 24 QtWidgets 0x000107413ad1 _ZN11QListWidget13setCurrentRowEi : 24 
QtWidgets 0x000107413ad1 _ZN11QListWidget13setCurrentRowEi + 129
( 25) 25 lyx 0x000105b5d93e 
_ZN3lyx8frontend12GuiErrorList14paramsToDialogEv : 25 lyx 0x000105b5d93e 
_ZN3lyx8frontend12GuiErrorList14paramsToDialogEv + 320
( 26) 26 lyx 0x000105b5e35f 
_ZN3lyx8frontend12GuiErrorList16initialiseParamsERKNSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIc
 : 26 lyx 0x000105b5e35f 
_ZN3lyx8frontend12GuiErrorList16initialiseParamsERKNSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIc
 + 831
( 27) 27 lyx 0x000105b5e419