]> code.delx.au - gnu-emacs/blobdiff - lisp/smerge-mode.el
(Abbrevs): A @node line without explicit Prev, Next, and Up links.
[gnu-emacs] / lisp / smerge-mode.el
index 31c7c4f2f1272a4c92bc9a49aa3e9dec20b4c7b0..8d9df18887532a6c2fcd92f32ddc4bd57e4e9aff 100644 (file)
@@ -1,10 +1,10 @@
 ;;; smerge-mode.el --- Minor mode to resolve diff3 conflicts
 
 ;; Copyright (C) 1999, 2000, 2001, 2002, 2003,
-;;   2004, 2005 Free Software Foundation, Inc.
+;;   2004, 2005, 2006 Free Software Foundation, Inc.
 
-;; Author: Stefan Monnier <monnier@cs.yale.edu>
-;; Keywords: revision-control merge diff3 cvs conflict
+;; Author: Stefan Monnier <monnier@iro.umontreal.ca>
+;; Keywords: tools revision-control merge diff3 cvs conflict
 
 ;; This file is part of GNU Emacs.
 
@@ -335,7 +335,17 @@ according to `smerge-match-conflict'.")
 
 (defun smerge-remove-props (beg end)
   (remove-overlays beg end 'smerge 'refine)
-  (remove-overlays beg end 'smerge 'conflict))
+  (remove-overlays beg end 'smerge 'conflict)
+  ;; Now that we use overlays rather than text-properties, this function
+  ;; does not cause refontification any more.  It can be seen very clearly
+  ;; in buffers where jit-lock-contextually is not t, in which case deleting
+  ;; the "<<<<<<< foobar" leading line leaves the rest of the conflict
+  ;; highlighted as if it were still a valid conflict.  Note that in many
+  ;; important cases (such as the previous example) we're actually called
+  ;; during font-locking so inhibit-modification-hooks is non-nil, so we
+  ;; can't just modify the buffer and expect font-lock to be triggered as in:
+  ;; (put-text-property beg end 'smerge-force-highlighting nil)
+  (remove-text-properties beg end '(fontified nil)))
 
 (defun smerge-popup-context-menu (event)
   "Pop up the Smerge mode context menu under mouse."