efficiently viewing Unix timestamps as dates

efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

Is there a mode to view (not convert!) Unix timestamps as dates?

It needs to be efficient because these are large files on remote
systems, and they are read-only so I can't modify them.

Ideally I would customize the time format and then turn this on as a
minor mode.  So I thought I'd ask if this already exists before I start
coding :)

Thanks
Ted

Re: efficiently viewing Unix timestamps as dates

[Kevin Rodgers]

On 12/13/10 10:20 AM, Ted Zlatanov wrote:
> Is there a mode to view (not convert!) Unix timestamps as dates?

What is a Unix timestamp, and how is it represented in Emacs Lisp (e.g. a
number or string or some other data type, and in what format)?

What is a date, and how is it represented in Emacs Lisp (i.e. a number or
string or some other data type, and in what format)?

> It needs to be efficient because these are large files on remote
> systems, and they are read-only so I can't modify them.
>
> Ideally I would customize the time format and then turn this on as a
> minor mode.  So I thought I'd ask if this already exists before I start
> coding :)

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Thu, 16 Dec 2010 00:28:38 -0700 Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote: 

KR> On 12/13/10 10:20 AM, Ted Zlatanov wrote:
>> Is there a mode to view (not convert!) Unix timestamps as dates?

KR> What is a Unix timestamp, and how is it represented in Emacs Lisp (e.g. a
KR> number or string or some other data type, and in what format)?

It's the number of seconds since the epoch, e.g. 

date '+%s'

or `M-x current-time' if you combine the first two integers, or 
`M-x float-time' if you round it.  Right now that's 1292527019 in
decimal.

KR> What is a date, and how is it represented in Emacs Lisp (i.e. a number or
KR> string or some other data type, and in what format)?

The Unix timestamp can be converted to a visual date with
`format-time-string', e.g.

M-: (format-time-string "%F %T" (current-time))

but the actual format string should be up to the user.  Really, my
question is "how do I find numbers that look like 1292527019, run a
function on them, and then show the results of that function overlaid on
top of the number without actually changing it in the buffer?"

Thanks
Ted

Re: efficiently viewing Unix timestamps as dates

[Burton Samograd]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 16 Dec 2010 00:28:38 -0700 Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote: 
> The Unix timestamp can be converted to a visual date with
> `format-time-string', e.g.
>
> M-: (format-time-string "%F %T" (current-time))

Or from the shell:

$ date --date=@1292532703
Thu Dec 16 13:51:43 MST 2010

--
Burton Samograd

Re: efficiently viewing Unix timestamps as dates

[PJ Weisberg]

On 12/16/10, Ted Zlatanov <tzz@lifelogs.com> wrote:

> question is "how do I find numbers that look like 1292527019, run a
> function on them, and then show the results of that function overlaid on
> top of the number without actually changing it in the buffer?"

Argh.  I don't actually know how to do the visual-only thing, but that
problem is complicated by the fact that the string "December 16, 2010"
(for example) contains TWO Unix timestamps, both in the early morning
hours of January 1, 1970.
-- 

-PJ

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

> but the actual format string should be up to the user.  Really, my
> question is "how do I find numbers that look like 1292527019, run a
> function on them, and then show the results of that function overlaid on
> top of the number without actually changing it in the buffer?"

The first part is rather tricky: "2" looks an awful lot like a Unix
timestamp ...wait... it *is* a Unix timestamp!
But assuming you know something about those time stamps, you can try
something like:

  (add-hook 'foo-mode-hook
            (lambda ()
              (font-lock-add-keywords nil
                '(("^[0-9]+"
                   (0 `(face nil display
                        ,(format-time-string "%F %T"
                           (seconds-to-time
                            (car (read-from-string
                                  (concat "1292527019" ".0"))))))))))))

where "^[0-9]+" is the regexp that matches your timestamps (in this
case I chose to assume they're always at the beginning of a line).


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Thu, 16 Dec 2010 17:23:34 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> but the actual format string should be up to the user.  Really, my
>> question is "how do I find numbers that look like 1292527019, run a
>> function on them, and then show the results of that function overlaid on
>> top of the number without actually changing it in the buffer?"

SM> The first part is rather tricky: "2" looks an awful lot like a Unix
SM> timestamp ...wait... it *is* a Unix timestamp!
SM> But assuming you know something about those time stamps, you can try
SM> something like:

SM>   (add-hook 'foo-mode-hook
SM>             (lambda ()
SM>               (font-lock-add-keywords nil
SM>                 '(("^[0-9]+"
SM>                    (0 `(face nil display
SM>                         ,(format-time-string "%F %T"
SM>                            (seconds-to-time
SM>                             (car (read-from-string
SM>                                   (concat "1292527019" ".0"))))))))))))

SM> where "^[0-9]+" is the regexp that matches your timestamps (in this
SM> case I chose to assume they're always at the beginning of a line).

I see a small bug in the last line, but I think it's fixable :)

On Thu, 16 Dec 2010 13:34:51 -0800 PJ Weisberg <pj@irregularexpressions.net> wrote: 

PW> Argh.  I don't actually know how to do the visual-only thing, but that
PW> problem is complicated by the fact that the string "December 16, 2010"
PW> (for example) contains TWO Unix timestamps, both in the early morning
PW> hours of January 1, 1970.

It's not so bad (I only bothered for dates after 2001 or 0-padded at the
beginning):

(add-hook 'foo-mode-hook
          (lambda ()
            (font-lock-add-keywords
             nil
             '(("[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"
                (0 `(face nil display
                          ,(format-time-string "%F %T"
                                               (seconds-to-time
                                                (car
                                                 (read-from-string
                                                  (concat
                                                   (match-string 0)
                                                   ".0"))))))))))))

I'd rather make this a minor mode than a hook, so I can easily turn it
on in a buffer.  Is that easy or hard to do?  Any specific example I can
look at?

Ted

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

> (add-hook 'foo-mode-hook
>           (lambda ()
>             (font-lock-add-keywords
>              nil
>              '(("[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"
>                 (0 `(face nil display
>                           ,(format-time-string "%F %T"
>                                                (seconds-to-time
>                                                 (car
>                                                  (read-from-string
>                                                   (concat
>                                                    (match-string 0)
>                                                    ".0"))))))))))))

> I'd rather make this a minor mode than a hook, so I can easily turn it
> on in a buffer.  Is that easy or hard to do?  Any specific example I can
> look at?

Use `define-minor-mode' rather than `add-hook'.


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 16 Dec 2010 17:12:23 -0600
> 
>              '(("[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"

Is something wrong with "[0-9]\{10\}"?

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Fri, 17 Dec 2010 10:25:47 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 16 Dec 2010 17:12:23 -0600
>> 
>> '(("[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"

EZ> Is something wrong with "[0-9]\{10\}"?

I was working on it (trying to refine the range) and forgot to post the
update.  I'll post it when I convert to a minor mode; my last version
was "\\<[0-9]\{8,11\}\\>" but that's not as nice as "[0-9]+" if you're
editing the text.

Ted

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Thu, 16 Dec 2010 21:35:10 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I'd rather make this a minor mode than a hook, so I can easily turn it
>> on in a buffer.  Is that easy or hard to do?  Any specific example I can
>> look at?

SM> Use `define-minor-mode' rather than `add-hook'.

Attached is my attempt to view numbers matching "\\<[0-9]\\{8,11\\}\\>"
as dates.  It works all right, but not perfectly.  I looked at
rainbow-mode.el for some of the setup and did some on my own.

It uses the `help-echo' text property, which means you have to use the
mouse to look at the date as a tooltip.  I didn't like how it looked
with the `display' property: you would hit backspace from a string of 8
digits to 7, and the display property would remain the previously
computed date.  If someone could explain how to display the calculated
date in some other way besides `help-echo', or how to use the margins or
something else to show the `help-echo' string, I'd really appreciate it.

Once this is ready I'll put it up on the GNU ELPA or wherever...  It's
really useful for me but others may not find it so useful.

Thanks
Ted


[-- Attachment #2: epoch-view.el --]
[-- Type: application/emacs-lisp, Size: 2719 bytes --]

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

> mouse to look at the date as a tooltip.  I didn't like how it looked
> with the `display' property: you would hit backspace from a string of 8
> digits to 7, and the display property would remain the previously
> computed date.

You have to explicit remove the `display' property before refreshing
with font-lock.  My sample code did not bother to do it because it was
just a proof of concept.

A naive way to do that is to add `display' to
font-lock-extra-managed-props, tho this will also remove `display'
properties added by other packages for other purposes.
So a better way is to add not just a `display' property but also another
property that is specific to your package, so that you can recognize
which `display' properties are yours, and then in font-lock-keywords you
can add a pseudo-keyword which will look for those display properties
and remove them.

Something like (untested):

 (defun foo-remove-display (limit)
   (let ((beg (point)))
     (while (< beg limit)
       (let ((next (next-single-property-change beg 'display nil end))
             (prop (get-text-property beg 'display)))
         (if (and prop (get-text-property beg 'foo-owned))
	     (put-text-property beg next 'display nil))
         (setq beg next))))
   nil)

 (add-hook 'foo-mode-hook
           (lambda ()
             (font-lock-add-keywords
              nil
              '((foo-remove-display)
                ("[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"
                 (0 `(face foo-owned t nil display
                           ,(format-time-string "%F %T"
                                                (seconds-to-time
                                                 (car
                                                  (read-from-string
                                                   (concat
                                                    (match-string 0)
                                                    ".0"))))))))))))

-- Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

On Fri, 15 Apr 2011 12:29:53 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> mouse to look at the date as a tooltip.  I didn't like how it looked
>> with the `display' property: you would hit backspace from a string of 8
>> digits to 7, and the display property would remain the previously
>> computed date.

SM> You have to explicit remove the `display' property before refreshing
SM> with font-lock.  My sample code did not bother to do it because it was
SM> just a proof of concept.

SM> A naive way to do that is to add `display' to
SM> font-lock-extra-managed-props, tho this will also remove `display'
SM> properties added by other packages for other purposes.
SM> So a better way is to add not just a `display' property but also another
SM> property that is specific to your package, so that you can recognize
SM> which `display' properties are yours, and then in font-lock-keywords you
SM> can add a pseudo-keyword which will look for those display properties
SM> and remove them.

I think the more careful method is a real pain (I couldn't figure it out
in a few hours of digging through the painful details), so I'd rather
override `display' naively.  I would have rather superimposed the date
somehow, like make the line height larger...  I was tempted to use SVG
to render it just how I want, but then it won't work without SVG support
and graphics.

If you want, tell me how to patch my code, attached here, to do it the
smart way.  It doesn't seem like a big deal but if you do...  As I said
I want to put it in the GNU ELPA so if the bar is higher for that
acceptance, I'll work on it some more.

Ted


[-- Attachment #2: epoch-view.el --]
[-- Type: application/emacs-lisp, Size: 2994 bytes --]

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

> If you want, tell me how to patch my code, attached here, to do it the
> smart way.

I sent you sample code in the previous message.  While untested, it's
partly cut&pasted from tex-mode.el, so it can't be very far
from working.


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Sun, 17 Apr 2011 11:38:39 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> If you want, tell me how to patch my code, attached here, to do it the
>> smart way.

SM> I sent you sample code in the previous message.  While untested, it's
SM> partly cut&pasted from tex-mode.el, so it can't be very far
SM> from working.

I don't understand why it should remove the display property
conditionally.  I want my package (epoch-view.el) to supercede any other
display properties for text that matches the epoch timestamp regular
expression, or it won't work properly (some text will not have the
display property I want it to have).  You can argue that the other
packages' display property may be important, but I think mine is
important too.

Should I augment the display property, appending my text to the existing
text, if any?  It seems like the problem is really that there's only one
display property.

My main question, though: is this OK for inclusion in the GNU ELPA as it
is, or do you want the display property issue hammered out beforehand,
or are there other reasons not to include it?

Thanks
Ted

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

> I don't understand why it should remove the display property
> conditionally.  I want my package (epoch-view.el) to supercede any other
> display properties for text that matches the epoch timestamp regular
> expression, or it won't work properly (some text will not have the
> display property I want it to have).  You can argue that the other
> packages' display property may be important, but I think mine is
> important too.

The issue is to not remove the display property placed on *other*
chunks of text.


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Tue, 19 Apr 2011 12:23:45 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I don't understand why it should remove the display property
>> conditionally.  I want my package (epoch-view.el) to supercede any other
>> display properties for text that matches the epoch timestamp regular
>> expression, or it won't work properly (some text will not have the
>> display property I want it to have).  You can argue that the other
>> packages' display property may be important, but I think mine is
>> important too.

SM> The issue is to not remove the display property placed on *other*
SM> chunks of text.

The package only applies the display property to text it matches.  Where
is the display property removed through the font-lock mechanism by my
package?  Here are the keywords in question (`epoch-view-render' applies
the display property).

(defvar epoch-view-font-lock-keywords
  '(("\\<[0-9]\\{8,11\\}\\>"
     (0 (epoch-view-render))))
  "Font-lock keywords of epoch timestamps.")

(defun epoch-view-render ()
  "Render a epoch match."
  (let ((text (match-string-no-properties 0)))
    `(face font-lock-warning-face
           display ,(epoch-view--render text))))

(defun epoch-view-turn-on ()
  "Turn on epoch-view-mode."
  (let ((props (make-local-variable 'font-lock-extra-managed-props)))
    (add-to-list props 'display))

  (font-lock-add-keywords nil epoch-view-font-lock-keywords))

Sorry if I seem dense but I really don't get what's causing this
problem.  It would be helpful if you could tell me what mode, combined
with `epoch-view-mode', will exhibit the problem.

Thanks
Ted

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

SM> The issue is to not remove the display property placed on *other*
SM> chunks of text.
> The package only applies the display property to text it matches.

Yes, but you do want to remove that property at some point.
Using font-lock-extra-managed-props is asking font-lock to take complete
control of the property (i.e. it causes font-lock-fontify-region to
start by erasing the `display' property over the whole fontified region)
so if the display property is set by a package that doesn't use
font-lock, that will be lost.


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Thu, 21 Apr 2011 17:20:58 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> The issue is to not remove the display property placed on *other*
SM> chunks of text.
>> The package only applies the display property to text it matches.

SM> Yes, but you do want to remove that property at some point.

Why remove it?  Do you mean when the package is turned off, or at some
point in the redisplay process?

SM> Using font-lock-extra-managed-props is asking font-lock to take complete
SM> control of the property (i.e. it causes font-lock-fontify-region to
SM> start by erasing the `display' property over the whole fontified region)
SM> so if the display property is set by a package that doesn't use
SM> font-lock, that will be lost.

Hmm, does Emacs need a `font-lock-display' property, to be used iff
`display' is not specified?  This seems like a lot of pain that should
not be passed to the package authors but handled in the core.

Are there packages that set `display' without letting font-lock manage
it?  I want to test the code you suggested against something that
actually breaks with epoch-view.el.

My previous question remains: is this serious enough that epoch-view.el
should not go in the GNU ELPA until it's fixed, or is it a minor bug I
can work on later?

Ted

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

SM> The issue is to not remove the display property placed on *other*
SM> chunks of text.
>>> The package only applies the display property to text it matches.
SM> Yes, but you do want to remove that property at some point.
> Why remove it?  Do you mean when the package is turned off, or at some
> point in the redisplay process?

I mean when the text gets modified so it doesn't represent a timestamp
any more.  [ When the user turns off the mode would be good as
well, tho I didn't pay any attention to this case.  ]

> Hmm, does Emacs need a `font-lock-display' property, to be used iff
> `display' is not specified?  This seems like a lot of pain that should
> not be passed to the package authors but handled in the core.

Well, I do think Emacs should make it easier for various packages to use
the same property without stepping on each other's toes, but right now
there isn't any good support for that.  The font-lock-face thingy is
kind of a solution, but I don't think it's very convincing and would
rather not use it for more things.
I've already outlined the way I think things should work, on emacs-devel
a few months ago.

> Are there packages that set `display' without letting font-lock
> manage it?

I can think of a good bunch, but they're all special-modes, so not used
on files.

> My previous question remains: is this serious enough that epoch-view.el
> should not go in the GNU ELPA until it's fixed, or is it a minor bug I
> can work on later?

It's not serious, no.  And packages don't need to be flawless in order
to be accepted for GNU ELPA, as should be evident if you look at many of
the packages included in Emacs ;-)


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Sun, 24 Apr 2011 02:18:49 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> The issue is to not remove the display property placed on *other*
SM> chunks of text.
>> Hmm, does Emacs need a `font-lock-display' property, to be used iff
>> `display' is not specified?  This seems like a lot of pain that should
>> not be passed to the package authors but handled in the core.

SM> Well, I do think Emacs should make it easier for various packages to
SM> use the same property without stepping on each other's toes, but
SM> right now there isn't any good support for that.  The font-lock-face
SM> thingy is kind of a solution, but I don't think it's very convincing
SM> and would rather not use it for more things.  I've already outlined
SM> the way I think things should work, on emacs-devel a few months ago.

OK.  Would you say this is on the TODO list for Emacs 24.x, 25.x, or
"some day"?

>> Are there packages that set `display' without letting font-lock
>> manage it?

SM> I can think of a good bunch, but they're all special-modes, so not used
SM> on files.

OK, so it's typically not an issue today but could become a problem.

>> My previous question remains: is this serious enough that epoch-view.el
>> should not go in the GNU ELPA until it's fixed, or is it a minor bug I
>> can work on later?

SM> It's not serious, no.  And packages don't need to be flawless in order
SM> to be accepted for GNU ELPA, as should be evident if you look at many of
SM> the packages included in Emacs ;-)

Heh, yes, if my code can make it in, anything goes :)

I'll commit epoch-view.el to the ELPA with a note about clashing
`display' properties as you suggested.  Then I'll work on it sooner or
later depending on how soon you think the multiple property support will
happen.

Thanks for your patience.

Ted

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Mon, 25 Apr 2011 14:52:39 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I'll commit epoch-view.el to the ELPA with a note about clashing
TZ> `display' properties as you suggested.  Then I'll work on it sooner or
TZ> later depending on how soon you think the multiple property support will
TZ> happen.

This is done to the Bazaar repository but I didn't deploy.  Please check
my commit and let me know if I need to change anything.

Thanks
Ted

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

SM> Well, I do think Emacs should make it easier for various packages to
SM> use the same property without stepping on each other's toes, but
SM> right now there isn't any good support for that.  The font-lock-face
SM> thingy is kind of a solution, but I don't think it's very convincing
SM> and would rather not use it for more things.  I've already outlined
SM> the way I think things should work, on emacs-devel a few months ago.

> OK.  Would you say this is on the TODO list for Emacs 24.x, 25.x, or
> "some day"?

It's been on the TODO list for a while already.  Actually, I think it's
reasonably easy to do (all the work is done when the properties are
added/removed, so there's no need to touch any of the redisplay code).


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Tue, 26 Apr 2011 10:28:03 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Well, I do think Emacs should make it easier for various packages to
SM> use the same property without stepping on each other's toes, but
SM> right now there isn't any good support for that.  The font-lock-face
SM> thingy is kind of a solution, but I don't think it's very convincing
SM> and would rather not use it for more things.  I've already outlined
SM> the way I think things should work, on emacs-devel a few months ago.

>> OK.  Would you say this is on the TODO list for Emacs 24.x, 25.x, or
>> "some day"?

SM> It's been on the TODO list for a while already.  Actually, I think it's
SM> reasonably easy to do (all the work is done when the properties are
SM> added/removed, so there's no need to touch any of the redisplay code).

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.

Thanks
Ted

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

> 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.

The idea is the following:

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

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

The implementation would go something like:

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

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

-- Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

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

Re: efficiently viewing Unix timestamps as dates

[Stefan Monnier]

> 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.

Yes, of course, we wouldn't do it a char at a time.  The code was just
illustrating the kind of semantics you could expect.

> So the default plane is nil?

That would be a natural choice, but any value would do.

> 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" :)

Actually, I really don't think this needs that much work.
The change should be localized, and in code which is not tricky.

It will probably introduce a few minor backward compatibility issues,
mostly around the need to distinguish "get the merged value of property
`foo'" and "get the value of property `foo' in the default plane".


        Stefan

Re: efficiently viewing Unix timestamps as dates

[Ted Zlatanov]

On Wed, 04 May 2011 12:32:34 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> 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" :)

SM> Actually, I really don't think this needs that much work.
SM> The change should be localized, and in code which is not tricky.

SM> It will probably introduce a few minor backward compatibility issues,
SM> mostly around the need to distinguish "get the merged value of property
SM> `foo'" and "get the value of property `foo' in the default plane".

Thanks for explaining.  I'll be first in line to test it with epoch-view.el.

Ted