Hi Bastien,
At Thu, 21 Jul 2011 11:52:44 +0200,
Bastien wrote:
> :
> > I'm also think about cache in the calfw side, such as an alist:
> > (date . [a list of contents]). Then, uses can refresh the cache
> > explicitly. It is easy to implement.
> >
> > Is the plan(1) the same idea?
>
> Yes, It's t
Hi Masashi,
SAKURAI Masashi writes:
> I'm also think about cache in the calfw side, such as an alist:
> (date . [a list of contents]). Then, uses can refresh the cache
> explicitly. It is easy to implement.
>
> Is the plan(1) the same idea?
Yes, It's the same idea, but on Org's side.
I'm focus
Hi Rasmus and Giovanni,
At Wed, 20 Jul 2011 15:31:04 +0200,
Giovanni Ridolfi wrote:
> :
> > What does '/per-se/' mean ?
>
> :-)
> it is Latin, an ancient *European* language
> it means:
> - 'In itself'
> - Also "by itself"
> or:
> - Without referring to anything else, intrinsically,
> taken
SAKURAI Masashi writes:
> What does '/per-se/' mean ?
It means 'as such'
Here is the entry from Merriam Webster Unabriged
,
| per se
| Function: adverb
| Etymology: Latin
| : by, of, or in itself or oneself or themselves : as such : INDEPENDENTLY,
INTRINSICALLY
|
|
|
|
|
|
`
>
Hi Bastien,
At Tue, 19 Jul 2011 01:06:14 +0200,
Bastien wrote:
> :
> > I'm sure that the caching mechanism is useful, but I'm not sure that
> > we should do it with paying the large cost of rewrite whole codes.
>
> FWIW, this is a two separate steps process: 1) write a usable cache,
> then 2) re
Hi Matthew,
Matthew Sauer writes:
> What I am hearing is that an API that allows caching could be built
> that could benefit extensions and then once that is deemed stable
> enough
Yes, stable and, moreover, *fast* enough...
> [...] an optional or separate track would be rebuilding the Agenda
Bastien,
What I am hearing is that an API that allows caching could be built
that could benefit extensions and then once that is deemed stable
enough an optional or separate track would be rebuilding the Agenda as
it is today into that API?
Matt
On Mon, Jul 18, 2011 at 6:06 PM, Bastien wrote:
>
Hi Masashi,
SAKURAI Masashi writes:
> I'm sure that the caching mechanism is useful, but I'm not sure that
> we should do it with paying the large cost of rewrite whole codes.
FWIW, this is a two separate steps process: 1) write a usable cache,
then 2) re-implement (parts of) the agenda by usi
Hi Bastien,
At Tue, 12 Jul 2011 09:37:21 +0200,
Bastien wrote:
> :
> The question is: would an API for the whole agenda mechanism (and not
> just scheduled items) be useful?
>
> I've never been a big fan of caching Org files information, because Org
> files are often modified in impredictible way
Hi Masashi,
this is a very interesting proposal -- thanks for the diagrams and the
pointers to existing schedule API. I will digg into this direction and
see if I can propose something useful.
The question is: would an API for the whole agenda mechanism (and not
just scheduled items) be useful?
Hi Bastien,
At Fri, 08 Jul 2011 10:53:08 +0200,
Bastien wrote:
> :
> > the re-design of the whole org-agenda-list algorithm
> > seems to be needed, because the key function
> > org-agenda-get-day-entries requires only one date and the subsequent
> > dependent functions also are designed by the API
11 matches
Mail list logo
