On 2020-08-07 14:29, Jürgen Spitzmüller wrote:
Am Freitag, den 07.08.2020, 13:48 +0200 schrieb Daniel:
Anyone seeing this regression?
Steps to reproduce:
1. Enable change tracking
2. Copy something
3. Paste it
Actual result:
- Pasted content not marked as added
Expected result:
- It is marked
Am Freitag, den 07.08.2020, 15:58 +0200 schrieb Thibaut Cuvelier:
> Shouldn't this parameter be set by default?
I agree.
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Fri, 7 Aug 2020 at 14:30, Jürgen Spitzmüller wrote:
> Am Freitag, den 07.08.2020, 13:48 +0200 schrieb Daniel:
> > Anyone seeing this regression?
> >
> > Steps to reproduce:
> > 1. Enable change tracking
> > 2. Copy something
> > 3. Paste it
> >
> > Actual result:
> > - Pasted content not marke
Am Freitag, den 07.08.2020, 13:48 +0200 schrieb Daniel:
> Anyone seeing this regression?
>
> Steps to reproduce:
> 1. Enable change tracking
> 2. Copy something
> 3. Paste it
>
> Actual result:
> - Pasted content not marked as added
>
> Expected result:
> - It is marked as added.
Tools > Prefer
Le 29/09/2016 à 14:03, Kornel Benko a écrit :
Shouldn't be 'List of Slides' also in French?
See attached.
(Slide in 1.1 Liste des transparents)
Sure, this is not translated in fr.po,
I've added
\def\listslidename{Liste des transparents}
in the preamble without success :-(
In fact, slidesec
Am Donnerstag, 29. September 2016 um 13:59:02, schrieb Jean-Pierre Chrétien
> Le 29/09/2016 à 09:54, Guenter Milde a écrit :
> > On 2016-09-28, Guenter Milde wrote:
> >> On 2016-09-28, Jean-Pierre Chrétien wrote:
> >>> Le 26/09/2016 à 09:24, Jean-Pierre Chrétien a écrit :
>
> >>>- the outline
Le 29/09/2016 à 09:54, Guenter Milde a écrit :
On 2016-09-28, Guenter Milde wrote:
On 2016-09-28, Jean-Pierre Chrétien wrote:
Le 26/09/2016 à 09:24, Jean-Pierre Chrétien a écrit :
- the outline and progress slides include an empty line after slide "Warning"
that I could not remove
Actu
On 2016-09-28, Guenter Milde wrote:
> On 2016-09-28, Jean-Pierre Chrétien wrote:
>> Le 26/09/2016 à 09:24, Jean-Pierre Chrétien a écrit :
Dear Jean-Pierre,
>> I've updated the French translation and committed it, so you may abandon the
>> change tracking as there are no other translations of thi
On 2016-09-28, Jean-Pierre Chrétien wrote:
> Le 26/09/2016 à 09:24, Jean-Pierre Chrétien a écrit :
Dear Jean-Pierre,
> I've updated the French translation and committed it, so you may abandon the
> change tracking as there are no other translations of this document.
thank you for the translatio
Le 26/09/2016 à 09:24, Jean-Pierre Chrétien a écrit :
Le 26/09/2016 à 01:31, Uwe Stöhr a écrit :
On Fri, Sep 23, 2016 at 07:37:39PM +, Guenter Milde wrote:
the seminar example file lib/examples/seminar.lyx is outdated.
There is a French translation in lib/examples/fr/seminar.lyx
I wrote
Le 26/09/2016 à 01:31, Uwe Stöhr a écrit :
On Fri, Sep 23, 2016 at 07:37:39PM +, Guenter Milde wrote:
the seminar example file lib/examples/seminar.lyx is outdated.
There is a French translation in lib/examples/fr/seminar.lyx
I wrote the original and would volunteer to update it.
Should
On Fri, Sep 23, 2016 at 07:37:39PM +, Guenter Milde wrote:
the seminar example file lib/examples/seminar.lyx is outdated.
There is a French translation in lib/examples/fr/seminar.lyx
I wrote the original and would volunteer to update it.
Should I use change tracking for an example file up
On Sat, Sep 24, 2016 at 11:34:11AM -0400, Scott Kostyshak wrote:
> Please CC Uwe on questions like these. He does not have time to follow
> all threads on the list. I have added him to the CC list.
Oops, now he's CC'ed.
> On Fri, Sep 23, 2016 at 07:37:39PM +, Guenter Milde wrote:
> > Dear Lyx
Please CC Uwe on questions like these. He does not have time to follow
all threads on the list. I have added him to the CC list.
On Fri, Sep 23, 2016 at 07:37:39PM +, Guenter Milde wrote:
> Dear Lyxdevelopers,
>
> the seminar example file lib/examples/seminar.lyx is outdated.
>
> There is a
On Thu, Oct 22, 2015 at 11:27:56PM -0400, Paul A. Rubin wrote:
>
> On 10/22/2015 06:33 PM, Scott Kostyshak wrote:
> >Actually I forgot to attach the .tex file. It is now attached (I BCC you
> >just in case). Scott
> Okay, we're getting a little clarity here. Your .tex file compiled and
> displayed
On 10/22/2015 06:33 PM, Scott Kostyshak wrote:
Actually I forgot to attach the .tex file. It is now attached (I BCC
you just in case). Scott
Okay, we're getting a little clarity here. Your .tex file compiled and
displayed correctly. I dug a little deeper and discovered that, in
addition to th
On Thu, Oct 22, 2015 at 07:42:59PM +, Paul A. Rubin wrote:
> Scott Kostyshak lyx.org> writes:
>
>
> >
> > Attached is my export to LaTeX (plain). If you compile it (with just the
> > command "latex") can you see the colors in the resulting dvi? What about
> > when you convert to PDF? I'm ac
Scott Kostyshak lyx.org> writes:
>
> Attached is my export to LaTeX (plain). If you compile it (with just the
> command "latex") can you see the colors in the resulting dvi? What about
> when you convert to PDF? I'm actually hoping that when you compile you
> get an error because of a missing p
On Wed, Oct 21, 2015 at 10:44:47PM +, Paul A. Rubin wrote:
> Scott Kostyshak lyx.org> writes:
>
>
> >
> > OK then we need to do another round of you exporting to .tex. The reason
> > is that I do not have dvipost installed (and it is not in the repos for
> > Ubuntu 15.04) so I cannot compil
Scott Kostyshak lyx.org> writes:
>
> OK then we need to do another round of you exporting to .tex. The reason
> is that I do not have dvipost installed (and it is not in the repos for
> Ubuntu 15.04) so I cannot compile the .tex files that you sent nor can I
> compare your .tex files with the o
On Wed, Oct 21, 2015 at 03:26:50PM +, Paul A. Rubin wrote:
> After uninstalling dvipost and reconfiguring LyX, nothing changed -- no
> change annotations in the output other than pdflatex.
OK then we need to do another round of you exporting to .tex. The reason
is that I do not have dvipost i
Scott Kostyshak lyx.org> writes:
>
> I think you do actually have dvipost. Your log file suggests that it is
> here:
> /home/paul/texmf/tex/latex/dvipost/dvipost.sty
Yes, I installed it.
>
> I wonder if this could be the critical difference between your setup and
> Kornel's/mine. If you are c
On Tue, Oct 20, 2015 at 10:03:27PM +, Paul A. Rubin wrote:
> > I did not test (I assume I get the same result as Kornel since I have a
> > similar system), but I suppose the next step is to send the .tex files.
> > e.g. instead of exporting to PDF (pdflatex) export to LaTeX (pdflatex).
I do i
Scott Kostyshak lyx.org> writes:
>
> On Tue, Oct 20, 2015 at 06:15:13PM +0200, Kornel Benko wrote:
> >
> > I tried your example, all available pdf formats are displaying the
change here.
> > (E.g.
> > PDF (ps2pdf), PDF (pdflatex), PDF (dvipdfm), PDF (XeTeX), PDF (LuaTeX)
> > )
> >
> > Ex
On Tue, Oct 20, 2015 at 03:49:40PM +, Paul A. Rubin wrote:
> Scott Kostyshak lyx.org> writes:
>
>
> >
> > Hi Paul, can you send a minimal example to the list so we can see if we
> > see the changes in other formats? So to confirm, if you compile with
> > XeTeX or LuaTeX you do not see the c
On Tue, Oct 20, 2015 at 06:15:13PM +0200, Kornel Benko wrote:
> Am Montag, 19. Oktober 2015 um 14:27:54, schrieb Paul A. Rubin
> > Hi all,
> >
> > I couldn't find an open bug report on either of these, so I thought I'd
> > ask for input here. The following apply to LyX 2.1.4.
> >
> > Issue #1:
Am Montag, 19. Oktober 2015 um 14:27:54, schrieb Paul A. Rubin
> Hi all,
>
> I couldn't find an open bug report on either of these, so I thought I'd
> ask for input here. The following apply to LyX 2.1.4.
>
> Issue #1: In the User Guide, section 6.16, the last paragraph says that
> dvipost mus
Scott Kostyshak lyx.org> writes:
>
> Hi Paul, can you send a minimal example to the list so we can see if we
> see the changes in other formats? So to confirm, if you compile with
> XeTeX or LuaTeX you do not see the changes?
Scott,
I'm not set up to use LuaTeX (and don't know how to use XeTe
On Mon, Oct 19, 2015 at 02:27:54PM -0400, Paul A. Rubin wrote:
> Hi all,
>
> I couldn't find an open bug report on either of these, so I thought I'd ask
> for input here. The following apply to LyX 2.1.4.
>
> Issue #1: In the User Guide, section 6.16, the last paragraph says that
> dvipost must b
2015-09-29 1:39 GMT+02:00 Scott Kostyshak :
> > For backwards compatibility, it could be an optional argument
> > \lyxadded[blue]{author}{date}{text}
>
> Good idea. I catch myself postponing thinking about backwards
> compatibility until a later stage. I hope that someday I will learn to
> think a
On Mon, Sep 28, 2015 at 05:27:44PM +0200, Jean-Marc Lasgouttes wrote:
> Le 27/09/2015 08:47, Scott Kostyshak a écrit :
> >If there are changes from multiple authors in a LyX file, the LyX
> >display shows different colors for each author. But when "Show changes
> >in output" is checked, the PDF onl
Le 27/09/2015 08:47, Scott Kostyshak a écrit :
If there are changes from multiple authors in a LyX file, the LyX
display shows different colors for each author. But when "Show changes
in output" is checked, the PDF only uses one color to show changes.
Attached is an example file.
The LaTeX shows
On 04/11/2012 12:05 AM, Xu Wang wrote:
I'm just curious as to whether change tracking will be implemented for
mathed or if there is some fundamental problem with doing so. I
imagine it will take a lot of work, but just curious if it's on
anyone's (long term?) todo list.
I don't know the answe
On Sun, Oct 24, 2010 at 11:01:53PM +0200, Vincent van Ravesteijn wrote:
> > I took a look and this looks good so far and a bit simpler than what I
> > thought would be necessary but I haven't tried to test it yet.
> >
>
> Please test if you have time. It was a long time ago for me too that I
> wor
On Sat, Oct 23, 2010 at 6:15 PM, Gregory Jefferis wrote:
> On 2010-10-23 16:40, "Richard Heck" wrote:
>
>> BUT...perhaps we could avoid going forward by allowing LyX to calculate
>> the hash value. I'd guess that it is easy to check if we have a hash
>> value or not, right? If not, then we can ca
> I took a look and this looks good so far and a bit simpler than what I
> thought would be necessary but I haven't tried to test it yet.
>
Please test if you have time. It was a long time ago for me too that I
worked on that code.
> I do remember that someone commented that they didn't like the
On 2010-10-23 16:40, "Richard Heck" wrote:
> BUT...perhaps we could avoid going forward by allowing LyX to calculate
> the hash value. I'd guess that it is easy to check if we have a hash
> value or not, right? If not, then we can calculate it. Maybe we need
> such code, anyway, in case there's s
On 10/23/2010 10:38 AM, Gregory Jefferis wrote:
On 2010-10-23 15:19, "Richard Heck" wrote:
On 10/23/2010 07:18 AM, Gregory Jefferis wrote:
3) How should lyx2lyx be handled in this case? I guess I need to layer a
conversion from vfr's patch (format 369) to my proposal. Or
On 2010-10-23 15:19, "Richard Heck" wrote:
> On 10/23/2010 07:18 AM, Gregory Jefferis wrote:
>>
3) How should lyx2lyx be handled in this case? I guess I need to layer a
conversion from vfr's patch (format 369) to my proposal. Or if that file
format was never a stable release
On 10/23/2010 07:18 AM, Gregory Jefferis wrote:
3) How should lyx2lyx be handled in this case? I guess I need to layer a
conversion from vfr's patch (format 369) to my proposal. Or if that file
format was never a stable release can it be ignored?
Now we only need to revert the hash n
Hi Vincent,
Thank you very much for getting back to this.
On 2010-10-23 03:21, "Vincent van Ravesteijn" wrote:
> Hi Gregory,
>
>> 1) I have a patch set for 1.6.X which will no longer apply because Vincent
>> (vfr) already contributed an alternative. I presume that I need to modify
>> my patch
Hi Gregory,
> 1) I have a patch set for 1.6.X which will no longer apply because Vincent
> (vfr) already contributed an alternative. I presume that I need to modify
> my patch to layer on top of his.
Actually, I wouldn't say I contributed an alternative. I just put in
your idea but implemented s
On 09/26/2010 07:57 PM, Gregory Jefferis wrote:
I would like to have another go at fixing this bad interaction between track
changes and version control systems. Basically means using a hash function
of author email (+/- name) rather than an integer starting at 1 to identify
the author of track
On 09/27/2010 07:24 AM, Pavel Sanda wrote:
Gregory Jefferis wrote:
conversion from vfr's patch (format 369) to my proposal. Or if that file
format was never a stable release can it be ignored?
i think it can't be ignored and new conversion needs to be built on top of it.
our own manu
Gregory Jefferis wrote:
> conversion from vfr's patch (format 369) to my proposal. Or if that file
> format was never a stable release can it be ignored?
i think it can't be ignored and new conversion needs to be built on top of it.
our own manuals are currently in this format too, not to speak a
yes i remember the thread. you unfortunately took too long hiatus and Vincent
disappeared meanwhile... ;)
I'm not disappeared.. ;) and this was still on my todo list. I didn't
forget about it. There just always seems other things that need to be
done too :(.
I'll be somewhat more visibly b
Vincent van Ravesteijn wrote:
> Are these ok for branch ?
Yes, OK.
Jürgen
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
This patch got more and more complicated when trying to solve the
technical implementation (see thread on Merging Colors).
What is your opinion now ?
What are the remaining issues of the "merging colors" patch? AFAICS, there
w
Andre Poenitz schreef:
On Sun, Feb 08, 2009 at 03:49:49AM +0100, Vincent van Ravesteijn wrote:
OK ?
I am a bit concerned about the includes, but I think that can be handled
later by something like the attached patch (untested).
These includes are simply a result of the fact that I
On Sun, Feb 08, 2009 at 03:49:49AM +0100, Vincent van Ravesteijn wrote:
> OK ?
I am a bit concerned about the includes, but I think that can be handled
later by something like the attached patch (untested).
Andre'
Index: Color.h
===
Final patches (I hope).
Patch 1:
*Color.cpp/h: add new Color class
*ColorCache.cpp/h: add code to convert Color to QColor
Patch 2:
* rowpainter.cpp: now the color for painting selected text and changed
text is set via FontInfo::setColor. However, this color should remain a
ColorCode as this co
Vincent van Ravesteijn schrieb:
The patch will be huge and I need to be very careful.
OK then better not before LyX 1.6.3. I'll test it as best as possible in the meantime because I have
to use change tracking quite often these days.
I will do it shortly, but I'm fixing some critical bugs
Uwe Stöhr schreef:
Vincent van Ravesteijn schrieb:
Otherwise I ask for an OK or comments for this patch.
Hello Vincent, what about your patch? When I remember correctly we
agreed to put it in for LyX 1.6.x and it was also requested in
bugzilla. Can you put it to trunk please?
Jürgen, am I
Vincent van Ravesteijn schrieb:
Otherwise I ask for an OK or comments for this patch.
Hello Vincent, what about your patch? When I remember correctly we agreed to put it in for LyX 1.6.x
and it was also requested in bugzilla. Can you put it to trunk please?
Jürgen, am I right? If so this sh
Vincent van Ravesteijn wrote:
> Yes, the last remarks of JMarc can be addressed quite easily.
>
> The risks I see is that I would have to change almost all ColorCode's in
> the code to Color objects. Every change or lack of change could possibly
> introduce a new bug.
If you think it's too risky,
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
This patch got more and more complicated when trying to solve the
technical implementation (see thread on Merging Colors).
What is your opinion now ?
What are the remaining issues of the "merging colors" patch? AFAICS, there
w
Vincent van Ravesteijn wrote:
> This patch got more and more complicated when trying to solve the
> technical implementation (see thread on Merging Colors).
>
> What is your opinion now ?
What are the remaining issues of the "merging colors" patch? AFAICS, there
were some final concerns by Jean-M
Jürgen Spitzmüller schreef:
Uwe Stöhr wrote:
Looks good, please put it in. This should in my opinion also go to LyX
1.6.2.
I agree (if the issues concerning the technical implementations are sorted
out).
Jürgen
This patch got more and more complicated when trying to solve the
te
On Thu, Jan 15, 2009 at 08:59:34AM +0100, Jean-Marc Lasgouttes wrote:
> I thought it was done by some templates, but now I cannot find them.
> Forget that for now.
It's in std::rel_ops in
But they tend to create more trouble than benefit.
Andre'
Le 14 janv. 09 à 23:19, Vincent van Ravesteijn a écrit :
Done. The nice thing is that we can now also make a new color:
Color_deletedtextmodifier. This can be set by the user to specify
the degree of lightening or darkening of the color. It would be
nice if the user can also put this to Colo
If I can go through with this, I would like to have a few OKs, because
changing all ColorCode's in the sources to Color is a quite intrusive
operation.
Yes, though that sort of sed-patch can often be committed separately,
for the most part, and it's usually fairly safe, in the sense that, if
Jean-Marc Lasgouttes schreef:
I created a new class ColorCode (and renamed the old enum to
something else).
Why not Color?
I moved this class to Color.cpp and renamed it to Color.
You could remove this type and set mergecolor to Color_ignore when no
merging is required (would b
Vincent van Ravesteijn writes:
> Herewith I'd like to propose a different solution. I'd like to hear
> whether this is a reasonable solution or not.
I am not sure that I prefer it to my solution, but I could live with it.
>I created a new class ColorCode (and renamed the old enum to
>som
Vincent van Ravesteijn wrote:
I like it, although I am not 100% sure from your screenshot that all
different pairs of colors can be
visually matched. And we have no idea of how color blind people
react to this.
What is probably strange is that the _deleted color will only be
available to th
I like it, although I am not 100% sure from your screenshot that all
different pairs of colors can be
visually matched. And we have no idea of how color blind people react
to this.
What is probably strange is that the _deleted color will only be
available to the user for changing when
has ac
Vincent van Ravesteijn wrote:
> While we are at the subject, I realized that the latex output with
> changes might be subject to change too.
>
> Do we want to exactly use the same colors in the output as on screen ?
Yes, why not.
> For now, the dvipost implementation of changes in the output is
>
While we are at the subject, I realized that the latex output with
changes might be subject to change too.
Do we want to exactly use the same colors in the output as on screen ?
For now, the dvipost implementation of changes in the output is
hardcoded as Red and Blue, can this be made any colo
Uwe Stöhr wrote:
> Looks good, please put it in. This should in my opinion also go to LyX
> 1.6.2.
I agree (if the issues concerning the technical implementations are sorted
out).
Jürgen
Vincent van Ravesteijn schrieb:
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
Looks good, please put it in. This should in my opinion also go to LyX
1.6.2.
regards Uwe
Jean-Marc Lasgouttes schreef:
Le 28 déc. 08 à 01:47, Vincent van Ravesteijn a écrit :
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear them.
I like it, although I a
On 28/12/2008 12:50, Jean-Marc Lasgouttes wrote:
Le 28 déc. 08 à 01:47, Vincent van Ravesteijn a écrit :
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear them.
Look
Le 28 déc. 08 à 01:47, Vincent van Ravesteijn a écrit :
Here is a patch that lowers the saturation for deletions. It is
also possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear them.
I like it, although I am not 100% sure from your scre
> The only point I would put forward is to take care that saturation is not too
> low, for accessibility reasons.
if this turns out to be an issue we could always add the saturation level to
the preferences...
rgheck wrote:
> > Here is a patch that lowers the saturation for deletions. It is also
> > possible to increase the saturation as shown in the attached.
> >
> > If there are strong opinions I'd like to hear them.
> >
> > Otherwise I ask for an OK or comments for this patch.
>
> Looks good to me. I
Vincent van Ravesteijn wrote:
leuven edwin schreef:
I'm open for new ideas.
or lower the saturation for deletions as in attached
edwin
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are str
leuven edwin schreef:
I'm open for new ideas.
or lower the saturation for deletions as in attached
edwin
Here is a patch that lowers the saturation for deletions. It is also
possible to increase the saturation as shown in the attached.
If there are strong opinions I'd like to hear t
Richard Heck schreef:
Uwe Stöhr wrote:
leuven edwin schrieb:
or lower the saturation for deletions as in attached
This is a cool idea! This is perhaps the better solution.
I was about to suggest something similar. We need something that
scales, and this does.
rh
Yes, I had somewhat the
Uwe Stöhr wrote:
leuven edwin schrieb:
or lower the saturation for deletions as in attached
This is a cool idea! This is perhaps the better solution.
I was about to suggest something similar. We need something that scales,
and this does.
rh
leuven edwin schrieb:
or lower the saturation for deletions as in attached
This is a cool idea! This is perhaps the better solution.
best regards
Uwe
> I'm open for new ideas.
or lower the saturation for deletions as in attached
edwin
<>
Vincent van Ravesteijn schrieb:
You have just found a new feature in LyX. Each author has his own color
for the changes he made. Now, the addition and deletion is shown by
either a strike-through or an underline.
This is indeed a new feature I was not aware of. But anyway, having the same col
Uwe Stöhr schreef:
Today me was sent a larger file created with LyX 1.5.x with change
tracking enabled. When opening that file with LyX 1.6.1 every change
is highlighted in blue, no matter if it was a deletion or addition.
This make change tracking rather unusable.
In LyX 1.5.7 deletions are c
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> It is again the spam filter getting mad. I restarted it, and things
> seem to be better now.
Thanks. I've entered them and added sample files. Unfortunately a few duplicates
got created (the site was pretty slow and showed me errors so I retried)
baseliner <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
>>
>> Please enter these two bugs in bugzilla if you do not get another answer.
>>
> Thanks JMarc.. I'm trying to login to bugzilla but it's timing out..
> tried a few times over the last 2 days.
It is ag
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> Please enter these two bugs in bugzilla if you do not get another answer.
>
Thanks JMarc.. I'm trying to login to bugzilla but it's timing out.. tried a few
times over the last 2 days.
baseliner <[EMAIL PROTECTED]> writes:
> Hi folks - I'd posted a couple issues related to change tracking to the users
> list but maybe that's not the right place given that they look like bugs..
> here're the two threads:
>
> http://thread.gmane.org/gmane.editors.lyx.general/51179
Please enter t
baseliner <[EMAIL PROTECTED]> schrieb:
> Have these already been logged? If not, please let me know if there's a
> place I should log it.
http://bugzilla.lyx.org
Günter
Andre Poenitz wrote:
... seems to be completely broken in trunk.
Has anybody tried it lately?
I just tried, seems to work fine. Change Tracking is by the way an
obvious candidate for context menu. Right now, one have to select a
change in order to accept it or reject via the "Document->Chang
Jürgen Spitzmüller wrote:
> I see. Try the following in preamble:
>
> \renewcommand{\lyxadded}[3]{%
> {\texorpdfstring{\color{lyxadded}}{}#3}%
> }
> \renewcommand{\lyxdeleted}[3]{%
> {\texorpdfstring{\color{lyxdeleted}\st{#3}}{#3}}%
> }
fixed in 1.6. In 1.5.x, we would need such a beast as
John Pye wrote:
> I have worked out a simple test case that illustrates this problem. The
> details I have posted as a new bug,
>
> http://bugzilla.lyx.org/show_bug.cgi?id=4504
>
> Would really appreciate any suggestions on how to overcome/work around
> this bug, as it's causing me quite some incon
Hi all,
I have worked out a simple test case that illustrates this problem. The
details I have posted as a new bug,
http://bugzilla.lyx.org/show_bug.cgi?id=4504
Would really appreciate any suggestions on how to overcome/work around
this bug, as it's causing me quite some inconvenience :-(
Cheer
John Pye wrote:
> Log file is attached.
Really just a shot in the dark, but does either of the following in preamble
change anything?
a.)
\renewcommand{\lyxadded}[3]{\bgroup \color{lyxadded}#3\egroup}
\renewcommand{\lyxdeleted}[3]{\bgroup \color{lyxdeleted}\st{#3}\egroup}
b.)
\usepackage{pdf
On Sun, Jan 13, 2008 at 09:40:07PM +1100, John Pye wrote:
> Hi Jürgen,
>
> Jürgen Spitzmüller wrote:
> > John Pye wrote:
> >
> >> Attached is a screenshot with the error from LyX, and the first one
> >> highlighted. It says "argument of \let has an extra }".
> >>
> >
> > The log file would
John Pye wrote:
> Attached is a screenshot with the error from LyX, and the first one
> highlighted. It says "argument of \let has an extra }".
The log file would really help more. And could you also post an example file
that shows the behaviour?
Jürgen
Attached is a screenshot with the error from LyX, and the first one
highlighted. It says "argument of \let has an extra }".
Cheers
JP
Jürgen Spitzmüller wrote:
> John Pye wrote:
>
>> what can I do to fix my document?
>>
>
> For a start, post the error message (or the LaTeX log file), plea
John Pye wrote:
> Hi all,
>
> I'm afraid I got ahead of myself a bit when I wrote the following :-(
>
>> ... the track-changes stage of my [...] on the whole works very nicely.
>>
>
> An afternoon's worth of editing with track-changes turned on has
> resulted in a compound document, one fil
John Pye wrote:
> what can I do to fix my document?
For a start, post the error message (or the LaTeX log file), please.
Jürgen
Michael Gerz wrote:
> IMHO, "find & replace" should always ignore deleted text, in CT mode as
> well as in non-CT mode.
That's what my patch does. I'm just waiting for your testing.
Jürgen
Helge Hafting schrieb:
If you turn off change tracking and edit, then surely all new stuff
should
be without the change tracking markings. (i.e. not deleted or marked
as inserted by someone.) You may be able to add inside a deleted region,
but that should split the deleted region in two.
That'
Bennett Helm schrieb:
I agree with the last sentence, but notice that the patch doesn't do
this! When change tracking is turned off, it is entirely possible to
delete -- remove from the file -- text that is marked as deleted.
Right. Even if we prohibited it, the user may always accept deleted te
1 - 100 of 199 matches
Mail list logo
