Re: About our bug in treating spaces from copied text
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Mon, Aug 15, 2011 at 6:06 AM, Uwe Stöhrwrote: > 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
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
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
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
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
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
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 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 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
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
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 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 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
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
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)) {