help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: efficiently viewing Unix timestamps as dates


From: Ted Zlatanov
Subject: Re: efficiently viewing Unix timestamps as dates
Date: Tue, 24 May 2011 20:01:47 -0000
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Wed, 27 Apr 2011 11:18:29 -0300 Stefan Monnier <monnier@iro.umontreal.ca> 
wrote: 

>> I was definitely not paying careful attention to that discussion when it
>> happened on emacs-devel.  Can you give some references so I can catch up
>> with what needs to be done, since "display" and "properties" return too
>> many matches?  Even if I don't work on it I can at least understand the
>> history.

SM> The idea is the following:

SM> We add a notion of "plane" to text-properties.  So, for example,
SM> font-lock would set the `face' property (and any other property it feels
SM> like setting) in the `font-lock' plane.  When font-lock needs to erase
SM> the properties it has set, it just erases the `font-lock' plane which
SM> guarantees that all the properties in that plane are removed (so you
SM> don't need font-lock-extra-managed-props any more) and none of the
SM> properties of other planes are affected (so you don't risk erasing
SM> other packages's properties).

SM> The text-property value at a particular point is the combination of the
SM> value for each existing plane.  The combination can be done via `or' or
SM> via some more sophisticated merge operator (the merge operator can be
SM> specified on a per-property basis, so `face' can be merged differently
SM> from `keymap' or `invisible').

As long as the merge is smart this should work: if you have
plane=1,face=A on (0, 5) and plane=2,face=B on (3, 10) the merge should
be called just once for the region between 3 and 5.  I assume that's how
you picture it too, though `re-merge-property' below doesn't do it.

SM> The implementation would go something like:

SM> (defun new-put-text-property (start end prop val &optional object)
SM>   (let ((plane (if (consp prop) (prog1 (car prop) (setq prop (cdr prop))))))
SM>     (old-put-text-property start end (cons plane prop) val object)
SM>     (re-merge-property start end prop object)))

SM> (defun re-merge-property (start end prop object)
SM>   (for all i from start to end
SM>     (old-put-text-property x (1+ x) prop
SM>                            (funcall (merger-function prop)
SM>                                     (collect-values-from-planes i prop)))))

So the default plane is nil?  That seems OK and backwards compatible.
But I don't know enough about the internals to say how much work this
will be; I would guess "a lot" :)

Ted


reply via email to

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