Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 14/10/2011 03:17, Uwe Stöhr a écrit :

I cannot parse what you mean. You are certainly not indicating that
any LaTeX list, like itemize or
enumerate environment, are designed with free spacing in mind, are you?



You misunderstood me. The LaTeX list allows to use multiple spaces. The
other lists are indeed derived from the basic LaTeX list but forbid this.


Can you point me to a document that support this claim? I find it hard 
to believe (or I still misunderstand you). In latex, nothing supports 
multiple spaces unless explicitly coded (eg verbatim).



I am not against this, but this will be a change for existing
documents. Some people are actually
happy that the lines do not break and go through the right margin...


But this doesn't make sense: You can't print it and also not publish
this. So I doubt that people do this purposely.


Do you really mean that you never saw people who do not care that their 
listing protrudes by 5mm outside of the right margin and would be 
annoyed to have a word alone on a line for correctness' sake?



Heiko Oberdiek told me that this would have drawbacks as this change
take place globally. (I didn't understand the TeX-internal details.)
Moreover it doesn't work for multiple spaces, see the attached file.


Do you have a lik to this discussion (I think you posted it already, but 
I lost it)? Maybe I can understand what he means.



It also doesn't solve the bug, because it is:
- when the user presses SPACE we insert a ~

As long as we don't change this, we can redefine whatever we want.


So my plan is to remove this special code that inserts explicit ~ and to 
upgrade our environments instead. THat would mean, with the following

arbitrary numbering
 0: no free spacing
 1: output space as ~
 2: output space as \ 
 3: output space as  
to ship with LyX only environments that use values 0 or 3, and keep 1 
and 2 for weird latex things we have no control on.



So why should we take risks and add some more definitions when there is
a clean solution that was recommended by LaTeX experts?


It is you who propose to take risks and change the way LyX-Code behaves 
wrt line breaks. I agree that the original choice was unfortunate, but 
we have to live with it. I would propose to keep LyX-Code with its 
broken semantics, but maybe move it to a module (that lyx2lyx would 
insert automatically as needed) and ship layouts supporting verbatim and 
alltt instead.



But lyxcode code _is_ standard. It correctly uses TeX's list environment
in exactly or the purpose why it is defined in TeX. The LaTeX gurus had
a look at our code and said it is correct.
We cannot use something else and this would also don't make sense.
Naturally spoken, we need a bus, not a car and not a lorry and we
already have this bus. We only need to change to change the arrangement
of its seats.


I wonder how the rest of the LaTeX community manges to produce documents 
without our very special environment. They don't know what they are 
missing :)


What is wrong with verbatim or alltt, seriously? Or even more fancy 
verbatim alternatives? What it the unique feature of LyX-Code that makes 
its existence worth it?


With LyX-Code, we reinvented a new wheel. The fact that an expert 
testified that our wheel is round is not enough to warrant using it.
Using standard environment means that tex-html or tex-odt fileter can 
understand our files. Is this worth nothing to you?


JMarc

JMarc

Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 14/10/2011 03:17, Uwe Stöhr a écrit :

I cannot parse what you mean. You are certainly not indicating that
any LaTeX list, like itemize or
enumerate environment, are designed with free spacing in mind, are you?



You misunderstood me. The LaTeX list allows to use multiple spaces. The
other lists are indeed derived from the basic LaTeX list but forbid this.


Can you point me to a document that support this claim? I find it hard 
to believe (or I still misunderstand you). In latex, nothing supports 
multiple spaces unless explicitly coded (eg verbatim).



I am not against this, but this will be a change for existing
documents. Some people are actually
happy that the lines do not break and go through the right margin...


But this doesn't make sense: You can't print it and also not publish
this. So I doubt that people do this purposely.


Do you really mean that you never saw people who do not care that their 
listing protrudes by 5mm outside of the right margin and would be 
annoyed to have a word alone on a line for correctness' sake?



Heiko Oberdiek told me that this would have drawbacks as this change
take place globally. (I didn't understand the TeX-internal details.)
Moreover it doesn't work for multiple spaces, see the attached file.


Do you have a lik to this discussion (I think you posted it already, but 
I lost it)? Maybe I can understand what he means.



It also doesn't solve the bug, because it is:
- when the user presses SPACE we insert a ~

As long as we don't change this, we can redefine whatever we want.


So my plan is to remove this special code that inserts explicit ~ and to 
upgrade our environments instead. THat would mean, with the following

arbitrary numbering
>> 0: no free spacing
>> 1: output space as "~"
>> 2: output space as "\ "
>> 3: output space as " "
to ship with LyX only environments that use values 0 or 3, and keep 1 
and 2 for weird latex things we have no control on.



So why should we take risks and add some more definitions when there is
a clean solution that was recommended by LaTeX experts?


It is you who propose to take risks and change the way LyX-Code behaves 
wrt line breaks. I agree that the original choice was unfortunate, but 
we have to live with it. I would propose to keep LyX-Code with its 
broken semantics, but maybe move it to a module (that lyx2lyx would 
insert automatically as needed) and ship layouts supporting verbatim and 
alltt instead.



But lyxcode code _is_ standard. It correctly uses TeX's list environment
in exactly or the purpose why it is defined in TeX. The LaTeX gurus had
a look at our code and said it is correct.
We cannot use something else and this would also don't make sense.
Naturally spoken, we need a bus, not a car and not a lorry and we
already have this bus. We only need to change to change the arrangement
of its seats.


I wonder how the rest of the LaTeX community manges to produce documents 
without our very special environment. They don't know what they are 
missing :)


What is wrong with verbatim or alltt, seriously? Or even more fancy 
verbatim alternatives? What it the unique feature of LyX-Code that makes 
its existence worth it?


With LyX-Code, we reinvented a new wheel. The fact that an expert 
testified that our wheel is round is not enough to warrant using it.
Using standard environment means that tex-html or tex-odt fileter can 
understand our files. Is this worth nothing to you?


JMarc

JMarc

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 12.09.2011 11:46, schrieb Jean-Marc Lasgouttes:


It allows free spacing, so that you can insert multiple spaces and LaTeX
will respect them. It moreover allows to format your text in the way you
like - like in our case typewriter.


I cannot parse what you mean. You are certainly not indicating that any LaTeX 
list, like itemize or
enumerate environment, are designed with free spacing in mind, are you?


You misunderstood me. The LaTeX list allows to use multiple spaces. The other lists are indeed 
derived from the basic LaTeX list but forbid this.



I had a lengthy discussion about this topic with the LaTeX gurus and our
lyxcode definition is correct. The only bug is that we are using in any
case protected spaces instead of normal ones.


So to use latex 2.09 terminology as I understand it (I have only Lamport first 
edition at hand :),
the advice is to use interword space (\ ) instead of unbreakable space (~).


Yes and that is also what they told me and this indeed fixes the problem. So the solution is really 
that simple!



I am not against this, but this will be a change for existing documents. Some 
people are actually
happy that the lines do not break and go through the right margin...


But this doesn't make sense: You can't print it and also not publish this. So I doubt that people do 
this purposely.



So I do not think we can do the
change just like that. What I would propose is to keep LyX-Code as an obsolete 
solution and support
instead some more standard stuff like verbatim and alltt.


\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does
that ring a bell?


That is the opposite to what we want. We need normal spaces that don't
act as protected spaces.


You know that you can just read the code instead of just complaining. THe 
effect \obeyspace is that
the LaTeX code

\begin{lyxcode}
aa bb bb
\end{lyxcode}
would act just as your proposed
\begin{lyxcode}
aa\ \ bb\ \ bb
\end{lyxcode}
whereas current LyX code outputs
\begin{lyxcode}
aa~~bb~~bb
\end{lyxcode}

Are you telling me that you cannot see that it just makes more sense?


Heiko Oberdiek told me that this would have drawbacks as this change take place globally. (I didn't 
understand the TeX-internal details.) Moreover it doesn't work for multiple spaces, see the attached 
file.

It also doesn't solve the bug, because it is:

- when the user presses SPACE we insert a ~

As long as we don't change this, we can redefine whatever we want.

So why should we take risks and add some more definitions when there is a clean solution that was 
recommended by LaTeX experts?



Actually I would propose freespacing to take several values:

0: no free spacing
1: output space as ~
2: output space as \ 
3: output space as  


I propose to use our default spacing mechanism:

- if the user enters a SPACE, he gets a '\ '
- the the user inserts a protected space (Ctrl+SPACE) he gets a '~'

As you can see, all we have to do is to transform in free spacing mode in inserted space to '\ '. 
All other space types can also in free spacing mode used as usual, even \negmedspace, \qquad etc.



And additionally replace lyxcode with something standard.


But lyxcode code _is_ standard. It correctly uses TeX's list environment in exactly or the purpose 
why it is defined in TeX. The LaTeX gurus had a look at our code and said it is correct.
We cannot use something else and this would also don't make sense. Naturally spoken, we need a bus, 
not a car and not a lorry and we already have this bus. We only need to change to change the 
arrangement of its seats.


regards Uwe


obeyspace-test.lyx
Description: application/lyx

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 12.09.2011 11:46, schrieb Jean-Marc Lasgouttes:


It allows free spacing, so that you can insert multiple spaces and LaTeX
will respect them. It moreover allows to format your text in the way you
like - like in our case typewriter.


I cannot parse what you mean. You are certainly not indicating that any LaTeX 
list, like itemize or
enumerate environment, are designed with free spacing in mind, are you?


You misunderstood me. The LaTeX list allows to use multiple spaces. The other lists are indeed 
derived from the basic LaTeX list but forbid this.



I had a lengthy discussion about this topic with the LaTeX gurus and our
lyxcode definition is correct. The only bug is that we are using in any
case protected spaces instead of normal ones.


So to use latex 2.09 terminology as I understand it (I have only Lamport first 
edition at hand :),
the advice is to use interword space (\ ) instead of unbreakable space (~).


Yes and that is also what they told me and this indeed fixes the problem. So the solution is really 
that simple!



I am not against this, but this will be a change for existing documents. Some 
people are actually
happy that the lines do not break and go through the right margin...


But this doesn't make sense: You can't print it and also not publish this. So I doubt that people do 
this purposely.



So I do not think we can do the
change just like that. What I would propose is to keep LyX-Code as an obsolete 
solution and support
instead some more standard stuff like verbatim and alltt.


\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does
that ring a bell?


That is the opposite to what we want. We need normal spaces that don't
act as protected spaces.


You know that you can just read the code instead of just complaining. THe 
effect \obeyspace is that
the LaTeX code

\begin{lyxcode}
aa bb bb
\end{lyxcode}
would act just as your proposed
\begin{lyxcode}
aa\ \ bb\ \ bb
\end{lyxcode}
whereas current LyX code outputs
\begin{lyxcode}
aa~~bb~~bb
\end{lyxcode}

Are you telling me that you cannot see that it just makes more sense?


Heiko Oberdiek told me that this would have drawbacks as this change take place globally. (I didn't 
understand the TeX-internal details.) Moreover it doesn't work for multiple spaces, see the attached 
file.

It also doesn't solve the bug, because it is:

- when the user presses SPACE we insert a ~

As long as we don't change this, we can redefine whatever we want.

So why should we take risks and add some more definitions when there is a clean solution that was 
recommended by LaTeX experts?



Actually I would propose freespacing to take several values:

0: no free spacing
1: output space as "~"
2: output space as "\ "
3: output space as " "


I propose to use our default spacing mechanism:

- if the user enters a SPACE, he gets a '\ '
- the the user inserts a protected space (Ctrl+SPACE) he gets a '~'

As you can see, all we have to do is to transform in free spacing mode in inserted space to '\ '. 
All other space types can also in free spacing mode used as usual, even \negmedspace, \qquad etc.



And additionally replace lyxcode with something standard.


But lyxcode code _is_ standard. It correctly uses TeX's list environment in exactly or the purpose 
why it is defined in TeX. The LaTeX gurus had a look at our code and said it is correct.
We cannot use something else and this would also don't make sense. Naturally spoken, we need a bus, 
not a car and not a lorry and we already have this bus. We only need to change to change the 
arrangement of its seats.


regards Uwe


obeyspace-test.lyx
Description: application/lyx

Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 29/08/2011 15:40, Uwe Stöhr a écrit :

In which sense is the LaTeX list environment designed to show
typewriter code?


It allows free spacing, so that you can insert multiple spaces and LaTeX
will respect them. It moreover allows to format your text in the way you
like - like in our case typewriter.


I cannot parse what you mean. You are certainly not indicating that any 
LaTeX list, like itemize or enumerate environment, are designed with 
free spacing in mind, are you? To my knowledge, all the list does here 
is to help us setting margins and other spacing as we want it to be.



I had a lengthy discussion about this topic with the LaTeX gurus and our
lyxcode definition is correct. The only bug is that we are using in any
case protected spaces instead of normal ones.


So to use latex 2.09 terminology as I understand it (I have only Lamport 
first edition at hand :), the advice is to use interword space (\ ) 
instead of unbreakable space (~).


I am not against this, but this will be a change for existing documents. 
Some people are actually happy that the lines do not break and go 
through the right margin... So I do not think we can do the change just 
like that. What I would propose is to keep LyX-Code as an obsolete 
solution and support instead some more standard stuff like verbatim and 
alltt.



\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does
that ring a bell?


That is the opposite to what we want. We need normal spaces that don't
act as protected spaces.


You know that you can just read the code instead of just complaining. 
THe effect \obeyspace is that the LaTeX code


\begin{lyxcode}
aa  bb  bb
\end{lyxcode}
would act just as your proposed
\begin{lyxcode}
aa\ \ bb\ \ bb
\end{lyxcode}
whereas current LyX code outputs
\begin{lyxcode}
aa~~bb~~bb
\end{lyxcode}

Are you telling me that you cannot see that it just makes more sense?

Actually I would propose freespacing to take several values:

0: no free spacing
1: output space as ~
2: output space as \ 
3: output space as  

And additionally replace lyxcode with something standard.

JMarc

Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 29/08/2011 15:40, Uwe Stöhr a écrit :

In which sense is the LaTeX list environment designed to show
typewriter code?


It allows free spacing, so that you can insert multiple spaces and LaTeX
will respect them. It moreover allows to format your text in the way you
like - like in our case typewriter.


I cannot parse what you mean. You are certainly not indicating that any 
LaTeX list, like itemize or enumerate environment, are designed with 
free spacing in mind, are you? To my knowledge, all the list does here 
is to help us setting margins and other spacing as we want it to be.



I had a lengthy discussion about this topic with the LaTeX gurus and our
lyxcode definition is correct. The only bug is that we are using in any
case protected spaces instead of normal ones.


So to use latex 2.09 terminology as I understand it (I have only Lamport 
first edition at hand :), the advice is to use interword space (\ ) 
instead of unbreakable space (~).


I am not against this, but this will be a change for existing documents. 
Some people are actually happy that the lines do not break and go 
through the right margin... So I do not think we can do the change just 
like that. What I would propose is to keep LyX-Code as an obsolete 
solution and support instead some more standard stuff like verbatim and 
alltt.



\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does
that ring a bell?


That is the opposite to what we want. We need normal spaces that don't
act as protected spaces.


You know that you can just read the code instead of just complaining. 
THe effect \obeyspace is that the LaTeX code


\begin{lyxcode}
aa  bb  bb
\end{lyxcode}
would act just as your proposed
\begin{lyxcode}
aa\ \ bb\ \ bb
\end{lyxcode}
whereas current LyX code outputs
\begin{lyxcode}
aa~~bb~~bb
\end{lyxcode}

Are you telling me that you cannot see that it just makes more sense?

Actually I would propose freespacing to take several values:

0: no free spacing
1: output space as "~"
2: output space as "\ "
3: output space as " "

And additionally replace lyxcode with something standard.

JMarc

Re: [patch] Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 29.08.2011 20:22, schrieb Pavel Sanda:


you can call methods via class::method() only when they are static.
otherwise you need real existing object for that class to call
class_variable.method().

generally you need either the variable or to declare that method
to be static.


How can I do this? Sorry for this stupid question but I never learned C++. All I know is from 
looking at the LyX code. Therefore my skills in the header business are quite low.


thanks and regards
Uwe

Re: [patch] Re: About our bug in treating spaces from copied text

[Vincent van Ravesteijn]

Op 1-9-2011 16:22, Uwe Stöhr schreef:

Am 29.08.2011 20:22, schrieb Pavel Sanda:


you can call methods via class::method() only when they are static.
otherwise you need real existing object for that class to call
class_variable.method().

generally you need either the variable or to declare that method
to be static.


How can I do this? Sorry for this stupid question but I never learned 
C++. All I know is from looking at the LyX code. Therefore my skills 
in the header business are quite low.


You can declare it static by putting static in front of it. But you 
can never declare InsetSpace::latex static. It needs to know whether 
it's a protected space, or  maybe a horizontal fill or whatever. So you 
need an object, set these properties and then you can call latex for 
that object.


I guess what you need is:

InsetSpaceParams params;
params.kind = PROTECTED;
InsetSpace space(params);
space.latex(os, runparams);

or create a static function:

class InsetSpace {
...
static latexForKind(Kind kind, os, runparams);
...
}

and call

InsetSpace::latexForKind(PROTECTED, os, runparams);

Vincent

Re: [patch] Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 29.08.2011 20:22, schrieb Pavel Sanda:


you can call methods via class::method() only when they are static.
otherwise you need real existing object for that class to call
class_variable.method().

generally you need either the variable or to declare that method
to be static.


How can I do this? Sorry for this stupid question but I never learned C++. All I know is from 
looking at the LyX code. Therefore my skills in the header business are quite low.


thanks and regards
Uwe

Re: [patch] Re: About our bug in treating spaces from copied text

[Vincent van Ravesteijn]

Op 1-9-2011 16:22, Uwe Stöhr schreef:

Am 29.08.2011 20:22, schrieb Pavel Sanda:


you can call methods via class::method() only when they are static.
otherwise you need real existing object for that class to call
class_variable.method().

generally you need either the variable or to declare that method
to be static.


How can I do this? Sorry for this stupid question but I never learned 
C++. All I know is from looking at the LyX code. Therefore my skills 
in the header business are quite low.


You can declare it static by putting "static" in front of it. But you 
can never declare InsetSpace::latex static. It needs to know whether 
it's a protected space, or  maybe a horizontal fill or whatever. So you 
need an object, set these properties and then you can call latex for 
that object.


I guess what you need is:

InsetSpaceParams params;
params.kind = PROTECTED;
InsetSpace space(params);
space.latex(os, runparams);

or create a static function:

class InsetSpace {
...
static latexForKind(Kind kind, os, runparams);
...
}

and call

InsetSpace::latexForKind(PROTECTED, os, runparams);

Vincent

Re: About our bug in treating spaces from copied text

[Guenter Milde]

On 2011-08-27, Uwe Stöhr wrote:
 Am 23.08.2011 23:18, schrieb Jean-Marc Lasgouttes:

 Could we just use alltt or even verbatim instead?

 VFerbatim would not allow any formatting while list does. What is alltt?

alltt is an environment of the LaTeX standard package alltt. 
http://www.tug.org/texlive/devsrc/Master/texmf-dist/doc/latex/base/alltt.pdf

  This package defines the alltt environment, which is like the verbatim
  environment except that \, {, and } have their usual meanings. Thus,
  other commands and environments can appear within an alltt environment.

I.e. it is similar to the pre HTML tag.


 But the aim of lyxlist is to provide an environment where multiple
 spaces are output as such and not only as one single space.

If a monospaced font is intended, too, alltt seems the right choice.

Günter

Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 27/08/2011 04:58, Uwe Stöhr a écrit :

Am 23.08.2011 23:18, schrieb Jean-Marc Lasgouttes:


I think lyxcode is fundamentally flawed, but nobody dares fixing it :)


The code is correct - it uses LaTeX#s list environment which is designed
for this purpose.


In which sense is the LaTeX list environment designed to show typewriter 
code?



Another solution would be to use \obeyspace there and just remve the
freespace nonsense.


Free spacing is OK here and therefore also provided by LaTeX's list
environment.


Could you make this statement more precise? I see nothing relating list 
and free spacing. Did you even look up \obeyspace? I'll give you the 
definition from latex.ltx:


\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does 
that ring a bell?


JMarc

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 29.08.2011 12:01, schrieb Jean-Marc Lasgouttes:


In which sense is the LaTeX list environment designed to show typewriter code?


It allows free spacing, so that you can insert multiple spaces and LaTeX will respect them. It 
moreover allows to format your text in the way you like - like in our case typewriter.


I had a lengthy discussion about this topic with the LaTeX gurus and our lyxcode definition is 
correct. The only bug is that we are using in any case protected spaces instead of normal ones.



\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does that ring 
a bell?


That is the opposite to what we want. We need normal spaces that don't act as 
protected spaces.

regards Uwe

[patch] Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Attached is the right approach I think:

We need to insert normal spaces as such so pressing SPACE leads to \ , pressing Ctrl+Space leads 
to ~, inserting a visible space leads to \textvisiblespace. So we only need to call InsetSpace's 
latex void to do the job.
The attached patch does this but does not compile: Illegal call of non-static member function. 
What am I doing wrong here?


thanks and regards
Uwe
Index: insets/InsetSpace.cpp
===
--- insets/InsetSpace.cpp	(revision 39557)
+++ insets/InsetSpace.cpp	(working copy)
@@ -538,18 +538,18 @@
 {
 	switch (params_.kind) {
 	case InsetSpaceParams::NORMAL:
-		os  (runparams.free_spacing ?   : \\ );
+		os  \\ ;
 		break;
 	case InsetSpaceParams::PROTECTED:
 		if (runparams.local_font 
 		runparams.local_font-language()-lang() == polutonikogreek)
 			// in babel's polutonikogreek, ~ is active
-			os  (runparams.free_spacing ?   : \\nobreakspace{});
+			os  \\nobreakspace{};
 		else
-			os  (runparams.free_spacing ? ' ' : '~');
+			os  '~';
 		break;
 	case InsetSpaceParams::VISIBLE:
-		os  (runparams.free_spacing ?   : \\textvisiblespace{});
+		os  \\textvisiblespace{};
 		break;
 	case InsetSpaceParams::THIN:
 		os  (runparams.free_spacing ?   : \\,);
Index: Paragraph.cpp
===
--- Paragraph.cpp	(revision 39556)
+++ Paragraph.cpp	(working copy)
@@ -51,6 +51,7 @@
 
 #include insets/InsetBibitem.h
 #include insets/InsetLabel.h
+#include insets/InsetSpace.h
 #include insets/InsetSpecialChar.h
 
 #include support/debug.h
@@ -906,11 +907,13 @@
 		os  '\n';
 		os.texrow().start(owner_-id(), i + 1);
 		column = 0;
-	} else if (style.free_spacing) {
-		os  '~';
-	} else {
+	}
+	// we need to distunguish between normal space ('\ '), protected space ('~')
+	// and visible space (\textvisiblespace) see bug #4742
+	else if (style.free_spacing)
+		InsetSpace::latex(os, runparams);
+	else
 		os  ' ';
-	}
 	return false;
 }
 

Re: [patch] Re: About our bug in treating spaces from copied text

[Pavel Sanda]

Uwe Stöhr wrote:
 The attached patch does this but does not compile: Illegal call of 
 non-static member function. What am I doing wrong here?

you can call methods via class::method() only when they are static.
otherwise you need real existing object for that class to call
class_variable.method().

generally you need either the variable or to declare that method
to be static.

pavel

Re: About our bug in treating spaces from copied text

[Guenter Milde]

On 2011-08-27, Uwe Stöhr wrote:
> Am 23.08.2011 23:18, schrieb Jean-Marc Lasgouttes:

>> Could we just use alltt or even verbatim instead?

> VFerbatim would not allow any formatting while list does. What is alltt?

alltt is an environment of the LaTeX standard package alltt. 
http://www.tug.org/texlive/devsrc/Master/texmf-dist/doc/latex/base/alltt.pdf

  This package defines the alltt environment, which is like the verbatim
  environment except that \, {, and } have their usual meanings. Thus,
  other commands and environments can appear within an alltt environment.

I.e. it is similar to the  HTML tag.


> But the aim of lyxlist is to provide an environment where multiple
> spaces are output as such and not only as one single space.

If a monospaced font is intended, too, alltt seems the right choice.

Günter

Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 27/08/2011 04:58, Uwe Stöhr a écrit :

Am 23.08.2011 23:18, schrieb Jean-Marc Lasgouttes:


I think lyxcode is fundamentally flawed, but nobody dares fixing it :)


The code is correct - it uses LaTeX#s list environment which is designed
for this purpose.


In which sense is the LaTeX list environment designed to show typewriter 
code?



Another solution would be to use \obeyspace there and just remve the
freespace nonsense.


Free spacing is OK here and therefore also provided by LaTeX's list
environment.


Could you make this statement more precise? I see nothing relating list 
and free spacing. Did you even look up \obeyspace? I'll give you the 
definition from latex.ltx:


\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does 
that ring a bell?


JMarc

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 29.08.2011 12:01, schrieb Jean-Marc Lasgouttes:


In which sense is the LaTeX list environment designed to show typewriter code?


It allows free spacing, so that you can insert multiple spaces and LaTeX will respect them. It 
moreover allows to format your text in the way you like - like in our case typewriter.


I had a lengthy discussion about this topic with the LaTeX gurus and our lyxcode definition is 
correct. The only bug is that we are using in any case protected spaces instead of normal ones.



\def\obeyspaces{\catcode`\ \active}
{\obeyspaces\global\let =\space}

In a nutshell, it makes normal spaces act like protected spaces. Does that ring 
a bell?


That is the opposite to what we want. We need normal spaces that don't act as 
protected spaces.

regards Uwe

[patch] Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Attached is the right approach I think:

We need to insert normal spaces as such so pressing SPACE leads to "\ ", pressing Ctrl+Space leads 
to "~", inserting a visible space leads to "\textvisiblespace". So we only need to call InsetSpace's 
latex void to do the job.
The attached patch does this but does not compile: "Illegal call of non-static member function." 
What am I doing wrong here?


thanks and regards
Uwe
Index: insets/InsetSpace.cpp
===
--- insets/InsetSpace.cpp	(revision 39557)
+++ insets/InsetSpace.cpp	(working copy)
@@ -538,18 +538,18 @@
 {
 	switch (params_.kind) {
 	case InsetSpaceParams::NORMAL:
-		os << (runparams.free_spacing ? " " : "\\ ");
+		os << "\\ ";
 		break;
 	case InsetSpaceParams::PROTECTED:
 		if (runparams.local_font &&
 		runparams.local_font->language()->lang() == "polutonikogreek")
 			// in babel's polutonikogreek, ~ is active
-			os << (runparams.free_spacing ? " " : "\\nobreakspace{}");
+			os << "\\nobreakspace{}";
 		else
-			os << (runparams.free_spacing ? ' ' : '~');
+			os << '~';
 		break;
 	case InsetSpaceParams::VISIBLE:
-		os << (runparams.free_spacing ? " " : "\\textvisiblespace{}");
+		os << "\\textvisiblespace{}";
 		break;
 	case InsetSpaceParams::THIN:
 		os << (runparams.free_spacing ? " " : "\\,");
Index: Paragraph.cpp
===
--- Paragraph.cpp	(revision 39556)
+++ Paragraph.cpp	(working copy)
@@ -51,6 +51,7 @@
 
 #include "insets/InsetBibitem.h"
 #include "insets/InsetLabel.h"
+#include "insets/InsetSpace.h"
 #include "insets/InsetSpecialChar.h"
 
 #include "support/debug.h"
@@ -906,11 +907,13 @@
 		os << '\n';
 		os.texrow().start(owner_->id(), i + 1);
 		column = 0;
-	} else if (style.free_spacing) {
-		os << '~';
-	} else {
+	}
+	// we need to distunguish between normal space ('\ '), protected space ('~')
+	// and visible space ("\textvisiblespace") see bug #4742
+	else if (style.free_spacing)
+		InsetSpace::latex(os, runparams);
+	else
 		os << ' ';
-	}
 	return false;
 }
 

Re: [patch] Re: About our bug in treating spaces from copied text

[Pavel Sanda]

Uwe Stöhr wrote:
> The attached patch does this but does not compile: "Illegal call of 
> non-static member function." What am I doing wrong here?

you can call methods via class::method() only when they are static.
otherwise you need real existing object for that class to call
class_variable.method().

generally you need either the variable or to declare that method
to be static.

pavel

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 15.08.2011 10:08, schrieb Vincent van Ravesteijn:


+// tabulators and outputting a single space instead is not what we
+// want in FreeSpacing mode
+par.insert(pos, from_ascii(), font, Change(bparams.trackChanges
?
+Change::INSERTED : Change::UNCHANGED));
+pos = pos + 4;
  space_inserted = true;
 }


I don't understand this. About which freespacing environments are we
talking. InsetListings for example can handle tabulators without problem, so
in that case it would be wrong to convert to four spaces. In ERT it's the
user's own responsibility not to use tabulators.


You are right, this change only needs to be done for lyxlist. For all other cases where free spacing 
is allowed, this is not necessary.
I assume that it is impossible the access the info if the pasted text goes into a lyxlist or not, or 
is this possible? if the latter, how?


thanks and regards
Uwe

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 23.08.2011 23:18, schrieb Jean-Marc Lasgouttes:


I think lyxcode is fundamentally flawed, but nobody dares fixing it :)


The code is correct - it uses LaTeX#s list environment which is designed for 
this purpose.


Could we just use alltt or even verbatim instead?


VFerbatim would not allow any formatting while list does. What is alltt?


Another solution would be to use \obeyspace there and just remve the freespace 
nonsense.


Free spacing is OK here and therefore also provided by LaTeX's list environment. The only issue is 
that we are currentl using in any case non-breakable spaces and that is what my patch fixes.



This is
more work, but a better result. For this we could have to create a new value 
freespacing=2 that
means allow mutiple spaces, but output them as normal spaces.


But the aim of lyxlist is to provide an environment where multiple spaces are output as such and not 
only as one single space.


regards Uwe

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 15.08.2011 10:08, schrieb Vincent van Ravesteijn:


+// tabulators and outputting a single space instead is not what we
+// want in FreeSpacing mode
+par.insert(pos, from_ascii(""), font, Change(bparams.trackChanges
?
+Change::INSERTED : Change::UNCHANGED));
+pos = pos + 4;
  space_inserted = true;
 }


I don't understand this. About which freespacing environments are we
talking. InsetListings for example can handle tabulators without problem, so
in that case it would be wrong to convert to four spaces. In ERT it's the
user's own responsibility not to use tabulators.


You are right, this change only needs to be done for lyxlist. For all other cases where free spacing 
is allowed, this is not necessary.
I assume that it is impossible the access the info if the pasted text goes into a lyxlist or not, or 
is this possible? if the latter, how?


thanks and regards
Uwe

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 23.08.2011 23:18, schrieb Jean-Marc Lasgouttes:


I think lyxcode is fundamentally flawed, but nobody dares fixing it :)


The code is correct - it uses LaTeX#s list environment which is designed for 
this purpose.


Could we just use alltt or even verbatim instead?


VFerbatim would not allow any formatting while list does. What is alltt?


Another solution would be to use \obeyspace there and just remve the freespace 
nonsense.


Free spacing is OK here and therefore also provided by LaTeX's list environment. The only issue is 
that we are currentl using in any case non-breakable spaces and that is what my patch fixes.



This is
more work, but a better result. For this we could have to create a new value 
freespacing=2 that
means "allow mutiple spaces, but output them as normal spaces.


But the aim of lyxlist is to provide an environment where multiple spaces are output as such and not 
only as one single space.


regards Uwe

Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 06/08/11 17:40, Uwe Stöhr a écrit :

\begin{lyxcode}
~~~Hello~~Hello~~\end{lyxcode}

This is wrong because if the line is too long, LaTeX tries to break the
line and does this at the first possibility - and this is at the
beginning of course. Thus the leading spaces get lost which was reported
as bug #4742. The fix consists of two things:

1. automatically transform the spaces to '\ ' instead of '~'
2. allow the user to insert a protected space to the LyX-Code
environment if he needs this

This solution is the result of a discussion at comp.text.tex with the
TeX experts Oberdiek, Kastrup and Arseneau.


I think lyxcode is fundamentally flawed, but nobody dares fixing it :)
Could we just use alltt or even verbatim instead?

Another solution would be to use \obeyspace there and just remve the 
freespace nonsense. This is more work, but a better result. For this we 
could have to create a new value freespacing=2 that means allow mutiple 
spaces, but output them as normal spaces.


JMarc

Re: About our bug in treating spaces from copied text

[Jean-Marc Lasgouttes]

Le 06/08/11 17:40, Uwe Stöhr a écrit :

\begin{lyxcode}
~~~Hello~~Hello~~\end{lyxcode}

This is wrong because if the line is too long, LaTeX tries to break the
line and does this at the first possibility - and this is at the
beginning of course. Thus the leading spaces get lost which was reported
as bug #4742. The fix consists of two things:

1. automatically transform the spaces to '\ ' instead of '~'
2. allow the user to insert a protected space to the LyX-Code
environment if he needs this

This solution is the result of a discussion at comp.text.tex with the
TeX experts Oberdiek, Kastrup and Arseneau.


I think lyxcode is fundamentally flawed, but nobody dares fixing it :)
Could we just use alltt or even verbatim instead?

Another solution would be to use \obeyspace there and just remve the 
freespace nonsense. This is more work, but a better result. For this we 
could have to create a new value freespacing=2 that means "allow mutiple 
spaces, but output them as normal spaces.


JMarc

Re: About our bug in treating spaces from copied text

[Vincent van Ravesteijn]

On Mon, Aug 15, 2011 at 6:06 AM, Uwe Stöhr uwesto...@web.de wrote:


 Am 12.08.2011 20:12, schrieb Vincent van Ravesteijn:



 Paragraph::insert(...) just calls Paragraph::insertChar(). Looking at
 Paragraph::insertChar(...,
 bool trackChanges) you can see that this does nothing else than
 Paragraph::insertChar(..., Change
 const  change) except for using Change(trackChanges ? Change::INSERTED :
 Change::UNCHANGED).



 Thanks!

 The attached patch now works also in case of ChangeTracking correctly.

 So what is now only missing is to allow to insert a protected space in
 LyX-Code.

 regards Uwe



  - } else if (style.free_spacing) {
 -  os  '~';
 + }
 + // we need a normal space here ('\ ') that allows line breaks
 + // and no protected space ('~') see bug #4742
 + else if (style.free_spacing) {
 +  os  \\ ;
   } else {
os  ' ';

I would prefer the comment within the else if {..} block.


 } else {
 -par.insertChar(pos, *cit, font, bparams.trackChanges);
 -++pos;
 +// transfporm tabulators to 4 spaces because LaTeX cannot handle


transfporm - transform

 +// tabulators and outputting a single space instead is not what we
 +// want in FreeSpacing mode
 +par.insert(pos, from_ascii(), font, Change(bparams.trackChanges
 ?
 +Change::INSERTED : Change::UNCHANGED));
 +pos = pos + 4;
  space_inserted = true;
 }

I don't understand this. About which freespacing environments are we
talking. InsetListings for example can handle tabulators without problem, so
in that case it would be wrong to convert to four spaces. In ERT it's the
user's own responsibility not to use tabulators.

Could you elaborate on the idea behind this (or should* *I read the bug) ?

Vincent

Re: About our bug in treating spaces from copied text

[Vincent van Ravesteijn]

On Mon, Aug 15, 2011 at 6:06 AM, Uwe Stöhr  wrote:


> Am 12.08.2011 20:12, schrieb Vincent van Ravesteijn:
>
>
>
>> Paragraph::insert(...) just calls Paragraph::insertChar(). Looking at
>> Paragraph::insertChar(...,
>> bool trackChanges) you can see that this does nothing else than
>> Paragraph::insertChar(..., Change
>> const & change) except for using "Change(trackChanges ? Change::INSERTED :
>> Change::UNCHANGED)".
>>
>>
>
> Thanks!
>
> The attached patch now works also in case of ChangeTracking correctly.
>
> So what is now only missing is to allow to insert a protected space in
> LyX-Code.
>
> regards Uwe
>
>
>
>  - } else if (style.free_spacing) {
> -  os << '~';
> + }
> + // we need a normal space here ('\ ') that allows line breaks
> + // and no protected space ('~') see bug #4742
> + else if (style.free_spacing) {
> +  os << "\\ ";
>   } else {
>os << ' ';
>
I would prefer the comment within the else if {..} block.


> } else {
> -par.insertChar(pos, *cit, font, bparams.trackChanges);
> -++pos;
> +// transfporm tabulators to 4 spaces because LaTeX cannot handle
>

transfporm -> transform

> +// tabulators and outputting a single space instead is not what we
> +// want in FreeSpacing mode
> +par.insert(pos, from_ascii(""), font, Change(bparams.trackChanges
> ?
> +Change::INSERTED : Change::UNCHANGED));
> +pos = pos + 4;
>  space_inserted = true;
> }
>
I don't understand this. About which freespacing environments are we
talking. InsetListings for example can handle tabulators without problem, so
in that case it would be wrong to convert to four spaces. In ERT it's the
user's own responsibility not to use tabulators.

Could you elaborate on the idea behind this (or should* *I read the bug) ?

Vincent

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 12.08.2011 20:12, schrieb Vincent van Ravesteijn:


Paragraph::insert(...) just calls Paragraph::insertChar(). Looking at 
Paragraph::insertChar(...,
bool trackChanges) you can see that this does nothing else than 
Paragraph::insertChar(..., Change
const  change) except for using Change(trackChanges ? Change::INSERTED : 
Change::UNCHANGED).


Thanks!

The attached patch now works also in case of ChangeTracking correctly.

So what is now only missing is to allow to insert a protected space in LyX-Code.

regards Uwe
Index: Paragraph.cpp
===
--- Paragraph.cpp	(revision 39484)
+++ Paragraph.cpp	(working copy)
@@ -903,8 +903,11 @@
 		os  '\n';
 		os.texrow().start(owner_-id(), i + 1);
 		column = 0;
-	} else if (style.free_spacing) {
-		os  '~';
+	}
+	// we need a normal space here ('\ ') that allows line breaks
+	// and no protected space ('~') see bug #4742
+	else if (style.free_spacing) {
+		os  \\ ;
 	} else {
 		os  ' ';
 	}
Index: Text.cpp
===
--- Text.cpp	(revision 39484)
+++ Text.cpp	(working copy)
@@ -788,8 +788,12 @@
 ++pos;
 space_inserted = true;
 			} else {
-par.insertChar(pos, *cit, font, bparams.trackChanges);
-++pos;
+// transfporm tabulators to 4 spaces because LaTeX cannot handle
+// tabulators and outputting a single space instead is not what we
+// want in FreeSpacing mode
+par.insert(pos, from_ascii(), font, Change(bparams.trackChanges ?
+	   Change::INSERTED : Change::UNCHANGED));
+pos = pos + 4;
 space_inserted = true;
 			}
 		} else if (!isPrintable(*cit)) {

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 12.08.2011 20:12, schrieb Vincent van Ravesteijn:


Paragraph::insert(...) just calls Paragraph::insertChar(). Looking at 
Paragraph::insertChar(...,
bool trackChanges) you can see that this does nothing else than 
Paragraph::insertChar(..., Change
const & change) except for using "Change(trackChanges ? Change::INSERTED : 
Change::UNCHANGED)".


Thanks!

The attached patch now works also in case of ChangeTracking correctly.

So what is now only missing is to allow to insert a protected space in LyX-Code.

regards Uwe
Index: Paragraph.cpp
===
--- Paragraph.cpp	(revision 39484)
+++ Paragraph.cpp	(working copy)
@@ -903,8 +903,11 @@
 		os << '\n';
 		os.texrow().start(owner_->id(), i + 1);
 		column = 0;
-	} else if (style.free_spacing) {
-		os << '~';
+	}
+	// we need a normal space here ('\ ') that allows line breaks
+	// and no protected space ('~') see bug #4742
+	else if (style.free_spacing) {
+		os << "\\ ";
 	} else {
 		os << ' ';
 	}
Index: Text.cpp
===
--- Text.cpp	(revision 39484)
+++ Text.cpp	(working copy)
@@ -788,8 +788,12 @@
 ++pos;
 space_inserted = true;
 			} else {
-par.insertChar(pos, *cit, font, bparams.trackChanges);
-++pos;
+// transfporm tabulators to 4 spaces because LaTeX cannot handle
+// tabulators and outputting a single space instead is not what we
+// want in FreeSpacing mode
+par.insert(pos, from_ascii(""), font, Change(bparams.trackChanges ?
+	   Change::INSERTED : Change::UNCHANGED));
+pos = pos + 4;
 space_inserted = true;
 			}
 		} else if (!isPrintable(*cit)) {

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 11.08.2011 03:03, schrieb Pavel Sanda:


why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?


Because par.insert requires a Change statement, while par.insertChar uses a
bool (bparams.trackChanges).
What do you think is correct here?


i dont know CT code. its just suspicious that previous code use variable which
seems to be dependent on the state of CT suddenly changes to some explicit
UNCHAGED state.


I also don't understand it, but par.insert is defined this way. You are right that this is not 
correct because it would not be tracked as change - I'll have a closer look if I can get it right.


thanks and regards
Uwe

Re: About our bug in treating spaces from copied text

[Vincent van Ravesteijn]

Op 12-8-2011 15:40, Uwe Stöhr schreef:

Am 11.08.2011 03:03, schrieb Pavel Sanda:


why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?


Because par.insert requires a Change statement, while par.insertChar 
uses a

bool (bparams.trackChanges).
What do you think is correct here?


i dont know CT code. its just suspicious that previous code use 
variable which
seems to be dependent on the state of CT suddenly changes to some 
explicit

UNCHAGED state.


I also don't understand it, but par.insert is defined this way. You 
are right that this is not correct because it would not be tracked as 
change - I'll have a closer look if I can get it right.


thanks and regards
Uwe


Paragraph::insert(...) just calls Paragraph::insertChar(). Looking at 
Paragraph::insertChar(..., bool trackChanges)  you can see that this 
does nothing else than Paragraph::insertChar(..., Change const  change) 
except for using Change(trackChanges ? Change::INSERTED : 
Change::UNCHANGED).


Vincent

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 11.08.2011 03:03, schrieb Pavel Sanda:


why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?


Because par.insert requires a Change statement, while par.insertChar uses a
bool (bparams.trackChanges).
What do you think is correct here?


i dont know CT code. its just suspicious that previous code use variable which
seems to be dependent on the state of CT suddenly changes to some explicit
UNCHAGED state.


I also don't understand it, but par.insert is defined this way. You are right that this is not 
correct because it would not be tracked as change - I'll have a closer look if I can get it right.


thanks and regards
Uwe

Re: About our bug in treating spaces from copied text

[Vincent van Ravesteijn]

Op 12-8-2011 15:40, Uwe Stöhr schreef:

Am 11.08.2011 03:03, schrieb Pavel Sanda:


why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?


Because par.insert requires a Change statement, while par.insertChar 
uses a

bool (bparams.trackChanges).
What do you think is correct here?


i dont know CT code. its just suspicious that previous code use 
variable which
seems to be dependent on the state of CT suddenly changes to some 
explicit

UNCHAGED state.


I also don't understand it, but par.insert is defined this way. You 
are right that this is not correct because it would not be tracked as 
change - I'll have a closer look if I can get it right.


thanks and regards
Uwe


Paragraph::insert(...) just calls Paragraph::insertChar(). Looking at 
Paragraph::insertChar(..., bool trackChanges)  you can see that this 
does nothing else than Paragraph::insertChar(..., Change const & change) 
except for using "Change(trackChanges ? Change::INSERTED : 
Change::UNCHANGED)".


Vincent

Re: About our bug in treating spaces from copied text

[Pavel Sanda]

Uwe Stöhr wrote:
 Index: Text.cpp
 ===
 --- Text.cpp(revision 39427)
 +++ Text.cpp(working copy)
 @@ -788,8 +788,11 @@
 ++pos;
 space_inserted = true;
 } else {
 -   par.insertChar(pos, *cit, font, 
 bparams.trackChanges);
 -   ++pos;
 +   // transfporm tabulators to 4 spaces because 
 LaTeX cannot handle
 +   // tabulators and outputting a space instead is 
 not what we want
 +   // in FreeSpacing mode
 +   par.insert(pos, from_ascii(), font, 
 Change(Change::UNCHANGED));

 why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?

 Because par.insert requires a Change statement, while par.insertChar uses a 
 bool (bparams.trackChanges).
 What do you think is correct here?

i dont know CT code. its just suspicious that previous code use variable which
seems to be dependent on the state of CT suddenly changes to some explicit
UNCHAGED state. so i'm asking whether you are sure about it :)

pavel

Re: About our bug in treating spaces from copied text

[Pavel Sanda]

Uwe Stöhr wrote:
>>> Index: Text.cpp
>>> ===
>>> --- Text.cpp(revision 39427)
>>> +++ Text.cpp(working copy)
>>> @@ -788,8 +788,11 @@
>>> ++pos;
>>> space_inserted = true;
>>> } else {
>>> -   par.insertChar(pos, *cit, font, 
>>> bparams.trackChanges);
>>> -   ++pos;
>>> +   // transfporm tabulators to 4 spaces because 
>>> LaTeX cannot handle
>>> +   // tabulators and outputting a space instead is 
>>> not what we want
>>> +   // in FreeSpacing mode
>>> +   par.insert(pos, from_ascii(""), font, 
>>> Change(Change::UNCHANGED));
>>
>> why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?
>
> Because par.insert requires a Change statement, while par.insertChar uses a 
> bool (bparams.trackChanges).
> What do you think is correct here?

i dont know CT code. its just suspicious that previous code use variable which
seems to be dependent on the state of CT suddenly changes to some explicit
UNCHAGED state. so i'm asking whether you are sure about it :)

pavel

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 08.08.2011 19:42, schrieb Pavel Sanda:


curious questions:
is style.free_spacing == true only for LyX-Code


No, you can also use this in other layouts as well. There are currently only the layouts beamer and 
egs who are using it and both use the lyxcode environment (which uses LaTeX's list environment).

But this doesn't matter because:


(i.e. can't we break
some other environments by sudden replacing ~ -  '\ ' ?


No. '\ ' is a LaTeX's normal space ~ is a non-breakable space and thus causing the problems. Wht 
the user really wants is a normal space so we should have used '\ ' from the beginning (when lyxcode 
was defined).




Index: Text.cpp
===
--- Text.cpp(revision 39427)
+++ Text.cpp(working copy)
@@ -788,8 +788,11 @@
++pos;
space_inserted = true;
} else {
-   par.insertChar(pos, *cit, font, 
bparams.trackChanges);
-   ++pos;
+   // transfporm tabulators to 4 spaces because 
LaTeX cannot handle
+   // tabulators and outputting a space instead is 
not what we want
+   // in FreeSpacing mode
+   par.insert(pos, from_ascii(), font, 
Change(Change::UNCHANGED));


why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?


Because par.insert requires a Change statement, while par.insertChar uses a 
bool (bparams.trackChanges).
What do you think is correct here?

regards Uwe

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 08.08.2011 19:42, schrieb Pavel Sanda:


curious questions:
is style.free_spacing == true only for LyX-Code


No, you can also use this in other layouts as well. There are currently only the layouts beamer and 
egs who are using it and both use the lyxcode environment (which uses LaTeX's list environment).

But this doesn't matter because:


(i.e. can't we break
some other environments by sudden replacing ~ ->  '\ ' ?


No. '\ ' is a LaTeX's "normal" space ~ is a non-breakable space and thus causing the problems. Wht 
the user really wants is a normal space so we should have used '\ ' from the beginning (when lyxcode 
was defined).




Index: Text.cpp
===
--- Text.cpp(revision 39427)
+++ Text.cpp(working copy)
@@ -788,8 +788,11 @@
++pos;
space_inserted = true;
} else {
-   par.insertChar(pos, *cit, font, 
bparams.trackChanges);
-   ++pos;
+   // transfporm tabulators to 4 spaces because 
LaTeX cannot handle
+   // tabulators and outputting a space instead is 
not what we want
+   // in FreeSpacing mode
+   par.insert(pos, from_ascii(""), font, 
Change(Change::UNCHANGED));


why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?


Because par.insert requires a Change statement, while par.insertChar uses a 
bool (bparams.trackChanges).
What do you think is correct here?

regards Uwe

Re: About our bug in treating spaces from copied text

[Pavel Sanda]

Uwe Stöhr wrote:
 Am 06.08.2011 17:40, schrieb Uwe Stöhr:

 The attached patch fixes point 1. and the tabulator issue.

curious questions:
is style.free_spacing == true only for LyX-Code (i.e. can't we break
some other environments by sudden replacing ~ - '\ ' ?

 + // we need a normal space here ('\ ') that allows line breaks
 + // and no protected space ('~') see bug #4742
 + else if (style.free_spacing) {
 + os  \\ ;
   } else {
   os  ' ';
   }
 Index: Text.cpp
 ===
 --- Text.cpp  (revision 39427)
 +++ Text.cpp  (working copy)
 @@ -788,8 +788,11 @@
   ++pos;
   space_inserted = true;
   } else {
 - par.insertChar(pos, *cit, font, 
 bparams.trackChanges);
 - ++pos;
 + // transfporm tabulators to 4 spaces because 
 LaTeX cannot handle
 + // tabulators and outputting a space instead is 
 not what we want
 + // in FreeSpacing mode
 + par.insert(pos, from_ascii(), font, 
 Change(Change::UNCHANGED));

why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?

pavel

Re: About our bug in treating spaces from copied text

[Pavel Sanda]

Uwe Stöhr wrote:
> Am 06.08.2011 17:40, schrieb Uwe Stöhr:
>
>> The attached patch fixes point 1. and the tabulator issue.

curious questions:
is style.free_spacing == true only for LyX-Code (i.e. can't we break
some other environments by sudden replacing ~ -> '\ ' ?

> + // we need a normal space here ('\ ') that allows line breaks
> + // and no protected space ('~') see bug #4742
> + else if (style.free_spacing) {
> + os << "\\ ";
>   } else {
>   os << ' ';
>   }
> Index: Text.cpp
> ===
> --- Text.cpp  (revision 39427)
> +++ Text.cpp  (working copy)
> @@ -788,8 +788,11 @@
>   ++pos;
>   space_inserted = true;
>   } else {
> - par.insertChar(pos, *cit, font, 
> bparams.trackChanges);
> - ++pos;
> + // transfporm tabulators to 4 spaces because 
> LaTeX cannot handle
> + // tabulators and outputting a space instead is 
> not what we want
> + // in FreeSpacing mode
> + par.insert(pos, from_ascii(""), font, 
> Change(Change::UNCHANGED));

why bparams.trackChanges is replaced by Change(Change::UNCHANGED) ?

pavel

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 06.08.2011 17:40, schrieb Uwe Stöhr:


The attached patch fixes point 1. and the tabulator issue.


Now it is really attached.

regards Uwe
Index: Paragraph.cpp
===
--- Paragraph.cpp	(revision 39427)
+++ Paragraph.cpp	(working copy)
@@ -903,8 +903,11 @@
 		os  '\n';
 		os.texrow().start(owner_-id(), i + 1);
 		column = 0;
-	} else if (style.free_spacing) {
-		os  '~';
+	}
+	// we need a normal space here ('\ ') that allows line breaks
+	// and no protected space ('~') see bug #4742
+	else if (style.free_spacing) {
+		os  \\ ;
 	} else {
 		os  ' ';
 	}
Index: Text.cpp
===
--- Text.cpp	(revision 39427)
+++ Text.cpp	(working copy)
@@ -788,8 +788,11 @@
 ++pos;
 space_inserted = true;
 			} else {
-par.insertChar(pos, *cit, font, bparams.trackChanges);
-++pos;
+// transfporm tabulators to 4 spaces because LaTeX cannot handle
+// tabulators and outputting a space instead is not what we want
+// in FreeSpacing mode
+par.insert(pos, from_ascii(), font, Change(Change::UNCHANGED));
+pos = pos + 4;
 space_inserted = true;
 			}
 		} else if (!isPrintable(*cit)) {

Re: About our bug in treating spaces from copied text

[Uwe Stöhr]

Am 06.08.2011 17:40, schrieb Uwe Stöhr:


The attached patch fixes point 1. and the tabulator issue.


Now it is really attached.

regards Uwe
Index: Paragraph.cpp
===
--- Paragraph.cpp	(revision 39427)
+++ Paragraph.cpp	(working copy)
@@ -903,8 +903,11 @@
 		os << '\n';
 		os.texrow().start(owner_->id(), i + 1);
 		column = 0;
-	} else if (style.free_spacing) {
-		os << '~';
+	}
+	// we need a normal space here ('\ ') that allows line breaks
+	// and no protected space ('~') see bug #4742
+	else if (style.free_spacing) {
+		os << "\\ ";
 	} else {
 		os << ' ';
 	}
Index: Text.cpp
===
--- Text.cpp	(revision 39427)
+++ Text.cpp	(working copy)
@@ -788,8 +788,11 @@
 ++pos;
 space_inserted = true;
 			} else {
-par.insertChar(pos, *cit, font, bparams.trackChanges);
-++pos;
+// transfporm tabulators to 4 spaces because LaTeX cannot handle
+// tabulators and outputting a space instead is not what we want
+// in FreeSpacing mode
+par.insert(pos, from_ascii(""), font, Change(Change::UNCHANGED));
+pos = pos + 4;
 space_inserted = true;
 			}
 		} else if (!isPrintable(*cit)) {