unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: master daea9b3 1/2: Read mailcaps again only when necessary
       [not found] ` <20211101135346.2EBEB20B72@vcs0.savannah.gnu.org>
@ 2021-11-01 16:56   ` Stefan Monnier
  2021-11-01 17:01     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-11-01 16:56 UTC (permalink / raw)
  To: emacs-devel; +Cc: Gregory Heytings

> +(defun file-has-changed-p (file)
> +  "Return non-nil if FILE has changed.
> +The modification time of FILE is compared to the modification
> +time of FILE during a previous invocation of `file-has-changed-p'.
> +Therefore the first invocation of `file-has-changed-p' always
> +returns non-nil."
> +  (let* ((attr (file-attributes file 'integer))
> +	  (mtime (file-attribute-modification-time attr))
> +	  (saved-mtime (gethash (intern file)
> +				file-has-changed-p--hash-table)))
> +     (when (not (equal mtime saved-mtime))
> +       (puthash (intern file) mtime file-has-changed-p--hash-table))))

This API doesn't seem safe.
If two packages read&parse the same file and both rely on this function
to decide when to reparse, the second package can get a nil value
(because the first has caused the mtime to be reset in the hash table)
even though the file has changed since it last parsed it.

So I think the function needs a second argument which represents the
"since when".  It could be the hash-table.

Side question: why use `intern`?
Why not just pass `:test #'equal` to the `make-hash-table`?


        Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 16:56   ` master daea9b3 1/2: Read mailcaps again only when necessary Stefan Monnier
@ 2021-11-01 17:01     ` Lars Ingebrigtsen
  2021-11-01 17:19       ` Eli Zaretskii
  2021-11-01 18:06       ` Stefan Monnier
  0 siblings, 2 replies; 20+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-01 17:01 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Gregory Heytings, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> If two packages read&parse the same file and both rely on this function
> to decide when to reparse, the second package can get a nil value
> (because the first has caused the mtime to be reset in the hash table)
> even though the file has changed since it last parsed it.

I think that's up to the higher level to decide whether it's a problem
or not, like with other memoizing functions.

(And relatedly, this function shouldn't use file-truename or anything on
the filename -- it's a string used as the key.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 17:01     ` Lars Ingebrigtsen
@ 2021-11-01 17:19       ` Eli Zaretskii
  2021-11-01 17:21         ` Lars Ingebrigtsen
  2021-11-01 18:06       ` Stefan Monnier
  1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2021-11-01 17:19 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: gregory, monnier, emacs-devel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 01 Nov 2021 18:01:56 +0100
> Cc: Gregory Heytings <gregory@heytings.org>, emacs-devel@gnu.org
> 
> (And relatedly, this function shouldn't use file-truename or anything on
> the filename -- it's a string used as the key.)

??? Then how do I tell the function which file do I want it to report
on?



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 17:19       ` Eli Zaretskii
@ 2021-11-01 17:21         ` Lars Ingebrigtsen
  2021-11-01 17:24           ` Eli Zaretskii
  0 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-01 17:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gregory, monnier, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> (And relatedly, this function shouldn't use file-truename or anything on
>> the filename -- it's a string used as the key.)
>
> ??? Then how do I tell the function which file do I want it to report
> on?

???  You give it a filename, which is a string.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 17:21         ` Lars Ingebrigtsen
@ 2021-11-01 17:24           ` Eli Zaretskii
  2021-11-01 17:29             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2021-11-01 17:24 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: gregory, monnier, emacs-devel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Mon, 01 Nov 2021 18:21:38 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> (And relatedly, this function shouldn't use file-truename or anything on
> >> the filename -- it's a string used as the key.)
> >
> > ??? Then how do I tell the function which file do I want it to report
> > on?
> 
> ???  You give it a filename, which is a string.  

What if we have the same file name in several different directories --
how will you record the files so they all get different hash slots?



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 17:24           ` Eli Zaretskii
@ 2021-11-01 17:29             ` Lars Ingebrigtsen
  2021-11-01 18:13               ` Eli Zaretskii
  2021-11-01 18:20               ` Stefan Monnier
  0 siblings, 2 replies; 20+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-01 17:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gregory, monnier, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> What if we have the same file name in several different directories --
> how will you record the files so they all get different hash slots?

Oh, you mean relative file names?  I think it's up to the caller to
decide.  If they don't want that, then give an absolute file name, and
if they do want that, then don't.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 17:01     ` Lars Ingebrigtsen
  2021-11-01 17:19       ` Eli Zaretskii
@ 2021-11-01 18:06       ` Stefan Monnier
  2021-11-01 18:48         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-11-01 18:06 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel, Gregory Heytings

Lars Ingebrigtsen [2021-11-01 18:01:56] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> If two packages read&parse the same file and both rely on this function
>> to decide when to reparse, the second package can get a nil value
>> (because the first has caused the mtime to be reset in the hash table)
>> even though the file has changed since it last parsed it.
> I think that's up to the higher level to decide whether it's a problem
> or not, like with other memoizing functions.

What higher level?  I'm talking about two separate packages that don't
know each other, so there's no higher level magic that will save us.


        Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 17:29             ` Lars Ingebrigtsen
@ 2021-11-01 18:13               ` Eli Zaretskii
  2021-11-01 18:35                 ` Stefan Monnier
  2021-11-01 18:20               ` Stefan Monnier
  1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2021-11-01 18:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: gregory, monnier, emacs-devel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Mon, 01 Nov 2021 18:29:12 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What if we have the same file name in several different directories --
> > how will you record the files so they all get different hash slots?
> 
> Oh, you mean relative file names?  I think it's up to the caller to
> decide.  If they don't want that, then give an absolute file name, and
> if they do want that, then don't.

But that's contrary to every other Emacs function that accepts file
names.  They all interpret the file names relative to the
default-directory.  And so do the primitives the current
implementation of file-has-changed-p: they expand the file name
internally.  But the file name that gets recorded in the hash table
does not follow that rule, and that is the problem.  because this way
it makes no sense to use relative file names, unless the caller asks
for trouble.  So in practice, every caller will have to pass an
absolute file name, which again is different from all the other APIs
we have that accept file names.

Once again, the key for recording the time stamp is the file name you
pass, so that key must be unique, and that means file-truename.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 17:29             ` Lars Ingebrigtsen
  2021-11-01 18:13               ` Eli Zaretskii
@ 2021-11-01 18:20               ` Stefan Monnier
  2021-11-01 18:31                 ` Eli Zaretskii
  1 sibling, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-11-01 18:20 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, gregory, emacs-devel

Lars Ingebrigtsen [2021-11-01 18:29:12] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> What if we have the same file name in several different directories --
>> how will you record the files so they all get different hash slots?
> Oh, you mean relative file names?  I think it's up to the caller to
> decide.  If they don't want that, then give an absolute file name, and
> if they do want that, then don't.

To avoid disappointment, it makes sense to pass the filename through
`expand-file-name` or to signal an error if the file name is not
absolute.


        Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 18:20               ` Stefan Monnier
@ 2021-11-01 18:31                 ` Eli Zaretskii
  0 siblings, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2021-11-01 18:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: larsi, gregory, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Mon, 01 Nov 2021 14:20:41 -0400
> 
> Lars Ingebrigtsen [2021-11-01 18:29:12] wrote:
> > Eli Zaretskii <eliz@gnu.org> writes:
> >> What if we have the same file name in several different directories --
> >> how will you record the files so they all get different hash slots?
> > Oh, you mean relative file names?  I think it's up to the caller to
> > decide.  If they don't want that, then give an absolute file name, and
> > if they do want that, then don't.
> 
> To avoid disappointment, it makes sense to pass the filename through
> `expand-file-name` or to signal an error if the file name is not
> absolute.

Why signal an error when the function can make the file name absolute
so easily?  It makes no sense.  No other API that accepts file names
does that, AFAIK.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 18:13               ` Eli Zaretskii
@ 2021-11-01 18:35                 ` Stefan Monnier
  2021-11-01 18:56                   ` Eli Zaretskii
  0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-11-01 18:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, gregory, emacs-devel

> Once again, the key for recording the time stamp is the file name you
> pass, so that key must be unique, and that means file-truename.

I'm not sure `file-truename` is indispensable or even desirable.
E.g.:

- read file ~/fileA which is a symlink to /foo/A,
  with `file-truename` when `file-changed-p` is called it records that
  /foo/A has timestamp T1.
- read ~/fileB which is a normal file.  When `file-changed-p` is called it
  records that ~/fileB has timestamp T2.
- user changes ~/fileB into a symlink to /foo/A
- we go and check whether ~/fileB has changed: when `file-changed-p` is
  called it passes it to `file-truename` before it looks up the
  hash-table; it then sees that it's still T1 and will say "everything
  good, ~/fileB hasn't changed".


-- Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 18:06       ` Stefan Monnier
@ 2021-11-01 18:48         ` Lars Ingebrigtsen
  2021-11-01 18:50           ` Stefan Monnier
  0 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-01 18:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Gregory Heytings, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> What higher level?  I'm talking about two separate packages that don't
> know each other, so there's no higher level magic that will save us.

That's true, and we could add a "namespace" parameter -- but...

If we really want to overengineer this, we'd make a file-cache object
that stores both the file name, the file metadata, and the cached data.

Well, come to think of it, perhaps that'd be nice as an interface?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 18:48         ` Lars Ingebrigtsen
@ 2021-11-01 18:50           ` Stefan Monnier
  2021-11-01 19:04             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-11-01 18:50 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel, Gregory Heytings

Lars Ingebrigtsen [2021-11-01 19:48:16] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> What higher level?  I'm talking about two separate packages that don't
>> know each other, so there's no higher level magic that will save us.
> That's true, and we could add a "namespace" parameter -- but...
> If we really want to overengineer this, we'd make a file-cache object
> that stores both the file name, the file metadata, and the cached data.
> Well, come to think of it, perhaps that'd be nice as an interface?

That's pretty close to my suggestion to pass the hash-table as a second
arg, yes.


        Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 18:35                 ` Stefan Monnier
@ 2021-11-01 18:56                   ` Eli Zaretskii
  2021-11-01 21:07                     ` Stefan Monnier
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2021-11-01 18:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: larsi, gregory, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  gregory@heytings.org,
>   emacs-devel@gnu.org
> Date: Mon, 01 Nov 2021 14:35:00 -0400
> 
> > Once again, the key for recording the time stamp is the file name you
> > pass, so that key must be unique, and that means file-truename.
> 
> I'm not sure `file-truename` is indispensable or even desirable.
> E.g.:
> 
> - read file ~/fileA which is a symlink to /foo/A,
>   with `file-truename` when `file-changed-p` is called it records that
>   /foo/A has timestamp T1.
> - read ~/fileB which is a normal file.  When `file-changed-p` is called it
>   records that ~/fileB has timestamp T2.
> - user changes ~/fileB into a symlink to /foo/A
> - we go and check whether ~/fileB has changed: when `file-changed-p` is
>   called it passes it to `file-truename` before it looks up the
>   hash-table; it then sees that it's still T1 and will say "everything
>   good, ~/fileB hasn't changed".

That's why I think we should also record the size and the inode, and
we probably should do that before taking file-truename.  The latter is
just for recording.

Of course, the situation you described is also highly improbable: why
should the same program care about two files in exactly that sequence
as to make your point for you?  What are the chances of that?



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 18:50           ` Stefan Monnier
@ 2021-11-01 19:04             ` Lars Ingebrigtsen
  2021-11-01 21:31               ` Stefan Monnier
  0 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-01 19:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Gregory Heytings, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That's pretty close to my suggestion to pass the hash-table as a second
> arg, yes.

Sort of something like:

(setq mailcap-data
      (file-refresh-if-changed
       (or mailcap-data (make-instance 'file-data-cache
                                       :file "/etc/mailcap"
                                       :refresher #'mailcap-parse-file))))

and then the data would be in

(slot-value mailcap-data 'data)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 18:56                   ` Eli Zaretskii
@ 2021-11-01 21:07                     ` Stefan Monnier
  2021-11-02 12:54                       ` Eli Zaretskii
  0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-11-01 21:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, gregory, emacs-devel

> That's why I think we should also record the size and the inode, and
> we probably should do that before taking file-truename.  The latter is
> just for recording.

There's a case to be made to just store most of the output of
`file-attributes`, indeed, instead of just the modification time.

> Of course, the situation you described is also highly improbable: why
> should the same program care about two files in exactly that sequence
> as to make your point for you?  What are the chances of that?

Maybe it's highly unlikely, indeed.

But I don't see what's the benefit of calling `file-truename`: I know it
makes it slower and introduces an (unlikely) broken corner case, but
what's the upside?


        Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 19:04             ` Lars Ingebrigtsen
@ 2021-11-01 21:31               ` Stefan Monnier
  2021-11-02 14:54                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-11-01 21:31 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel, Gregory Heytings

Lars Ingebrigtsen [2021-11-01 20:04:33] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> That's pretty close to my suggestion to pass the hash-table as a second
>> arg, yes.
>
> Sort of something like:
>
> (setq mailcap-data
>       (file-refresh-if-changed
>        (or mailcap-data (make-instance 'file-data-cache
>                                        :file "/etc/mailcap"
>                                        :refresher #'mailcap-parse-file))))
>
> and then the data would be in
>
> (slot-value mailcap-data 'data)

I don't see any need to bring in EIEIO into this (remember that EIEIO
objects and operations are slow).

I was thinking more along the lines of

    (defun file-contents-attributes (file)
      (let ((a (file-attributes file)))
        ;; Stamp out data that will never reflect a change in the file.
        (setf (file-attribute-access-time a) nil)
        (setf (file-attribute-link-number a) nil)
        a))

    (defun file-unchanged-p (file cache)
      (unless (file-name-absolute-p file) (setq file (expand-file-name file)))
      (let ((old (gethash (cons file 'file-contents-attributes) cache))
            (new (file-contents-attributes file)))
        (if (equal old new)
            t
          (puthash (cons file 'file-contents-attributes) new cache)
          nil)))

    (defun mailcap-parse-file (file &optional cache)
      (unless (file-name-absolute-p file) (setq file (expand-file-name file)))
      (or (and cache
               (file-unchanged-p file cache)
               (gethash (cons file 'mailcap-parse-file) cache))
          (let ((data <do the actual parsing>))
            (when cache
              (puthash (cons file 'mailcap-parse-file) data cache))
            data)))


-- Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 21:07                     ` Stefan Monnier
@ 2021-11-02 12:54                       ` Eli Zaretskii
  2021-11-02 13:51                         ` Stefan Monnier
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2021-11-02 12:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: larsi, gregory, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Mon, 01 Nov 2021 17:07:12 -0400
> 
> But I don't see what's the benefit of calling `file-truename`: I know it
> makes it slower and introduces an (unlikely) broken corner case, but
> what's the upside?

It will avoid several false responses, with symlinks and on
filesystems with special "features", like case-insensitivity.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-02 12:54                       ` Eli Zaretskii
@ 2021-11-02 13:51                         ` Stefan Monnier
  0 siblings, 0 replies; 20+ messages in thread
From: Stefan Monnier @ 2021-11-02 13:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, gregory, emacs-devel

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: larsi@gnus.org,  gregory@heytings.org,  emacs-devel@gnu.org
>> Date: Mon, 01 Nov 2021 17:07:12 -0400
>> 
>> But I don't see what's the benefit of calling `file-truename`: I know it
>> makes it slower and introduces an (unlikely) broken corner case, but
>> what's the upside?
>
> It will avoid several false responses, with symlinks and on
> filesystems with special "features", like case-insensitivity.

I can see cases where using `file-truename` will return slightly less
pessimistic results, e.g. if we test "FooBar" after having tested
"foobar" it may avoid deciding it's changed even tho it wasn't.
But that seems like a very minor advantage (such pessimistic results
are largely unavoidable, so code should be prepared to work correctly
in their presence anyway).


        Stefan




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: master daea9b3 1/2: Read mailcaps again only when necessary
  2021-11-01 21:31               ` Stefan Monnier
@ 2021-11-02 14:54                 ` Lars Ingebrigtsen
  0 siblings, 0 replies; 20+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-02 14:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Gregory Heytings, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>     (defun mailcap-parse-file (file &optional cache)
>       (unless (file-name-absolute-p file) (setq file (expand-file-name file)))
>       (or (and cache
>                (file-unchanged-p file cache)
>                (gethash (cons file 'mailcap-parse-file) cache))
>           (let ((data <do the actual parsing>))
>             (when cache
>               (puthash (cons file 'mailcap-parse-file) data cache))
>             data)))

That does have the advantage that the package can store the data for
many files in the same place, which is nice.  But the interface doesn't
seem as clear as it could be.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-11-02 14:54 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20211101135344.25800.81476@vcs0.savannah.gnu.org>
     [not found] ` <20211101135346.2EBEB20B72@vcs0.savannah.gnu.org>
2021-11-01 16:56   ` master daea9b3 1/2: Read mailcaps again only when necessary Stefan Monnier
2021-11-01 17:01     ` Lars Ingebrigtsen
2021-11-01 17:19       ` Eli Zaretskii
2021-11-01 17:21         ` Lars Ingebrigtsen
2021-11-01 17:24           ` Eli Zaretskii
2021-11-01 17:29             ` Lars Ingebrigtsen
2021-11-01 18:13               ` Eli Zaretskii
2021-11-01 18:35                 ` Stefan Monnier
2021-11-01 18:56                   ` Eli Zaretskii
2021-11-01 21:07                     ` Stefan Monnier
2021-11-02 12:54                       ` Eli Zaretskii
2021-11-02 13:51                         ` Stefan Monnier
2021-11-01 18:20               ` Stefan Monnier
2021-11-01 18:31                 ` Eli Zaretskii
2021-11-01 18:06       ` Stefan Monnier
2021-11-01 18:48         ` Lars Ingebrigtsen
2021-11-01 18:50           ` Stefan Monnier
2021-11-01 19:04             ` Lars Ingebrigtsen
2021-11-01 21:31               ` Stefan Monnier
2021-11-02 14:54                 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).