[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: smerge-match-conflict]

From: Stefan Monnier
Subject: Re: address@hidden: smerge-match-conflict]
Date: Wed, 14 Nov 2001 20:29:48 -0500

> This is really two bugs in the same function, one of them being fixed
> in the included patch, but the other not.  My reason for reporting them
> together is that the best way I know of showing them is with the same
> example.
> Explanation and partial fix
> - ---------------------------
> Note that the buffer bar<2> now contains
>       <<<<<<< bar
>       text2=======
>       text1>>>>>>> 1.2
> Since the "========" sequence doesn't start on a new line
> smerge-match-conflict doesn't find it with the help of
> smerge-other-re.  If I terminate the contents of the "bar" files with
> newline there is no problem.  So this is bug #1.  I guess looking for
> "=======" that doesn't start a new line might produce too many
> false hits.  Maybe "(diff)Merging Incomplete Lines" is of use here.
> Or maybe it's not worth fixing this.
> Anyway, when smerge-find-conclict calls smerge-match-conflict it will
> ignore-errors, but smerge-match-conflict doesn't yield an error since
> it does ignore-errors itself, and only returns the string
> "Point not in conflict region" when the search for smerge-other-re
> doesn't succeed.  The documentation for smerge-match-conflict says
> that
>       An error is raised if not inside a conflict.
> But it doesn't, and that is bug #2.  This change makes that so.  I
> made smerge-match-conflict only catch search-failed errors, since that
> is the only error it is prepared for, as far as I understand.

The patch was correct.  It was obviously a typo.
I have committed it to both branches of Emacs' CVS repository.
I haven't had time to look into fixing the bug #1 yet.
Thank you,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]