emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: finder.el UI


From: Ted Zlatanov
Subject: Re: finder.el UI
Date: Mon, 22 Mar 2010 08:30:51 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.91 (gnu/linux)

On Sat, 20 Mar 2010 00:48:03 +0200 Juri Linkov <address@hidden> wrote: 

>> Is there any possibility of rethinking the UI of finder.el?  It's
>> very... episodic.

JL> Yes, the old finder UI was too ad-hoc.  This is the reason why
JL> there was a task in etc/TODO to replace it with the Info UI
JL> that I implemented for 23.2 with `M-x info-finder'.

Is that blocked by something else or just waiting for tuits?

I tried it and it's a browser that deadends at the commentary.  Wouldn't
it make sense to at least let the user browse the original package
sources?  But this is still much better than the old finder and I would
get rid of the old one.  But you mention another finder:

>> The BBDB UI, for instance, does a great job filtering and displaying a
>> few choices from a large list.  The Gnus summary/article buffers are
>> another good UI example, with the limiting commands.  package.el can
>> list hundreds of packages concisely.

JL> package.el has a different usage of keywords.  While Info UI is useful
JL> for informational purposes (to find a package etc.), the purpose of
JL> package.el is to select and install a package.  This requires
JL> a different UI.  I think the most convenient UI for this task
JL> would be UI like http://www.jurta.org/en/emacs/ee/finder

I looked.  I like that it has multiple views plus the ability to visit
the source code.

JL> Please note that I don't propose to use this package as is
JL> in package.el.  I'm referring to its UI that would be useful
JL> for package.el.

So I'm a little confused.  Is the jurta.org finder proposed for Emacs
inclusion?  Or is info-finder the way to go?

Either way, users who look for packages also like to install and
activate them, so IMHO it makes sense that all the finder UIs should
link to package.el installation+activation somehow, either internally by
calling package.el functions or externally by launching package.el, when
it's part of Emacs.

Ted





reply via email to

[Prev in Thread] Current Thread [Next in Thread]