Michael == Michael Gerz [EMAIL PROTECTED] writes:
Michael In other words, you want me to introduce some
Michael enum AcceptReject { ACCEPT, REJECT }
Michael and pass it as parameter, right?
I am sorry that I did not answer in time. To try to compensate, here
is a patch showing what I mean.
Michael == Michael Gerz [EMAIL PROTECTED] writes:
And acceptChanges would be more understandable if named
acceptAllChanges.
Michael What the semantic difference between acceptChanges and
Michael acceptAllChanges? If we All here, we have to add it
Michael everywhere (which means that we can
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Michael == Michael Gerz [EMAIL PROTECTED] writes:
Michael In other words, you want me to introduce some
Michael enum AcceptReject { ACCEPT, REJECT }
Michael and pass it as parameter, right?
Jean-Marc I am sorry that I did not answer
Jean-Marc Lasgouttes schrieb:
I am sorry that I did not answer in time. To try to compensate, here
is a patch showing what I mean. The idea is to use the complete
symmetry between accept and reject:
- accept: remove DELETED chunks, keep INSERTED chunks
- reject: remove INSERTED chunks, keep
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> In other words, you want me to introduce some
Michael> enum AcceptReject { ACCEPT, REJECT }
Michael> and pass it as parameter, right?
I am sorry that I did not answer in time. To try to compensate, here
is a patch showing
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
>> And acceptChanges would be more understandable if named
>> acceptAllChanges.
>>
Michael> What the semantic difference between acceptChanges and
Michael> acceptAllChanges? If we "All" here, we have to add it
Michael> everywhere (which
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> In other words, you want me to introduce some
Michael> enum AcceptReject { ACCEPT, REJECT }
Michael> and pass it as parameter, right?
Jean-Marc> I am sorry
Jean-Marc Lasgouttes schrieb:
I am sorry that I did not answer in time. To try to compensate, here
is a patch showing what I mean. The idea is to use the complete
symmetry between accept and reject:
- accept: remove DELETED chunks, keep INSERTED chunks
- reject: remove INSERTED chunks, keep
Michael Gerz wrote:
Hi,
this patch should fix most problems related to accept/reject-change. I
tested it briefly (given the limited time resources).
I don't understand where InsetText::acceptChanges() and
InsetText::rejectChanges() are used. I only see that
LyXText::acceptOrRejectChange()
Jean-Marc Lasgouttes schrieb:
* src/lyxtext.h:
* src/BufferView.C: * src/text3.C: * src/text.C: merge methods
acceptChange() and rejectChange() to acceptOrRejectChange() because
they share a lot of tricky code
I think you could have kept acceptChange and rejectChanges as trivial
Abdelrazak Younes schrieb:
Michael Gerz wrote:
Hi,
this patch should fix most problems related to accept/reject-change.
I tested it briefly (given the limited time resources).
I don't understand where InsetText::acceptChanges() and
InsetText::rejectChanges() are used. I only see that
Michael Gerz wrote:
Hi,
this patch should fix most problems related to accept/reject-change. I
tested it briefly (given the limited time resources).
I don't understand where InsetText::acceptChanges() and
InsetText::rejectChanges() are used. I only see that
LyXText::acceptOrRejectChange()
Jean-Marc Lasgouttes schrieb:
* src/lyxtext.h:
* src/BufferView.C: * src/text3.C: * src/text.C: merge methods
acceptChange() and rejectChange() to acceptOrRejectChange() because
they share a lot of tricky code
I think you could have kept acceptChange and rejectChanges as trivial
Abdelrazak Younes schrieb:
Michael Gerz wrote:
Hi,
this patch should fix most problems related to accept/reject-change.
I tested it briefly (given the limited time resources).
I don't understand where InsetText::acceptChanges() and
InsetText::rejectChanges() are used. I only see that
Hi,
this patch should fix most problems related to accept/reject-change. I
tested it briefly (given the limited time resources).
Remaining items on my agenda:
- invoke DEPM after accept/reject-change (high prio, take 1 evening)
- implement accept/reject-all-changes as an atomic operation
Michael == Michael Gerz [EMAIL PROTECTED] writes:
* src/lyxtext.h:
* src/BufferView.C: * src/text3.C: * src/text.C: merge methods
acceptChange() and rejectChange() to acceptOrRejectChange() because
they share a lot of tricky code
I think you could have kept acceptChange and rejectChanges
Hi,
this patch should fix most problems related to accept/reject-change. I
tested it briefly (given the limited time resources).
Remaining items on my agenda:
- invoke DEPM after accept/reject-change (high prio, take 1 evening)
- implement accept/reject-all-changes as an atomic operation
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
>> * src/lyxtext.h:
>> * src/BufferView.C: * src/text3.C: * src/text.C: merge methods
>> acceptChange() and rejectChange() to acceptOrRejectChange() because
>> they share a lot of tricky code
I think you could have kept acceptChange
18 matches
Mail list logo
