From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.help Subject: Re: efficiently viewing Unix timestamps as dates Date: Wed, 04 May 2011 08:35:41 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87tyda7fma.fsf@lifelogs.com> References: <87mxo9mvxm.fsf@lifelogs.com> <87bp4la59u.fsf@lifelogs.com> <87fwtx5n3c.fsf@lifelogs.com> <87sjtk73tb.fsf@lifelogs.com> <877hav4fj9.fsf@lifelogs.com> <87r58ygyse.fsf@lifelogs.com> <87r58yf6zg.fsf@lifelogs.com> <87vcy7pbze.fsf@lifelogs.com> <87k4eijego.fsf@lifelogs.com> <877hahggrx.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306268584 17771 80.91.229.12 (24 May 2011 20:23:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 May 2011 20:23:04 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 24 22:23:00 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QOy83-0006mZ-CV for geh-help-gnu-emacs@m.gmane.org; Tue, 24 May 2011 22:22:59 +0200 Original-Received: from localhost ([::1]:44093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOy82-0002xC-To for geh-help-gnu-emacs@m.gmane.org; Tue, 24 May 2011 16:22:58 -0400 Original-Path: usenet.stanford.edu!news-transit.tcx.org.uk!news.albasani.net!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 48 Original-X-Trace: news.albasani.net gr21txYJjfc3PbbCzMvRZTLcg2Krm/W95NmIbj6dgRownrEn11sSot1rFU6H8ogcn9tWmMpyX72MK4q6s0M0Ug== Original-NNTP-Posting-Date: Wed, 4 May 2011 13:35:41 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="xSvud0KQpICSHV7l/J1X05xdiXBEily1BkKBtASmqu/HJ4HNzRhbBaKSO0aY1Di+RKcJ9c3o3SKmZHveVzAplAPttMuMGGToNkVVZpq0oiO0bvI7GRCFvAt7ZM0OdKn0"; mail-complaints-to="abuse@albasani.net" User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Cancel-Lock: sha1:WlFz33e7CFQcdEcdaQ4HOlUOS3U= sha1:8rfEpIYWxvjAkdTNYi8HuTWTLDg= Original-Xref: usenet.stanford.edu gnu.emacs.help:186780 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:81132 Archived-At: On Wed, 27 Apr 2011 11:18:29 -0300 Stefan Monnier 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