GNU bug report logs - #32991
27.0.50; diff-auto-refine-mode a no-op

Previous Next

Package: emacs;

Reported by: charles <at> aurox.ch

Date: Mon, 8 Oct 2018 18:28:01 UTC

Severity: normal

Tags: fixed

Found in version 27.0.50

Fixed in version 27.1

Done: charles <at> aurox.ch

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: charles <at> aurox.ch (Charles A. Roelli)
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 32991 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#32991: 27.0.50; diff-auto-refine-mode a no-op
Date: Sun, 03 Feb 2019 12:42:24 +0100
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Date: Fri, 01 Feb 2019 02:38:51 -0500
> 
> > A similar option `font-lock` also makes sense for a new
> > customizable variable with a name like `smerge-refine`
> > that could automatically refine all smerge conflicts.
> 
> FWIW, here's the reason why I haven't even looked into doing it
> automatically for smerge: IMO 2-way conflicts are worthless so I only
> care about 3-way conflicts, and for those I don't know how to display
> all 3 different "refinements" at the same time.  IOW I too often need to
> use the cycling behavior of smerge-refine for a "font-lock" version to
> be sufficient.  So if we implement a "font-lock" version of
> smerge-refine, we'll need to make sure it interacts well with subsequent
> manual smerge-refine cycling.

Why are 2-way conflicts worthless?  Automatically refining them could
be helpful in some situations.

By the way, does the updated change I sent in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32991#38 look okay to
you?




This bug report was last modified 6 years and 76 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.