Michael Gerz wrote:
Helge Hafting wrote:
I was hoping to avoid the case where a "new change" happens
in the middle of something, just because a 5-minute border happened
in the middle of some typing. So, merging adjacent changes
(by the same author) that only differ by 5 minutes (or whatever th
Helge Hafting wrote:
I was hoping to avoid the case where a "new change" happens
in the middle of something, just because a 5-minute border happened
in the middle of some typing. So, merging adjacent changes
(by the same author) that only differ by 5 minutes (or whatever the
granularity becomes
Michael Gerz wrote:
Helge Hafting wrote:
Do that mean one eventually have to accept 48 changes for
4 hours of continous typing?
Not really. You can select an arbitrary part of your document and just
invoke "accept-change", which accepts all changes in the given selection.
How about alway
Jean-Marc Lasgouttes wrote:
Michael> For simplicity, we could assume that adjacent changes of the
Michael> _same_ author are always merged, where the later time is
Michael> preserved. In this case, the changetime indicates the latest
Michael> change in the given section. This leads to less chang
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Right now, there is no such concept as an editing session.
Michael> Moreover, I would like to have meaningful changetimes. MS
Michael> Word and OOo also keep track of the exact time.
We should maybe have such concept: a change c
Helge Hafting wrote:
Do that mean one eventually have to accept 48 changes for
4 hours of continous typing?
Not really. You can select an arbitrary part of your document and just
invoke "accept-change", which accepts all changes in the given selection.
How about always merging changes tha
Helge Hafting wrote:
How about always merging changes that are next to each other
and happen in the same editing session? Use the different timestamps
for changes that are not adjacent, they are much more likely not related.
One change is one change even if it took more than 5min to type it in.
[EMAIL PROTECTED] wrote:
Hi folks,
I would like to inform you about two issues that I am going to address this
evening. If you disagree, please complain loudly. Otherwise, I will continue
the CT cleanup...
1. Change time
Every change has a time. This time is used as a guidance for the user w
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Both improvements have been committed. Man, coding has become
Michael> a real joy!
But don't get carried away... These changes were big (in the sense of
changing behaviour) and it would have been better to see the patches
before
Jean-Marc Lasgouttes wrote:
michael> Presently, if you delete an inset, all its content is deleted
michael> recursively. This is unfortunate. Imagine that your colleague
michael> makes changes in an existing inset. He sends it to you and
michael> you come to the conclusion that the inset should
Jean-Marc Lasgouttes wrote:
michael> 1. Change time
This looks OK. Please encapsulate the policy telling which changes are
equal so that we can modify it later.
Another solution would be to have all the changes in a same session be
the same, or all changes by a same author be the same.
Com
> "michael" == michael gerz <[EMAIL PROTECTED]> writes:
michael> Hi folks, I would like to inform you about two issues that I
michael> am going to address this evening. If you disagree, please
michael> complain loudly. Otherwise, I will continue the CT cleanup...
michael> 1. Change time
This
Hi folks,
I would like to inform you about two issues that I am going to address this
evening. If you disagree, please complain loudly. Otherwise, I will continue
the CT cleanup...
1. Change time
Every change has a time. This time is used as a guidance for the user while
editing his document.
Martin Vermeer wrote:
BTW you seem to change some lookupChangeFulls to lookupChange. Is that
intentional?
Yes. Both functions are nearly identical. I think one of them can go.
Michael
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Also before doing too much work in the 1.4.x branch, please
Lars> verify with J-M that it eventually will be accepted... and
Lars> please do not forget trunk.
Good point. While the patch really goes in the right direction, it
s
On Mon, Apr 10, 2006 at 08:32:33PM +0200, Michael Gerz wrote:
> Hi all,
>
> FYI: I am still working on a patch that allows switching change tracking
> on and off without having to accept all changes.
>
> It turned out that this feature cannot be realized without modifying
> core parts of the Ly
Michael Gerz <[EMAIL PROTECTED]> writes:
| It turned out that this feature cannot be realized without modifying
| core parts of the LyX code. There is a special CT data structure that
| is only initialized when CT is activated. My approach is to set up the
| data structure even if CT is deactivate
Hi all,
FYI: I am still working on a patch that allows switching change tracking
on and off without having to accept all changes.
It turned out that this feature cannot be realized without modifying
core parts of the LyX code. There is a special CT data structure that is
only initialized whe
18 matches
Mail list logo
