[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lyx-devel
Subject:    Re: [PATCH] Change tracking hacking
From:       Johnathan Burchill <jkerrb () users ! sourceforge ! net>
Date:       2005-02-21 0:51:02
Message-ID: 200502201751.09252.jkerrb () users ! sourceforge ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Lars Gullik Bjønnes wrote:

>Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
>| Lars Gullik Bjønnes wrote:
>>
>>> I am very happy to see bugs fixed. but I am a bit wary of adding
>>> functionality at this stage. 
>>
>| It's a bug fix really. The unability to break paragraphs is a severe (and
>| the biggest remaining AFAICS) limitation of the change tracker (see bug
>| 880).
>
>That is a limitation and missing functionality, not really a bug.
>(even if it has a bug number)

I agree; not being able to break "unchanged" paragraphs was intentionally 
disabled from the change-tracking algorithm. Providing this feature requires 
quite a lot of modification to the source code, spanning several files, 
including

1) a new inset, called InsetNewparagraph, analogous to InsetNewline. It is a 
placeholder that indicates a new paragraph was inserted within unchanged 
text. It is removed when explicitly deleted by "Backspace", or (unlike 
InsetNewline) the change is accepted during a merge.

This part was included in the initial attachment that goes with this thread.

2) making sure that every lyx command that alters the cursor position checks 
to see if it should do something special upon finding an InsetNewparagraph. 
That is, the cursor should never appear to the right of the inset (in 
Left-To-Right mode), and backspace at the beginning of a paragraph should 
merge it with the previous paragraph if the previous paragraph ends with an 
InsetNewparagraph. And so on.

As I found out this week, only part of this was accomplished in the initial 
patch. I gotta say, the cursor positioning code seems linear. Would be nice 
if I could've added a new inset, and defined within its implementation how it 
responds to cursor movement, instead of chasing down all the special cases in 
text.C, text2.C, text3.C, paragraph_funcs.C, etc... Maybe I've got the wrong 
idea altogether on how to break paragraphs in change tracking --- discussion 
welcome :).

3) adding the ability to merge unchanged paragraphs together. That could be 
accomplished by putting a (Change::Type) Change::DELETED InsetNewparagraph 
between the two paragraphs as a placeholder during change tracking.

It all seems hackish, but that's the best I've been able to come up with for 
breaking paragraphs. Points (2) and (3) above should discourage you from 
implementing this feature in the first 1.4 release if you're now in feature 
freeze mode.

>
>I am not alian to letting this improvement in, but I'd like it
>separate from the bug fix.
>
>>> Are you able to split up the patch to 
>>> keep the bugfix and the new functionality separate?
>>
>| That would be good anyway.
>
>yes.

I've attached the bug fix. There's no point in providing the break-paragraph 
patch until it's fully functional. If you want to play with it, see my first 
attachment in this thread. Whether or not you want to implement the 
functionality in 1.4.0, I'll work on it in the meantime, and provide patches 
as she goes.

>
>-- 
>        Lgb

Cheers,
JB

-- 
Johnathan K. Burchill, Ph.D.
jkerrb@users.sourceforge.net

[Attachment #5 (application/pgp-signature)]
["lyx-bug-1277-fix.diff.gz" (application/x-gzip)]

[prev in list] [next in list] [prev in thread] [next in thread]