Re: more on anything.el inclusion

Re: more on anything.el inclusion

[Thierry Volpiatto]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 30 Jun 2010 20:36:31 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 
>
> TV> We did lot of work on anything since this time, anyone can see, try
> TV> and use anything on http://repo.or.cz/w/anything-config.git If you
> TV> like it, then we could include in emacs.
>
> Strangely, I can't check it out over HTTP:
>
> % git clone http://repo.or.cz/w/anything-config.git
> Initialized empty Git repository in /home/tzz/source/anything-config/.git/
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> (and nice warning, the checkout fails completely!)


> but it works with the git://repo.or.cz/anything-config.git URL.

Yes sorry, clone with:
git clone git://repo.or.cz/anything-config.git

> I think the revision history should be cut out of anything.el.
>
> It's pretty hard for a novice to get started customizing the sources.
> There is almost no Customize support AFAICT for anything-sources.  The
> existing anything.el docs assume good knowledge of Emacs Lisp.  I don't
> know if that is a problem, but a real manual would be very helpful for
> beginners.

anything-sources is deprecated and should be used with care with only
few sources, the one provided by default with anything.el are enough.

So the use of M-x anything is deprecated, you should use now commands
provided in anything-config.el.

Setting up a function for commands not provided is simple as:

(defun anything-buffers-only ()
  (interactive)
  (anything-other-buffer 'anything-c-source-buffers+ "*anything buffers*"))

Actually installing anything is easy and work out of the box with only:

(require 'anything-config)
(require 'anything-match-plugin) ; facultatif

Anything is now self documented both in mode-line and with C-h m or your
usual help command, but yes a manual would be nice.

> What sources should be on by default for Emacs users of anything.el?

Only the one that are already set in anything.el.


> I'm sure there are a lot of style and behavior issues I'm missing.  I'm
> so used to anything.el that I'm probably not a good test case of how it
> looks to an Emacs user.
>
> Ted
>
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Dan Nicolaescu]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> On Wed, 30 Jun 2010 20:36:31 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 
>>
>> TV> We did lot of work on anything since this time, anyone can see, try
>> TV> and use anything on http://repo.or.cz/w/anything-config.git If you
>> TV> like it, then we could include in emacs.
>>
>> Strangely, I can't check it out over HTTP:
>>
>> % git clone http://repo.or.cz/w/anything-config.git
>> Initialized empty Git repository in /home/tzz/source/anything-config/.git/
>> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>>
>> (and nice warning, the checkout fails completely!)
>
>
>> but it works with the git://repo.or.cz/anything-config.git URL.
>
> Yes sorry, clone with:
> git clone git://repo.or.cz/anything-config.git
>
>> I think the revision history should be cut out of anything.el.
>>
>> It's pretty hard for a novice to get started customizing the sources.
>> There is almost no Customize support AFAICT for anything-sources.  The
>> existing anything.el docs assume good knowledge of Emacs Lisp.  I don't
>> know if that is a problem, but a real manual would be very helpful for
>> beginners.
>
> anything-sources is deprecated and should be used with care with only
> few sources, the one provided by default with anything.el are enough.
>
> So the use of M-x anything is deprecated, you should use now commands
> provided in anything-config.el.
>
> Setting up a function for commands not provided is simple as:
>
> (defun anything-buffers-only ()
>   (interactive)
>   (anything-other-buffer 'anything-c-source-buffers+ "*anything buffers*"))
>
> Actually installing anything is easy and work out of the box with only:
>
> (require 'anything-config)
> (require 'anything-match-plugin) ; facultatif

For packages included in emacs we try to avoid using require to
activate the package.  [I don't know anything about this particular
package, so...]


> Anything is now self documented both in mode-line and with C-h m or your
> usual help command, but yes a manual would be nice.

Can you please add some brief description of what it actually does?

;;;; anything.el --- open anything / QuickSilver-like candidate-selection framework

does not tell much...

>
>> What sources should be on by default for Emacs users of anything.el?
>
> Only the one that are already set in anything.el.
>
>
>> I'm sure there are a lot of style and behavior issues I'm missing.  I'm
>> so used to anything.el that I'm probably not a good test case of how it
>> looks to an Emacs user.
>>
>> Ted
>>
>>
>>
>
> -- 
> Thierry Volpiatto
> Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Thierry Volpiatto]

Dan Nicolaescu <dann@gnu.org> writes:

>> Actually installing anything is easy and work out of the box with only:
>>
>> (require 'anything-config)
>> (require 'anything-match-plugin) ; facultatif
>
> For packages included in emacs we try to avoid using require to
> activate the package.  [I don't know anything about this particular
> package, so...]

A lot of autoload cookies are missing in anything-config, however, 

(autoload 'anything-find-files "anything-config.el" "" t)

is enough to enable anything.

>
>> Anything is now self documented both in mode-line and with C-h m or your
>> usual help command, but yes a manual would be nice.
>
> Can you please add some brief description of what it actually does?
>
> ;;;; anything.el --- open anything / QuickSilver-like candidate-selection framework
>
> does not tell much...

anything is a framework that allow to setup an interactive and
incremental display to select candidate and provide diverses actions on
it or many of them.

Basically, you can see that as a big completing-read, but incremental
with nice display, and providing differents action on candidate selected
in collection.

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Dan Nicolaescu]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>>> Actually installing anything is easy and work out of the box with only:
>>>
>>> (require 'anything-config)
>>> (require 'anything-match-plugin) ; facultatif
>>
>> For packages included in emacs we try to avoid using require to
>> activate the package.  [I don't know anything about this particular
>> package, so...]
>
> A lot of autoload cookies are missing in anything-config, however, 
>
> (autoload 'anything-find-files "anything-config.el" "" t)
>
> is enough to enable anything.

That's the same as using require.  The preferred way is to do it with
a function call, or a mode.

>>> Anything is now self documented both in mode-line and with C-h m or your
>>> usual help command, but yes a manual would be nice.
>>
>> Can you please add some brief description of what it actually does?
>>
>> ;;;; anything.el --- open anything / QuickSilver-like candidate-selection framework
>>
>> does not tell much...
>
> anything is a framework that allow to setup an interactive and
> incremental display to select candidate and provide diverses actions on
> it or many of them.
>
> Basically, you can see that as a big completing-read, but incremental
> with nice display, and providing differents action on candidate selected
> in collection.

And how do you use it?

BTW, this might be obvious to you, but for people that have not used
the package is not.  Adding a few lines of describing what it does and
how to use it is very helpful.  [Please note that this has no relation
to getting this package included in emacs, this is just what a
potential user would like].

Re: more on anything.el inclusion

[Thierry Volpiatto]

Dan Nicolaescu <dann@gnu.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Dan Nicolaescu <dann@gnu.org> writes:
>>
>>>> Actually installing anything is easy and work out of the box with only:
>>>>
>>>> (require 'anything-config)
>>>> (require 'anything-match-plugin) ; facultatif
>>>
>>> For packages included in emacs we try to avoid using require to
>>> activate the package.  [I don't know anything about this particular
>>> package, so...]
>>
>> A lot of autoload cookies are missing in anything-config, however, 
>>
>> (autoload 'anything-find-files "anything-config.el" "" t)
>>
>> is enough to enable anything.
>
> That's the same as using require.  The preferred way is to do it with
> a function call, or a mode.
>
>>>> Anything is now self documented both in mode-line and with C-h m or your
>>>> usual help command, but yes a manual would be nice.
>>>
>>> Can you please add some brief description of what it actually does?
>>>
>>> ;;;; anything.el --- open anything / QuickSilver-like candidate-selection framework
>>>
>>> does not tell much...
>>
>> anything is a framework that allow to setup an interactive and
>> incremental display to select candidate and provide diverses actions on
>> it or many of them.
>>
>> Basically, you can see that as a big completing-read, but incremental
>> with nice display, and providing differents action on candidate selected
>> in collection.
>
> And how do you use it?

On the user side, if you use anything-config.el, there is already build
in sources ready for use, so you can use provided functions like any
other emacs one (e.g M-x anything-xfonts).

For the developper who want to write his own anything source the best
actually is to look at the sources wrote in anything-config.el.

Basically, you run anything like that:

(anything 'source)

source is an alist that you can write like that:
(Where name, candidates, action are anything attributes.
You have a lot of attributes, for full info, use:
M-x anything-describe-anything-attribute)

(defvar mysource
  '((name . "A simple example that open all file with extension .el")
    (candidates . (lambda ()
                   (loop for i in (directory-files default-directory)
                      when (string= (file-name-extension i) "el")
                      collect i)))
    (action . (("Open file" . find-file)
               ("Do something else" . (lambda (candidate)
                                        ;; Write here something more
                                        ;; useful than nil
                                        nil))))))

;; [EVAL] (anything 'mysource)

After evaluating line above to see if your new source work as expected,
you can now define your new anything command:

(defun my-new-anything-command ()
  (interactive)
  (anything 'mysource))


> BTW, this might be obvious to you, but for people that have not used
> the package is not.  Adding a few lines of describing what it does and
> how to use it is very helpful.  [Please note that this has no relation
> to getting this package included in emacs, this is just what a
> potential user would like].
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Dan Nicolaescu]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>>> Dan Nicolaescu <dann@gnu.org> writes:
>>>
>>>>> Actually installing anything is easy and work out of the box with only:
>>>>>
>>>>> (require 'anything-config)
>>>>> (require 'anything-match-plugin) ; facultatif
>>>>
>>>> For packages included in emacs we try to avoid using require to
>>>> activate the package.  [I don't know anything about this particular
>>>> package, so...]
>>>
>>> A lot of autoload cookies are missing in anything-config, however, 
>>>
>>> (autoload 'anything-find-files "anything-config.el" "" t)
>>>
>>> is enough to enable anything.
>>
>> That's the same as using require.  The preferred way is to do it with
>> a function call, or a mode.
>>
>>>>> Anything is now self documented both in mode-line and with C-h m or your
>>>>> usual help command, but yes a manual would be nice.
>>>>
>>>> Can you please add some brief description of what it actually does?
>>>>
>>>> ;;;; anything.el --- open anything / QuickSilver-like candidate-selection framework
>>>>
>>>> does not tell much...
>>>
>>> anything is a framework that allow to setup an interactive and
>>> incremental display to select candidate and provide diverses actions on
>>> it or many of them.
>>>
>>> Basically, you can see that as a big completing-read, but incremental
>>> with nice display, and providing differents action on candidate selected
>>> in collection.
>>
>> And how do you use it?
>
> On the user side, if you use anything-config.el, there is already build
> in sources ready for use, so you can use provided functions like any
> other emacs one (e.g M-x anything-xfonts).

This is still hard to grasp...
Can you provide concrete examples of typical problems and how
anything.el solves them?



>
> For the developper who want to write his own anything source the best
> actually is to look at the sources wrote in anything-config.el.
>
> Basically, you run anything like that:
>
> (anything 'source)
>
> source is an alist that you can write like that:
> (Where name, candidates, action are anything attributes.
> You have a lot of attributes, for full info, use:
> M-x anything-describe-anything-attribute)
>
> (defvar mysource
>   '((name . "A simple example that open all file with extension .el")
>     (candidates . (lambda ()
>                    (loop for i in (directory-files default-directory)
>                       when (string= (file-name-extension i) "el")
>                       collect i)))
>     (action . (("Open file" . find-file)
>                ("Do something else" . (lambda (candidate)
>                                         ;; Write here something more
>                                         ;; useful than nil
>                                         nil))))))
>
> ;; [EVAL] (anything 'mysource)
>
> After evaluating line above to see if your new source work as expected,
> you can now define your new anything command:
>
> (defun my-new-anything-command ()
>   (interactive)
>   (anything 'mysource))
>
>
>> BTW, this might be obvious to you, but for people that have not used
>> the package is not.  Adding a few lines of describing what it does and
>> how to use it is very helpful.  [Please note that this has no relation
>> to getting this package included in emacs, this is just what a
>> potential user would like].
>>
>
> -- 
> Thierry Volpiatto
> Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Thierry Volpiatto]

Dan Nicolaescu <dann@gnu.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Dan Nicolaescu <dann@gnu.org> writes:
>>
>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>
>>>> Dan Nicolaescu <dann@gnu.org> writes:
>>>>
>>>>>> Actually installing anything is easy and work out of the box with only:
>>>>>>
>>>>>> (require 'anything-config)
>>>>>> (require 'anything-match-plugin) ; facultatif
>>>>>
>>>>> For packages included in emacs we try to avoid using require to
>>>>> activate the package.  [I don't know anything about this particular
>>>>> package, so...]
>>>>
>>>> A lot of autoload cookies are missing in anything-config, however, 
>>>>
>>>> (autoload 'anything-find-files "anything-config.el" "" t)
>>>>
>>>> is enough to enable anything.
>>>
>>> That's the same as using require.  The preferred way is to do it with
>>> a function call, or a mode.
>>>
>>>>>> Anything is now self documented both in mode-line and with C-h m or your
>>>>>> usual help command, but yes a manual would be nice.
>>>>>
>>>>> Can you please add some brief description of what it actually does?
>>>>>
>>>>> ;;;; anything.el --- open anything / QuickSilver-like candidate-selection framework
>>>>>
>>>>> does not tell much...
>>>>
>>>> anything is a framework that allow to setup an interactive and
>>>> incremental display to select candidate and provide diverses actions on
>>>> it or many of them.
>>>>
>>>> Basically, you can see that as a big completing-read, but incremental
>>>> with nice display, and providing differents action on candidate selected
>>>> in collection.
>>>
>>> And how do you use it?
>>
>> On the user side, if you use anything-config.el, there is already build
>> in sources ready for use, so you can use provided functions like any
>> other emacs one (e.g M-x anything-xfonts).
>
> This is still hard to grasp...
> Can you provide concrete examples of typical problems and how
> anything.el solves them?

Say you want to see how look dejavu fonts in emacs:
M-x anything-xfonts RET

enter in prompt: deja

Move anything overlay with C-n/p or down/up
Hit C-z
Hit TAB to see provided actions
Hit C-g to exit doing nothing
Hit RET to exit doing the default action.

Did you read example i provide under here?

>
>
>
>>
>> For the developper who want to write his own anything source the best
>> actually is to look at the sources wrote in anything-config.el.
>>
>> Basically, you run anything like that:
>>
>> (anything 'source)
>>
>> source is an alist that you can write like that:
>> (Where name, candidates, action are anything attributes.
>> You have a lot of attributes, for full info, use:
>> M-x anything-describe-anything-attribute)
>>
>> (defvar mysource
>>   '((name . "A simple example that open all file with extension .el")
>>     (candidates . (lambda ()
>>                    (loop for i in (directory-files default-directory)
>>                       when (string= (file-name-extension i) "el")
>>                       collect i)))
>>     (action . (("Open file" . find-file)
>>                ("Do something else" . (lambda (candidate)
>>                                         ;; Write here something more
>>                                         ;; useful than nil
>>                                         nil))))))
>>
>> ;; [EVAL] (anything 'mysource)
>>
>> After evaluating line above to see if your new source work as expected,
>> you can now define your new anything command:
>>
>> (defun my-new-anything-command ()
>>   (interactive)
>>   (anything 'mysource))
>>
>>
>>> BTW, this might be obvious to you, but for people that have not used
>>> the package is not.  Adding a few lines of describing what it does and
>>> how to use it is very helpful.  [Please note that this has no relation
>>> to getting this package included in emacs, this is just what a
>>> potential user would like].
>>>
>>
>> -- 
>> Thierry Volpiatto
>> Gpg key: http://pgp.mit.edu/
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Ted Zlatanov]

On Thu, 01 Jul 2010 09:50:30 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 

TV> On the user side, if you use anything-config.el, there is already build
TV> in sources ready for use, so you can use provided functions like any
TV> other emacs one (e.g M-x anything-xfonts).

OK.  Thanks for explaining.  So from the user's viewpoint, it should be
enough to autoload all the front-end anything-* functions (from
anything.el ideally, so users don't have to know about
anything-config.el as you had it in your autoload example).  Can you
make the necessary changes?  Or will that require major work?

Is there a list of the standard front-end functions (a subset of the
autoloads below) that should always be exposed (through keyboard
mappings, possibly in a menu) to Emacs users?  The xfonts and file
selection ones should be in that list for sure.

TV> For the developper who want to write his own anything source the best
TV> actually is to look at the sources wrote in anything-config.el.

I don't think you need to explain too much about developer support in
this thread; I would assume anyone interested in extending it is capable
of reading the docs.

Thanks
Ted

Re: more on anything.el inclusion

[Thierry Volpiatto]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 01 Jul 2010 09:50:30 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 
>
> TV> On the user side, if you use anything-config.el, there is already build
> TV> in sources ready for use, so you can use provided functions like any
> TV> other emacs one (e.g M-x anything-xfonts).
>
> OK.  Thanks for explaining.  So from the user's viewpoint, it should be
> enough to autoload all the front-end anything-* functions (from
> anything.el ideally, so users don't have to know about
> anything-config.el as you had it in your autoload example).  Can you
> make the necessary changes?  Or will that require major work?

Maybe a function that autoload all as suggested by Dan?
Would not need major work, but need to discuss it with Rubikitch.

> Is there a list of the standard front-end functions (a subset of the
> autoloads below) that should always be exposed (through keyboard
> mappings, possibly in a menu) to Emacs users?  The xfonts and file
> selection ones should be in that list for sure.

In which menu should we add anything commands?
I mean this kind of menu:

(easy-menu-define nil global-map
  "`anything' menu"
  `("Anything commands"
    ["Find files" anything-find-files t]
    ["Show xfonts" anything-xfonts t]))

Here it is in global menu, but maybe that should go in tools or don't
know where.(i never used menus in emacs, toolbar is disabled here).


> TV> For the developper who want to write his own anything source the best
> TV> actually is to look at the sources wrote in anything-config.el.
>
> I don't think you need to explain too much about developer support in
> this thread; I would assume anyone interested in extending it is capable
> of reading the docs.

Ok

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Lennart Borgman]

On Thu, Jul 1, 2010 at 4:15 PM, Thierry Volpiatto
<thierry.volpiatto@gmail.com> wrote:
>
> In which menu should we add anything commands?

I have suggested long ago to create a top level menu for all minor
modes. That would make decisions like this easier.

Re: more on anything.el inclusion

[Ted Zlatanov]

On Thu, 01 Jul 2010 16:15:38 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 

TV> Ted Zlatanov <tzz@lifelogs.com> writes:

>> OK.  Thanks for explaining.  So from the user's viewpoint, it should be
>> enough to autoload all the front-end anything-* functions (from
>> anything.el ideally, so users don't have to know about
>> anything-config.el as you had it in your autoload example).  Can you
>> make the necessary changes?  Or will that require major work?

TV> Maybe a function that autoload all as suggested by Dan?
TV> Would not need major work, but need to discuss it with Rubikitch.

Wonderful, thank you.

>> Is there a list of the standard front-end functions (a subset of the
>> autoloads below) that should always be exposed (through keyboard
>> mappings, possibly in a menu) to Emacs users?  The xfonts and file
>> selection ones should be in that list for sure.

TV> In which menu should we add anything commands?
TV> I mean this kind of menu:

TV> (easy-menu-define nil global-map
TV>   "`anything' menu"
TV>   `("Anything commands"
TV>     ["Find files" anything-find-files t]
TV>     ["Show xfonts" anything-xfonts t]))

TV> Here it is in global menu, but maybe that should go in tools or don't
TV> know where.(i never used menus in emacs, toolbar is disabled here).

The menu location is not so important.  The point is to make a list of
"important" front-end functions that users should really know about.
The keyboard mappings are IMO much more important because anything-*
functions tend to be important while editing, not as an interactive
exploration (which menus do well).  So when we have the list we can
propose a list of mappings and depending on whether the list has 10 or
100 entries we can anticipate the mapping complexity.

On Thu, 1 Jul 2010 16:48:48 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> On Thu, Jul 1, 2010 at 4:15 PM, Thierry Volpiatto
LB> <thierry.volpiatto@gmail.com> wrote:
>> 
>> In which menu should we add anything commands?

LB> I have suggested long ago to create a top level menu for all minor
LB> modes. That would make decisions like this easier.

Exposing functionality creates UI complexity; Emacs is already really
complex both in UI terms and in scope.  So I don't think adding a
general menu like that (have you seen how many minor modes Emacs has?)
would benefit the users.

OTOH it would be very nifty if there was a anything-minor-mode function
that let you browse (with some help text) and activate minor modes.

Ted

Re: more on anything.el inclusion

[Dan Nicolaescu]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>>> Dan Nicolaescu <dann@gnu.org> writes:
>>>
>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>>
>>>>> Dan Nicolaescu <dann@gnu.org> writes:
>>>>>
>>>>>>> Actually installing anything is easy and work out of the box with only:
>>>>>>>
>>>>>>> (require 'anything-config)
>>>>>>> (require 'anything-match-plugin) ; facultatif
>>>>>>
>>>>>> For packages included in emacs we try to avoid using require to
>>>>>> activate the package.  [I don't know anything about this particular
>>>>>> package, so...]
>>>>>
>>>>> A lot of autoload cookies are missing in anything-config, however, 
>>>>>
>>>>> (autoload 'anything-find-files "anything-config.el" "" t)
>>>>>
>>>>> is enough to enable anything.
>>>>
>>>> That's the same as using require.  The preferred way is to do it with
>>>> a function call, or a mode.
>>>>
>>>>>>> Anything is now self documented both in mode-line and with C-h m or your
>>>>>>> usual help command, but yes a manual would be nice.
>>>>>>
>>>>>> Can you please add some brief description of what it actually does?
>>>>>>
>>>>>> ;;;; anything.el --- open anything / QuickSilver-like candidate-selection framework
>>>>>>
>>>>>> does not tell much...
>>>>>
>>>>> anything is a framework that allow to setup an interactive and
>>>>> incremental display to select candidate and provide diverses actions on
>>>>> it or many of them.
>>>>>
>>>>> Basically, you can see that as a big completing-read, but incremental
>>>>> with nice display, and providing differents action on candidate selected
>>>>> in collection.
>>>>
>>>> And how do you use it?
>>>
>>> On the user side, if you use anything-config.el, there is already build
>>> in sources ready for use, so you can use provided functions like any
>>> other emacs one (e.g M-x anything-xfonts).
>>
>> This is still hard to grasp...
>> Can you provide concrete examples of typical problems and how
>> anything.el solves them?
>
> Say you want to see how look dejavu fonts in emacs:
> M-x anything-xfonts RET

Does this happen automatically when you do x-choose-font?

As a user do I need to know a lot of anything-* function names, or
this happens automatically when I use completion?

> enter in prompt: deja
>
> Move anything overlay with C-n/p or down/up
> Hit C-z
> Hit TAB to see provided actions
> Hit C-g to exit doing nothing
> Hit RET to exit doing the default action.
>
> Did you read example i provide under here?

No, I am looking at this from the point of view of a user, not a programmer.

You might want to step back, and think about how to present this to
someone that has not idea what anything.el is, and what it can do.
(I still don't know after a few emails...)

>
>>
>>
>>
>>>
>>> For the developper who want to write his own anything source the best
>>> actually is to look at the sources wrote in anything-config.el.
>>>
>>> Basically, you run anything like that:
>>>
>>> (anything 'source)
>>>
>>> source is an alist that you can write like that:
>>> (Where name, candidates, action are anything attributes.
>>> You have a lot of attributes, for full info, use:
>>> M-x anything-describe-anything-attribute)
>>>
>>> (defvar mysource
>>>   '((name . "A simple example that open all file with extension .el")
>>>     (candidates . (lambda ()
>>>                    (loop for i in (directory-files default-directory)
>>>                       when (string= (file-name-extension i) "el")
>>>                       collect i)))
>>>     (action . (("Open file" . find-file)
>>>                ("Do something else" . (lambda (candidate)
>>>                                         ;; Write here something more
>>>                                         ;; useful than nil
>>>                                         nil))))))
>>>
>>> ;; [EVAL] (anything 'mysource)
>>>
>>> After evaluating line above to see if your new source work as expected,
>>> you can now define your new anything command:
>>>
>>> (defun my-new-anything-command ()
>>>   (interactive)
>>>   (anything 'mysource))
>>>
>>>
>>>> BTW, this might be obvious to you, but for people that have not used
>>>> the package is not.  Adding a few lines of describing what it does and
>>>> how to use it is very helpful.  [Please note that this has no relation
>>>> to getting this package included in emacs, this is just what a
>>>> potential user would like].
>>>>
>>>
>>> -- 
>>> Thierry Volpiatto
>>> Gpg key: http://pgp.mit.edu/
>>
>
> -- 
> Thierry Volpiatto
> Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Harald Hanche-Olsen]

+ Dan Nicolaescu <dann@gnu.org>:

> You might want to step back, and think about how to present this to
> someone that has not idea what anything.el is, and what it can do.
> (I still don't know after a few emails...)

I can't help explain anything (*), but it has been compared to
quicksilver on the Mac, which I do use. And the problem with
explaining that is that it is (in some ways) so totally different from
traditional computer interfaces that it's almost impossible to
describe it meaningfully. You just have to see it in action. That
doesn't mean you cannot and should not try, but it explains why the
explanations this far fall short.

(Imagine explaining computers and what you can do with them to your
great-great-grandfather.)

(*) I love being able to say that.

- Harald (who is now willing to try anything for himself)

Re: more on anything.el inclusion

[Ted Zlatanov]

On Thu, 01 Jul 2010 11:33:19 -0500 (CDT) Harald Hanche-Olsen <hanche@math.ntnu.no> wrote: 

HH> + Dan Nicolaescu <dann@gnu.org>:
>> You might want to step back, and think about how to present this to
>> someone that has not idea what anything.el is, and what it can do.
>> (I still don't know after a few emails...)

HH> I can't help explain anything (*), but it has been compared to
HH> quicksilver on the Mac, which I do use. 

It's similar to Gnome Do as well (or you can say Do is like
QuickSilver), for those who don't have a Mac.

HH> And the problem with explaining that is that it is (in some ways) so
HH> totally different from traditional computer interfaces that it's
HH> almost impossible to describe it meaningfully. You just have to see
HH> it in action. That doesn't mean you cannot and should not try, but
HH> it explains why the explanations this far fall short.

We've had interactive completion in Emacs for a while and it actually
does a lot of cool things like anything.el.  Icicles also addresses
similar needs, although I personally did not like it.  So I don't think
it's necessarily a radical interface you'd have trouble explaining to
the Emacs crowd :)

Ted

Re: more on anything.el inclusion

[Lennart Borgman]

2010/7/1 Ted Zlatanov <tzz@lifelogs.com>:
>>>
>>> In which menu should we add anything commands?
>
> LB> I have suggested long ago to create a top level menu for all minor
> LB> modes. That would make decisions like this easier.
>
> Exposing functionality creates UI complexity; Emacs is already really
> complex both in UI terms and in scope.  So I don't think adding a
> general menu like that (have you seen how many minor modes Emacs has?)
> would benefit the users.


A misunderstanding. The problem today is that all minor mode menus
goes into the top level menu, i.e. the menu bar. So every minor mode
you turn on takes space in the menu bar, but the space in the menu bar
is limited.

What I suggested is that minor mode menus should not go into the menu
bar. They should go into a submenu for minor modes instead. (Perhaps
that should be customized per minor mode.)

Normally minor modes are not in the menus unless they are turned on.


> OTOH it would be very nifty if there was a anything-minor-mode function
> that let you browse (with some help text) and activate minor modes.


The menus are also used for this. Functionality are sometimes put in
the menus so that it is easier to find it. I think that is a good
idea.

Re: more on anything.el inclusion

[Thierry Volpiatto]

Dan Nicolaescu <dann@gnu.org> writes:

>> Say you want to see how look dejavu fonts in emacs:
>> M-x anything-xfonts RET
>
> Does this happen automatically when you do x-choose-font?

Don't know what is x-choose-font, i have not such command.

> As a user do I need to know a lot of anything-* function names, or
> this happens automatically when I use completion?

AFAIK M-x provide completion on all emacs commands, why not for anything
commands?
You can use anything-M-x or anything-emacs-commands as a replacement of
M-x.

>> enter in prompt: deja
>>
>> Move anything overlay with C-n/p or down/up
>> Hit C-z
>> Hit TAB to see provided actions
>> Hit C-g to exit doing nothing
>> Hit RET to exit doing the default action.
>>
>> Did you read example i provide under here?
>
> No, I am looking at this from the point of view of a user, not a programmer.

Ok.

> You might want to step back, and think about how to present this to
> someone that has not idea what anything.el is, and what it can do.
On the user point of view, there is nothing to understand, anything
provide emacs commands like any other emacs package.

So you do M-x anything- TAB and try differents commands.

> (I still don't know after a few emails...)
I assume you are joking. ;-)


-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Harald Hanche-Olsen]

+ Dan Nicolaescu <dann@gnu.org>:

> (I still don't know after a few emails...)

Does  http://www.emacswiki.org/cgi-bin/emacs/Anything  help at all?

- Harald

Re: more on anything.el inclusion

[Dan Nicolaescu]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>>> Say you want to see how look dejavu fonts in emacs:
>>> M-x anything-xfonts RET
>>
>> Does this happen automatically when you do x-choose-font?
>
> Don't know what is x-choose-font, i have not such command.

Sorry, x-select-font

BTW, anything-xfonts is not the best example, looking at fonts is not
a very frequent action.  Can you give an example of a more frequent
operation / mode of operation.

>> As a user do I need to know a lot of anything-* function names, or
>> this happens automatically when I use completion?
>
> AFAIK M-x provide completion on all emacs commands, why not for anything
> commands?
> You can use anything-M-x or anything-emacs-commands as a replacement of
> M-x.

So are you saying that instead of using M-x SOMETHING one would use
M-x anything-SOMETHING?

Normally users don't do M-x find-file, they to C-x C-f, so if you do C-x C-f do you get 
M-x anything-find-file ? (and similar for other key bindings)

>> You might want to step back, and think about how to present this to
>> someone that has not idea what anything.el is, and what it can do.
> On the user point of view, there is nothing to understand, anything
> provide emacs commands like any other emacs package.
>
> So you do M-x anything- TAB and try differents commands.

As a user, if the package does not quite tell me why would I want to
try it, I won't do it.  That's why I am asking from some simple, easy
to understand, significant examples.

>> (I still don't know after a few emails...)
> I assume you are joking. ;-)

I am not.  All I know that it's a package that does some kind of
completion that is activated after you do (require 'anything).  But
it's unclear what type of completion, and why would I want to use it.
Please don't get this wrong, many people are saying it's a great
package, but the description can use some improvement.

Re: more on anything.el inclusion

[Thierry Volpiatto]

Dan Nicolaescu <dann@gnu.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Dan Nicolaescu <dann@gnu.org> writes:
>>
>>>> Say you want to see how look dejavu fonts in emacs:
>>>> M-x anything-xfonts RET
>>>
>>> Does this happen automatically when you do x-choose-font?
>>
>> Don't know what is x-choose-font, i have not such command.
>
> Sorry, x-select-font

> BTW, anything-xfonts is not the best example, looking at fonts is not
> a very frequent action.  Can you give an example of a more frequent
> operation / mode of operation.

You can try anything-find-files that can be a replacement of C-x C-f
IF YOU WANT.
In any case, it will never replace standard C-x C-f (find-file) until
you write explicitely in your .emacs
(global-set-key (kbd "C-x C-f") 'anyting-find-files)
                                                  ^
                                                  Notice the s at end.

That the choice of the user to use the command he want.

As you will see anything-find-files will give you in addition of an
incremental search a bunch of actions on candidate:

,----
| Find File
| Find file in Dired
| Find file in Elscreen 
| Complete at point
| Delete File(s)
| Find file as root
| Open file externally (C-u to choose)
| Find file other window
| Find file other frame
`----

find file in elscreen appear in menu only if elscreen is loaded.

complete at point provide file completion in any buffer in emacs
(minibuffer compris)

>>> As a user do I need to know a lot of anything-* function names, or
>>> this happens automatically when I use completion?
>>
>> AFAIK M-x provide completion on all emacs commands, why not for anything
>> commands?
>> You can use anything-M-x or anything-emacs-commands as a replacement of
>> M-x.
>
> So are you saying that instead of using M-x SOMETHING one would use
> M-x anything-SOMETHING?

Yes that is your choice, anything DONT REPLACE emacs commands unless you
do it explicitely by binding command.

> Normally users don't do M-x find-file, they to C-x C-f, so if you do C-x C-f do you get 
> M-x anything-find-file ? (and similar for other key bindings)

No, as explained above, that's your choice, maybe one prefer using
standard C-x C-f (find-file) and not anything-find-files.

So you can install anything in emacs and continue to use emacs as you
always did.

>>> You might want to step back, and think about how to present this to
>>> someone that has not idea what anything.el is, and what it can do.
>> On the user point of view, there is nothing to understand, anything
>> provide emacs commands like any other emacs package.
>>
>> So you do M-x anything- TAB and try differents commands.
>
> As a user, if the package does not quite tell me why would I want to
> try it, I won't do it.  That's why I am asking from some simple, easy
> to understand, significant examples.
>
>>> (I still don't know after a few emails...)
>> I assume you are joking. ;-)
>
> I am not.  All I know that it's a package that does some kind of
> completion that is activated after you do (require 'anything).  But
> it's unclear what type of completion, and why would I want to use it.
> Please don't get this wrong, many people are saying it's a great
> package, but the description can use some improvement.
As Harald said, it's difficult to describe until you use it.


-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Ted Zlatanov]

On Thu, 01 Jul 2010 13:43:37 -0400 Dan Nicolaescu <dann@gnu.org> wrote: 

DN> So are you saying that instead of using M-x SOMETHING one would use
DN> M-x anything-SOMETHING?

DN> Normally users don't do M-x find-file, they to C-x C-f, so if you do
DN> C-x C-f do you get M-x anything-find-file ? (and similar for other
DN> key bindings)

anything.el does not change or interfere with the normal completion
system.  IMHO this is a good thing: it has allowed anything.el to
experiment freely and has made it a simple unobtrusive add-on.

DN> As a user, if the package does not quite tell me why would I want to
DN> try it, I won't do it.  That's why I am asking from some simple, easy
DN> to understand, significant examples.

How about

"anything.el: easy find/select/operate on files/fonts/anything interface.

A live-search (similar to Quicksilver and Gnome Do) alternative to
standard completion mechanisms you can try by exploring the anything-*
commands.  Does not change or interfere with standard completion and
requires no customizations out of the box."

Re: more on anything.el inclusion

[Ted Zlatanov]

On Thu, 1 Jul 2010 18:43:02 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> 2010/7/1 Ted Zlatanov <tzz@lifelogs.com>:
>>>> 
>>>> In which menu should we add anything commands?
>> 
LB> I have suggested long ago to create a top level menu for all minor
LB> modes. That would make decisions like this easier.
>> 
>> Exposing functionality creates UI complexity; Emacs is already really
>> complex both in UI terms and in scope.  So I don't think adding a
>> general menu like that (have you seen how many minor modes Emacs has?)
>> would benefit the users.

LB> A misunderstanding. The problem today is that all minor mode menus
LB> goes into the top level menu, i.e. the menu bar. So every minor mode
LB> you turn on takes space in the menu bar, but the space in the menu bar
LB> is limited.

LB> What I suggested is that minor mode menus should not go into the menu
LB> bar. They should go into a submenu for minor modes instead. (Perhaps
LB> that should be customized per minor mode.)

LB> Normally minor modes are not in the menus unless they are turned on.

I see.  You meant "all active minor modes" in your original message.
Yes, in that limited case it could work but I'm not convinced it would
be useful.

Ted

Re: more on anything.el inclusion

[Wojciech Meyer]

I tried it at work today and I quite like it. To the extent I wanted
immediately bind it to a key. The idea is about implict context,
normally you have to supply conext in a form of specific function. To
open a file you have to say M-x load-file or to switch to a buffer you
have to say M-x ibuffer-switch, M-x anything try to guess the action
based on a context and give you a choice. So in this case you just say
M-x anything and type characters, and get list of options to do with
the names or symbols containig those.
Wojciech

On 7/1/10, Dan Nicolaescu <dann@gnu.org> wrote:
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Dan Nicolaescu <dann@gnu.org> writes:
>>
>>>> Say you want to see how look dejavu fonts in emacs:
>>>> M-x anything-xfonts RET
>>>
>>> Does this happen automatically when you do x-choose-font?
>>
>> Don't know what is x-choose-font, i have not such command.
>
> Sorry, x-select-font
>
> BTW, anything-xfonts is not the best example, looking at fonts is not
> a very frequent action.  Can you give an example of a more frequent
> operation / mode of operation.
>
>>> As a user do I need to know a lot of anything-* function names, or
>>> this happens automatically when I use completion?
>>
>> AFAIK M-x provide completion on all emacs commands, why not for anything
>> commands?
>> You can use anything-M-x or anything-emacs-commands as a replacement of
>> M-x.
>
> So are you saying that instead of using M-x SOMETHING one would use
> M-x anything-SOMETHING?
>
> Normally users don't do M-x find-file, they to C-x C-f, so if you do C-x C-f
> do you get
> M-x anything-find-file ? (and similar for other key bindings)
>
>>> You might want to step back, and think about how to present this to
>>> someone that has not idea what anything.el is, and what it can do.
>> On the user point of view, there is nothing to understand, anything
>> provide emacs commands like any other emacs package.
>>
>> So you do M-x anything- TAB and try differents commands.
>
> As a user, if the package does not quite tell me why would I want to
> try it, I won't do it.  That's why I am asking from some simple, easy
> to understand, significant examples.
>
>>> (I still don't know after a few emails...)
>> I assume you are joking. ;-)
>
> I am not.  All I know that it's a package that does some kind of
> completion that is activated after you do (require 'anything).  But
> it's unclear what type of completion, and why would I want to use it.
> Please don't get this wrong, many people are saying it's a great
> package, but the description can use some improvement.
>
>

-- 
Sent from my mobile device

Re: more on anything.el inclusion

[Lennart Borgman]

2010/7/1 Ted Zlatanov <tzz@lifelogs.com>:
>
> LB> What I suggested is that minor mode menus should not go into the menu
> LB> bar. They should go into a submenu for minor modes instead. (Perhaps
> LB> that should be customized per minor mode.)
>
> LB> Normally minor modes are not in the menus unless they are turned on.
>
> I see.  You meant "all active minor modes" in your original message.
> Yes, in that limited case it could work but I'm not convinced it would
> be useful.


It depends on how many minor modes you use.

Also I think it would make the distinction between minor modes and
major modes a bit more clear for beginners.

Re: more on anything.el inclusion

[Stefan Monnier]

> BTW, this might be obvious to you, but for people that have not used
> the package is not.  Adding a few lines of describing what it does and
> how to use it is very helpful.  [Please note that this has no relation
> to getting this package included in Emacs, this is just what a
> potential user would like].

Having gone through the same steps, plus some private discussion with
Thierry, here's my take on it:

   anything.el provides an alternate selection mechanism that differs
   from the usual minibuffer+completion mechanism in various ways,
   such as:
   - the *Completions* buffer is always displayed.
   - the *Completions* buffer is where the action takes place.
   - ...
   - the action to perform on the object(s) you selected is (or can be)
     chosen from the *Completions* buffer, i.e. after selecting the
     object rather than before.
   
   I.e. one difference is that the UI for selection is a bit different.
   And another is that the "paradigm" is changed from "choose action
   then choose on which object to apply it" to "choose object(s) and
   then choose action to apply to it/them".

I haven't delved far enough to give much further details.  I think it
would be good to try and decouple some of those aspects, especially
since I think that some of them could be included in
completion-list-mode (i.e. in the default UI).


        Stefan

Re: more on anything.el inclusion

[Ted Zlatanov]

On Mon, 05 Jul 2010 00:02:59 +0200 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> BTW, this might be obvious to you, but for people that have not used
>> the package is not.  Adding a few lines of describing what it does and
>> how to use it is very helpful.  [Please note that this has no relation
>> to getting this package included in Emacs, this is just what a
>> potential user would like].

...
SM> I haven't delved far enough to give much further details.  I think it
SM> would be good to try and decouple some of those aspects, especially
SM> since I think that some of them could be included in
SM> completion-list-mode (i.e. in the default UI).

Does this mean you'd rather not include anything.el in Emacs?

My view is that the anything.el system, separated from the Emacs
completion mechanism, has significant freedom with plugins and
functionality.  So improving the completion mechanism is not the same as
what anything.el can provide for Emacs users.

Ted

Re: more on anything.el inclusion

[Thierry Volpiatto]

Hi Ted, sorry for late reply.

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 01 Jul 2010 16:15:38 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 
>
> TV> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>>> OK.  Thanks for explaining.  So from the user's viewpoint, it should be
>>> enough to autoload all the front-end anything-* functions (from
>>> anything.el ideally, so users don't have to know about
>>> anything-config.el as you had it in your autoload example).  Can you
>>> make the necessary changes?  Or will that require major work?
>
> TV> Maybe a function that autoload all as suggested by Dan?
> TV> Would not need major work, but need to discuss it with Rubikitch.
>
> Wonderful, thank you.

I don't think a function is neccessary as anything don't modify other
things in emacs.
There is now an anything-command-map that can be autoloaded at emacs
startup.

>>> Is there a list of the standard front-end functions (a subset of the
>>> autoloads below) that should always be exposed (through keyboard
>>> mappings, possibly in a menu) to Emacs users?  The xfonts and file
>>> selection ones should be in that list for sure.
>
> TV> In which menu should we add anything commands?
> TV> I mean this kind of menu:
>
> TV> (easy-menu-define nil global-map
> TV>   "`anything' menu"
> TV>   `("Anything commands"
> TV>     ["Find files" anything-find-files t]
> TV>     ["Show xfonts" anything-xfonts t]))
>
> TV> Here it is in global menu, but maybe that should go in tools or don't
> TV> know where.(i never used menus in emacs, toolbar is disabled here).
>
> The menu location is not so important.  The point is to make a list of
> "important" front-end functions that users should really know about.
> The keyboard mappings are IMO much more important because anything-*
> functions tend to be important while editing, not as an interactive
> exploration (which menus do well).  So when we have the list we can
> propose a list of mappings and depending on whether the list has 10 or
> 100 entries we can anticipate the mapping complexity.

The anything-command-map is now prefixed at '<f5> a', what can be
discussed.
If user like a command and want to replace it with standard
emacs command, he can bind it to global-map 
(e.g anything-find-files <=> find-file ==> C-x C-f)

There is also a menu showing important commands (again this list can be
discussed) that appear when autoloading anything-command-map.

> On Thu, 1 Jul 2010 16:48:48 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 
>
> LB> On Thu, Jul 1, 2010 at 4:15 PM, Thierry Volpiatto
> LB> <thierry.volpiatto@gmail.com> wrote:
>>> 
>>> In which menu should we add anything commands?
>
> LB> I have suggested long ago to create a top level menu for all minor
> LB> modes. That would make decisions like this easier.
>
> Exposing functionality creates UI complexity; Emacs is already really
> complex both in UI terms and in scope.  So I don't think adding a
> general menu like that (have you seen how many minor modes Emacs has?)
> would benefit the users.
>
> OTOH it would be very nifty if there was a anything-minor-mode function
> that let you browse (with some help text) and activate minor modes.
>
> Ted
>
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[MON KEY]

On Wed, 07 Jul 2010 11:47:40 -0500 Ted Zlatanov wrote:
> Does this mean you'd rather not include anything.el in Emacs?
>
> My view is that the anything.el system, separated from the Emacs
> completion mechanism, has significant freedom with plugins and

This freedom isn't of itself a good thing and could just as well serve
as a potential source confusion/bugs/conflict.

AFAIK anything is currently maintained by a cadre of users and the
`freedom' that the anything interface provides has/can created
conflicts w/re implementation details.

Were anything.el to be included in Emacs who would be the lead point
of contact?

IMHO of the anything cadre Thierry is prob. the capable person, though
I imagine nominating him as such could be a bone of contention other
of the existing contributors.

This being said, it likewise isn't at all clear how/why the Anything
featureset is different from or somehow 'better than' the Icicles
features Drew Adams' has provided and maintained for many years
now. Indeed, IIUC there is already some overlap between the two API's
because there a not insignificant degree of functionality overlap. It
would seem a real shame (and prob. an insulting to Drew) to consider
inclusion of Anything without an honest discussion of inclusion of
Icicles as well.

Maybe Icicles and Antyhing code/features could/should be merged before
inclusion in Emacs.

FTR I use neither Anything nor Icicles and couldn't endorse either
from experience.  However, I have watched the progress of their
respective development with interest.

> functionality.  So improving the completion mechanism is not the
> same as what anything.el can provide for Emacs users.

Why should it be?
What Stephan proposes is absolutely TRT for users such as myself who
_could/should_ benefit from the features and proven design concepts
which both Anything and Icicles seem to extend to their current
adoptees. Why shouldn't we all benefit from an abstracted meta-level
API?

It is wrongheaded to arbitrarily incorporate external packages which
duplicate existing core behaviour/features such that the duplication
of the new (however useful) is better positioned to becomes the norm
simply by virtue of the pain imposed on emacs-devels to retrofit a
core API after the fact.

IOW lets say anything.el were to be included in Emacs and it became so
widely adopted that it was deemed worthwhile to attempt a retroactive
metaleval API (including C primitives). Were Stefan or some other
devel to endeavor implementation of such an API they might be hard
pressed to maintain backwards compatibility with the existing
anything.el procedures and prob. alienate the primary anything.el user
base to boot.

> Ted

--
/s_P\

Re: more on anything.el inclusion

[Thierry Volpiatto]

Hope my private mail is clear enough.
I say no more here as i don't want to pollute this mailing list.

MON KEY <monkey@sandpframing.com> writes:

> On Wed, 07 Jul 2010 11:47:40 -0500 Ted Zlatanov wrote:
>> Does this mean you'd rather not include anything.el in Emacs?
>>
>> My view is that the anything.el system, separated from the Emacs
>> completion mechanism, has significant freedom with plugins and
>
> This freedom isn't of itself a good thing and could just as well serve
> as a potential source confusion/bugs/conflict.
>
> AFAIK anything is currently maintained by a cadre of users and the
> `freedom' that the anything interface provides has/can created
> conflicts w/re implementation details.
>
> Were anything.el to be included in Emacs who would be the lead point
> of contact?
>
> IMHO of the anything cadre Thierry is prob. the capable person, though
> I imagine nominating him as such could be a bone of contention other
> of the existing contributors.
>
> This being said, it likewise isn't at all clear how/why the Anything
> featureset is different from or somehow 'better than' the Icicles
> features Drew Adams' has provided and maintained for many years
> now. Indeed, IIUC there is already some overlap between the two API's
> because there a not insignificant degree of functionality overlap. It
> would seem a real shame (and prob. an insulting to Drew) to consider
> inclusion of Anything without an honest discussion of inclusion of
> Icicles as well.
>
> Maybe Icicles and Antyhing code/features could/should be merged before
> inclusion in Emacs.
>
> FTR I use neither Anything nor Icicles and couldn't endorse either
> from experience.  However, I have watched the progress of their
> respective development with interest.
>
>> functionality.  So improving the completion mechanism is not the
>> same as what anything.el can provide for Emacs users.
>
> Why should it be?
> What Stephan proposes is absolutely TRT for users such as myself who
> _could/should_ benefit from the features and proven design concepts
> which both Anything and Icicles seem to extend to their current
> adoptees. Why shouldn't we all benefit from an abstracted meta-level
> API?
>
> It is wrongheaded to arbitrarily incorporate external packages which
> duplicate existing core behaviour/features such that the duplication
> of the new (however useful) is better positioned to becomes the norm
> simply by virtue of the pain imposed on emacs-devels to retrofit a
> core API after the fact.
>
> IOW lets say anything.el were to be included in Emacs and it became so
> widely adopted that it was deemed worthwhile to attempt a retroactive
> metaleval API (including C primitives). Were Stefan or some other
> devel to endeavor implementation of such an API they might be hard
> pressed to maintain backwards compatibility with the existing
> anything.el procedures and prob. alienate the primary anything.el user
> base to boot.
>
>> Ted
>
> --
> /s_P\
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: more on anything.el inclusion

[Ted Zlatanov]

On Sat, 10 Jul 2010 14:27:45 -0400 MON KEY <monkey@sandpframing.com> wrote: 

MK> Maybe Icicles and Antyhing code/features could/should be merged before
MK> inclusion in Emacs.

MK> FTR I use neither Anything nor Icicles and couldn't endorse either
MK> from experience.  However, I have watched the progress of their
MK> respective development with interest.

I used both anything.el and Icicles for a long time (though I stopped
using Icicles a year ago).  They can't be merged.  At best you can pick
features from both.

MK> It is wrongheaded to arbitrarily incorporate external packages which
MK> duplicate existing core behaviour/features such that the duplication
MK> of the new (however useful) is better positioned to becomes the norm
MK> simply by virtue of the pain imposed on emacs-devels to retrofit a
MK> core API after the fact.

I disagree with your phrasing ("arbitrarily" and "duplication" in
particular) and your conclusions.

MK> IOW lets say anything.el were to be included in Emacs and it became so
MK> widely adopted that it was deemed worthwhile to attempt a retroactive
MK> metaleval API (including C primitives). Were Stefan or some other
MK> devel to endeavor implementation of such an API they might be hard
MK> pressed to maintain backwards compatibility with the existing
MK> anything.el procedures and prob. alienate the primary anything.el user
MK> base to boot.

Well, that's why I asked Stefan what his decision was.  If he says "no"
that's fine.  I think he can judge the effort and significance of an
alternative to the standard completion mechanism.

Ted

Re: more on anything.el inclusion

[rubikitch]

From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: more on anything.el inclusion
Date: Thu, 01 Jul 2010 08:18:03 -0500

Hi,

I'm the developer of anything.el.

> TV> On the user side, if you use anything-config.el, there is already build
> TV> in sources ready for use, so you can use provided functions like any
> TV> other emacs one (e.g M-x anything-xfonts).
> 
> OK.  Thanks for explaining.  So from the user's viewpoint, it should be
> enough to autoload all the front-end anything-* functions (from
> anything.el ideally, so users don't have to know about
> anything-config.el as you had it in your autoload example).  Can you
> make the necessary changes?  Or will that require major work?

We'll add autoload cookies to them.

> Is there a list of the standard front-end functions (a subset of the
> autoloads below) that should always be exposed (through keyboard
> mappings, possibly in a menu) to Emacs users?  The xfonts and file
> selection ones should be in that list for sure.

The preconfigured anything commands are too many to include into menus
and some commands overlap other commands.
For example, M-x anything-for-files handles buffers (M-x anything-buffers+),
recentf (M-x anything-recentf), bookmarks (M-x anything-bookmarks) and locate (M-x anything-locate).
We offer single source (anything-c-source-*) and multiple sources commands so that
users can select preferred commands.

Instead of binding all anything commands to menu and keymap,
I created a navigator command for anything-* commands.
M-x anything-execute-anything-command lists all anything commands in anything-config.el.
Users can search and select appropriate command.
Then users can bind it to keys.

I think small amount of commands should be bound to menu and keymap.


Cheers,
--
rubikitch

Re: more on anything.el inclusion

[Thierry Volpiatto]

rubikitch@ruby-lang.org writes:

> From: Ted Zlatanov <tzz@lifelogs.com>
> Subject: Re: more on anything.el inclusion
> Date: Thu, 01 Jul 2010 08:18:03 -0500
>
> Hi,
>
> I'm the developer of anything.el.
>
>> TV> On the user side, if you use anything-config.el, there is already build
>> TV> in sources ready for use, so you can use provided functions like any
>> TV> other emacs one (e.g M-x anything-xfonts).
>> 
>> OK.  Thanks for explaining.  So from the user's viewpoint, it should be
>> enough to autoload all the front-end anything-* functions (from
>> anything.el ideally, so users don't have to know about
>> anything-config.el as you had it in your autoload example).  Can you
>> make the necessary changes?  Or will that require major work?
>
> We'll add autoload cookies to them.
>
>> Is there a list of the standard front-end functions (a subset of the
>> autoloads below) that should always be exposed (through keyboard
>> mappings, possibly in a menu) to Emacs users?  The xfonts and file
>> selection ones should be in that list for sure.
>
> The preconfigured anything commands are too many to include into menus
> and some commands overlap other commands.
> For example, M-x anything-for-files handles buffers (M-x anything-buffers+),
> recentf (M-x anything-recentf), bookmarks (M-x anything-bookmarks) and locate (M-x anything-locate).
> We offer single source (anything-c-source-*) and multiple sources commands so that
> users can select preferred commands.
>
> Instead of binding all anything commands to menu and keymap,
> I created a navigator command for anything-* commands.
> M-x anything-execute-anything-command lists all anything commands in anything-config.el.
> Users can search and select appropriate command.
> Then users can bind it to keys.
>
> I think small amount of commands should be bound to menu and keymap.

It is already done, with a anything-command-map and a menu
(anything-config.el).
The prefix command is for the moment "<f5> a" for all anything commands.
The list or commands in menu and/or in anything-command-map should be
discussed, the prefix "f5 a" also.

>
> Cheers,
> --
> rubikitch
>
>

-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: more on anything.el inclusion

[Stefan Monnier]

SM> I haven't delved far enough to give much further details.  I think it
SM> would be good to try and decouple some of those aspects, especially
SM> since I think that some of them could be included in
SM> completion-list-mode (i.e. in the default UI).

> Does this mean you'd rather not include anything.el in Emacs?

No.


        Stefan

Re: more on anything.el inclusion

[rubikitch]

From: Stefan Monnier <monnier@IRO.UMontreal.CA>
Subject: Re: more on anything.el inclusion
Date: Fri, 23 Jul 2010 17:35:42 +0200

> SM> I haven't delved far enough to give much further details.  I think it
> SM> would be good to try and decouple some of those aspects, especially
> SM> since I think that some of them could be included in
> SM> completion-list-mode (i.e. in the default UI).
> 
> > Does this mean you'd rather not include anything.el in Emacs?
> 
> No.

Thanks. I'm working on anything.el to be included in Emacs.
I filled most of long lines within 80 columns.

Cheers,
--
rubikitch

Re: more on anything.el inclusion

[Ted Zlatanov]

On Sat, 24 Jul 2010 06:49:06 +0900 (JST) rubikitch@ruby-lang.org wrote: 

r> Thanks. I'm working on anything.el to be included in Emacs.
r> I filled most of long lines within 80 columns.

Any chance this will be available for review soon?

Thanks
Ted

Re: more on anything.el inclusion

[rubikitch]

From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: more on anything.el inclusion
Date: Thu, 12 Aug 2010 18:02:25 -0500

> On Sat, 24 Jul 2010 06:49:06 +0900 (JST) rubikitch@ruby-lang.org wrote: 
> 
> r> Thanks. I'm working on anything.el to be included in Emacs.
> r> I filled most of long lines within 80 columns.
> 
> Any chance this will be available for review soon?

The public repository is available: ssh://repo.or.cz/srv/git/anything-config

--
rubikitch

Re: more on anything.el inclusion

[Juri Linkov]

>> Any chance this will be available for review soon?
>
> The public repository is available: ssh://repo.or.cz/srv/git/anything-config

Since elpa.gnu.org is accessible now, there's a good chance
to add anything to elpa.gnu.org.

Re: more on anything.el inclusion

[Thierry Volpiatto]

Hi Ted, and sorry for late reply.

rubikitch@ruby-lang.org writes:

> From: Ted Zlatanov <tzz@lifelogs.com>
> Subject: Re: more on anything.el inclusion
> Date: Thu, 12 Aug 2010 18:02:25 -0500
>
>> On Sat, 24 Jul 2010 06:49:06 +0900 (JST) rubikitch@ruby-lang.org wrote: 
>> 
>> r> Thanks. I'm working on anything.el to be included in Emacs.
>> r> I filled most of long lines within 80 columns.
>> 
>> Any chance this will be available for review soon?
>
> The public repository is available: ssh://repo.or.cz/srv/git/anything-config

As you guess i think, this access to anything repo is not public, the
public access to anything is:

URL             git://repo.or.cz/anything-config.git
                http://repo.or.cz/r/anything-config.git

Use the git url to clone and the http one to browse.

-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: more on anything.el inclusion

[Thierry Volpiatto]

Hi Juri,
Juri Linkov <juri@jurta.org> writes:

>>> Any chance this will be available for review soon?
>>
>> The public repository is available: ssh://repo.or.cz/srv/git/anything-config
>
> Since elpa.gnu.org is accessible now, there's a good chance
> to add anything to elpa.gnu.org.

Yes of course, but having anything in emacs would be better.

-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997