[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ;;; anything.el --- open anything
From: |
address@hidden |
Subject: |
Re: ;;; anything.el --- open anything |
Date: |
Tue, 07 Aug 2007 02:56:04 -0700 |
User-agent: |
G2/1.0 |
On Aug 7, 8:55 am, Tassilo Horn <address@hidden> wrote:
> "address@hidden" <address@hidden> writes:
>
> Hi Tamas,
>
> >> So it's an adaptive candidate sorter which learns which candidates
> >> you select frequently and makes them more accessible for you.
>
> > Currently, the history of selections is stored and used per source, so
> > for example a different entry is stored when something is selected
> > from the File Name History or Recentf and such stored entries are used
> > only when sorting File Name History or Recentf, respectively.
>
> > I vaguely remember there was some reason why I selected history
> > handling by source, but now I don't really know what's the advantage.
> > Shouldn't selection history be stored by type instead, so that for
> > example a selection from any file providing source would contribute to
> > the common knowledge of what files one selects most frequently?
>
> > What do you think?
>
> I think that would make sense. But how would you go with sources that
> don't have a type field?
>
I plan to generalize source attributes, so that type would be a
fallback for those attributes which are not specified by the source.
So, for example, instead of using anything-candidate-transformers,
candidate transformation would be a simple source attribute which the
source could specify directly, or via its type.
So instead of
(setq anything-candidate-transformers
'((file . some-func)))
it would either be
(setq anything-sources '((name . "Some Source")
...
(candidate-transformer . some-func)))
or
(setq anything-sources '((name . "Some Source")
...
(type . file)))
(setq anything-type-attributes
'((file ((candidate-transformer . some-func)
...
)))
And it would be the same for anything-candidate-transformers and
anything-action-transformers, so these would all be obsoleted.
That's of course impacts anything-config.el heavily, so I only want to
do it if you agree and when you have the time to work on it.
Naturally, everything will be backward compatible until the transition
is complete, so I won't remove the existing framework until then.
I plan to do it in incremental steps. The first step will be
generalizing anything-filtered-candidate-transformers. You don't use
it yet in anything-config.el, so that's the simplest, and it will help
to finalize the adaptive sorter.
When it's done then the rest can be done incrementally.
What do you think of this plan?
- Re: ;;; anything.el --- open anything, (continued)
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/06
- Re: ;;; anything.el --- open anything, billclem, 2007/08/06
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/07
- Re: ;;; anything.el --- open anything, billclem, 2007/08/07
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/07
- Re: ;;; anything.el --- open anything, Tassilo Horn, 2007/08/07
- Message not available
- Re: ;;; anything.el --- open anything,
address@hidden <=
- Re: ;;; anything.el --- open anything, Tassilo Horn, 2007/08/07
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/10
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/10
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/11
- Re: ;;; anything.el --- open anything, Tassilo Horn, 2007/08/13
- Message not available
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/13
- Message not available
- Re: ;;; anything.el --- open anything, billclem, 2007/08/18
- Re: ;;; anything.el --- open anything, Xavier Maillard, 2007/08/19
- Re: ;;; anything.el --- open anything, address@hidden, 2007/08/19
- Re: ;;; anything.el --- open anything, Xavier Maillard, 2007/08/19