Mats Lidell writes:
>>>>> Skip wrote:
Skip> Copying the text and pasting to another buffer retains that
Skip> highlighting.
These are untested but are the right kind of thing. If you can't
easily get them to work, let me know and I'll fix it. Unfortunately
there doesn't seem to be an occur-mode-hook to allow you to do it
automatically in every occur buffer. An RFE in the tracker for these
features would not be out of line (but won't get attention from me
very quickly, sorry!)
To get rid of all highlighting entirely:
;; there's probably actually a function that does this, if nowhere
;; else, in Gnus :-)
(defun remove-all-highlighting (&optional start end)
;; this could be inconvenient, it will error if you don't have an
;; active region
(interactive "r")
(rationalize-interval-start-end)
(iterate-over-extents #'delete-extent start end))
To make all highlighting non-sticky:
(defun make-highlighting-unsticky (&optional start end)
;; this could be inconvenient, it will error if you don't have an
;; active region
(interactive "r")
(rationalize-interval-start-end)
(iterate-over-extents (lambda (e) (set-extent-property 'duplicable nil))
start end))
;; Very inefficient, there are several ways to iterate over extents
;; but the API is non-trivial.
(defun iterate-over-extents (function start end)
(let ((here start))
(while (< here end)
(mapc (lambda (e)
(when (and (>= (extent-start-position e) start)
(<= (extent-end-position e) end)
(= (extent-property e 'text-prop) 'face))
(funcall function e)))
(extents-at here))
(setq here (1+ here)))))
;; This horrible thing assumes START and END are arguments used to
;; represent the endpoints of a buffer region.
;; Since it's a defsubst, should be placed *before* it is used. Put
;; here for pedagogical reasons.
;; Might be useful to define as a macro (or maybe it already is :-).
(defsubst rationalize-interval-start-end ()
(setq start (or start (point-min))
end (or end (point-max)))
(psetq start (min start end)
end (max start end))
I have been hit by that at occasions too. I wonder now. Shouldn't
the
default be to just paste the text?
No; there is no good default here.
What is the reasoning behind pasting the whole extent? The need for
a good sister function pops up as well, like yank-text or
yank-extent depending on the default!?
It's an FSF-ism. This goes back to the early days of Lucid, and was
one of the reasons why RMS refused to accept the Lucid contribution.
RMS believed (and GNUbies still believe) that "text properties" should
be considered part of the text. This makes sense in some cases, for
example:
A *text property* is one, like the emphasis on the term defined,
which should be copied along with the text.
If you copy that definition, in general you do want to copy
the emphasis.
However, since in GNU Emacs at first there were *only* text
properties, and overlays are inconvenient for many purposes, and the
overlay API is also somewhat less convenient than the text property
API, text properties are widely abused in GNU Emacs and packages
written for it to add position- or mode-dependent properties that
should not (according to their semantics) be copied with the text.
RMS never grokked the point that the various properties which have
different values depending on whether an extent is used as a text
property or as an overlay are in principle independent of each other,
and it merely is the case that the configurations defining "text
property", "overlay", and now "field" are very common use cases.
However, such abstraction is anathema to RMSthought.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta