tree widget

tree widget

[Masatake YAMATO]

How do you think including tree-widget developed by David PONCE 
in emacs official distribution?

screenshot -> http://emhacks.sourceforge.net/tw-shots.html

It may be useful to represent branches of version control systems
in a buffer.

Masatake YAMATO

Re: tree widget

[Dhruva Krishnamurthy]

Hello,

On Thu, 08 Apr 2004 21:07:48 +0900 (JST), "Masatake YAMATO"
<jet@gyve.org> said:
> How do you think including tree-widget developed by David PONCE 
> in emacs official distribution?
> 
> screenshot -> http://emhacks.sourceforge.net/tw-shots.html
> 
> It may be useful to represent branches of version control systems
> in a buffer.

I would personally welcome that. Rendering an XML file, showing EBROWSE
data and lot of other hierarchical data display could use that (function
call graphs). I have plans of writing a simple project planning tool with
dependencies, this tree view will be great.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: tree widget

[Mario Lang]

[-- Attachment #1.1: Type: text/plain, Size: 706 bytes --]

Masatake YAMATO <jet@gyve.org> writes:

> How do you think including tree-widget developed by David PONCE 
> in emacs official distribution?

I'd personally very much like that.  I use tree-widget.el for several little
pet-projects of mine, and I find it is a very useful and powerful package.
scid-browser.el in the chess.el CVS repository uses it to display a
tree of available games in the database, and gspi[1] uses it to
display the GNOME desktop accessibility information.  In both projects,
it has proofen to be very useful.

I also like it since it is a living example that widget.el can actually
be used for more than just plain custom buffers.

[1] http://delysid.org/gspi.html

-- 
CYa,
  Mario

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

~/{arch} causes an error in find-file

[Masatake YAMATO]

Hi,

After I created an tla archive at ~/{arch}, C-x C-f raise an error.
I have found that vc-workfile-version used in vc-arch-mode-line-string
returns nil. A temporary solution is attached.

Masatake YAMATO

2004-04-12  Masatake YAMATO  <jet@gyve.org>

	* vc-arch.el (vc-arch-mode-line-string): Return an empty
	string if `vc-workfile-version' returns nil.

cvs diff: warning: unrecognized response `access control disabled, clients can connect from any host' from cvs server
Index: lisp/vc-arch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-arch.el,v
retrieving revision 1.5
diff -u -r1.5 vc-arch.el
--- lisp/vc-arch.el	23 Mar 2004 21:36:49 -0000	1.5
+++ lisp/vc-arch.el	12 Apr 2004 03:32:50 -0000
@@ -309,15 +309,18 @@
 (defun vc-arch-mode-line-string (file)
   "Return string for placement in modeline by `vc-mode-line' for FILE."
   (let ((rev (vc-workfile-version file)))
-    (dolist (rule vc-arch-mode-line-rewrite)
-      (if (string-match (car rule) rev)
-	  (setq rev (replace-match (cdr rule) t nil rev))))
-    (format "Arch%c%s"
-	    (case (vc-state file)
-	      ((up-to-date needs-patch) ?-)
-	      (added ?@)
-	      (t ?:))
-	    rev)))
+    (if rev
+	(progn
+	  (dolist (rule vc-arch-mode-line-rewrite)
+	    (if (string-match (car rule) rev)
+		(setq rev (replace-match (cdr rule) t nil rev))))
+	  (format "Arch%c%s"
+		  (case (vc-state file)
+		    ((up-to-date needs-patch) ?-)
+		    (added ?@)
+		    (t ?:))
+		  rev))
+      "")))
 
 (defun vc-arch-diff3-rej-p (rej)
   (let ((attrs (file-attributes rej)))

Re: tree widget

[Masatake YAMATO]

>     How do you think including tree-widget developed by David PONCE 
>     in emacs official distribution?
> 
> Could you explain to me what that does?

As the name explains, the code provides widget
representing a tree hierarchy like:

[-] ./
 | [+] CVS/
 | [+] autom4te.cache/
 | [+] checks/
 | [-] src/
 |  | [+] .deps/
 |  | [+] .libs/
 |  | [+] CVS/
 |  |  .cvsignore*
 |  |  Makefile*
 |  |  Makefile.am*
 |  |  Makefile.in*
 |  |  TAGS*
 |  |  glibextra.c*
 |  |  glibextra.h*
 |  |  glibextra.lo*
 |  |  glibextra.o*
 |  |  libinda.la*
 |  |  linda.c*
 |  |  linda.h*
 |  |  linda.lo*
 |  |  linda.o*
 |  |  semantic.cache*
 |  |  tuplespace.c*
 |  |  tuplespace.h*
 |  |  tuplespace.lo*
 |  `  tuplespace.o*
 |  .cvsignore*
 |  AUTHORS*
 |  ChangeLog*
 |  HACKING*
 `  semantic.cache*

You can click [+] and [-] to show and hide the sub tree like
outline mode.

Masatake YAMATO

Re: ~/{arch} causes an error in find-file

[Stefan Monnier]

> After I created a tla archive at ~/{arch},

Do you really mean an archive?  As in `tla make-archive ~/{arch}'?
That sounds like a really dumb choice of name.
It's like choosing ~/CVS for your $CVSROOT.

I've committed a different fix.  Can you try it?


        Stefan

Re: ~/{arch} causes an error in find-file

[Masatake YAMATO]

> Do you really mean an archive?  As in `tla make-archive ~/{arch}'?
> That sounds like a really dumb choice of name.
> It's like choosing ~/CVS for your $CVSROOT.

I am new to arch. I found it on "Arch Recipes"
http://wiki.gnuarch.org/moin.cgi/Arch_20Recipes

So, some people may use the name.

> I've committed a different fix.  Can you try it?
It works fine. Thank you.


Masatake YAMATO

Re: ~/{arch} causes an error in find-file

[Miles Bader]

On Mon, Apr 12, 2004 at 01:56:18PM +0900, Masatake YAMATO wrote:
> I am new to arch. I found it on "Arch Recipes"
> http://wiki.gnuarch.org/moin.cgi/Arch_20Recipes
> 
> So, some people may use the name.

Yeah, that's a silly habit some people have (apparently for pretty arbitrary
historical reasons); I'll change the wiki to not recommend it.  There's no
reason at all to use braces.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: ~/{arch} causes an error in find-file

[Stefan Monnier]

>> I am new to arch. I found it on "Arch Recipes"
>> http://wiki.gnuarch.org/moin.cgi/Arch_20Recipes
>> So, some people may use the name.
> Yeah, that's a silly habit some people have (apparently for pretty arbitrary
> historical reasons); I'll change the wiki to not recommend it.  There's no
> reason at all to use braces.

And it makes it pretty much impossible to use Arch for your home directory
(like I'm trying to do here).


        Stefan

Re: tree widget

[Kim F. Storm]

Masatake YAMATO <jet@gyve.org> writes:

> >     How do you think including tree-widget developed by David PONCE 
> >     in emacs official distribution?
> > 
> > Could you explain to me what that does?
> 
> As the name explains, the code provides widget
> representing a tree hierarchy like:
> 
> You can click [+] and [-] to show and hide the sub tree like
> outline mode.

Doesn't speedbar already have code to do that?  But maybe not in a
generally useful way...?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: tree widget

[Mario Lang]

storm@cua.dk (Kim F. Storm) writes:

> Masatake YAMATO <jet@gyve.org> writes:
>
>> >     How do you think including tree-widget developed by David PONCE 
>> >     in emacs official distribution?
>> > 
>> > Could you explain to me what that does?
>> 
>> As the name explains, the code provides widget
>> representing a tree hierarchy like:
>> 
>> You can click [+] and [-] to show and hide the sub tree like
>> outline mode.
>
> Doesn't speedbar already have code to do that?  But maybe not in a
> generally useful way...?

That is the point.  Speedbar can not really be reused
outside of the speedbar itself.  tree-widget can be used
in every buffer that has received proper `widget-setup'.
Appart from that, tree-widget has a really nice dynamical children
generation feature which you can use to draw a tree
collapsed, without having all the data for the whole tree ready.
Whenever the user expands a node, the children of that node
are retrieved by calling a function.  This is very very
handy for deeply branched trees.

Apart from that, since tree-widget is completely Widget based,
you can easily create things like a node with a text entry
field, without any major hassle.  I don't think that
speedbar makes this easy in any way.

-- 
CYa,
  Mario | Debian Developer <URL:http://debian.org/>
        | Get my public key via finger mlang@db.debian.org
        | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Re: tree widget

[Richard Stallman]

    >     How do you think including tree-widget developed by David PONCE 
    >     in emacs official distribution?
    > 
    > Could you explain to me what that does?

    As the name explains, the code provides widget
    representing a tree hierarchy like:

It sounds quite useful.  Could you post the code here
so that people can look at it?

Re: tree widget

[Masatake YAMATO]

[-- Attachment #1: Type: Text/Plain, Size: 589 bytes --]

>     >     How do you think including tree-widget developed by David PONCE 
>     >     in emacs official distribution?
>     > 
>     > Could you explain to me what that does?
> 
>     As the name explains, the code provides widget
>     representing a tree hierarchy like:
> 
> It sounds quite useful.  Could you post the code here
> so that people can look at it?

I attached .tar.gz file got from
http://sourceforge.net/project/showfiles.php?group_id=79309&package_id=81112

I would like David PONCE to explain the cutting edge version if such a 
version is existing.

Masatake YAMATO

[-- Attachment #2: tree-widget-2.0.tar.gz --]
[-- Type: Application/Octet-Stream, Size: 15822 bytes --]

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: tree widget

[David PONCE]

Hi,

> I would like David PONCE to explain the cutting edge version if such a 
> version is existing.

The latest version of tree-widget.el is available from the SF CVS at:

http://cvs.sf.net/viewcvs.py/*checkout*/emhacks/emhacks/tree-widget.el

Last changes since released version 2.0 were mainly to improve
portability and handling of images themes.  Here is the relevant
change log:

2003-11-24  David Ponce  <david@dponce.com>

	* tree-widget.el

	Add support for image properties by theme.  Improve portability.

	(tree-widget-create-image): Add new optional argument for image
	properties.
	(tree-widget--image-properties): New variable.
	(tree-widget-set-image-properties): New function.
	(tree-widget-find-image): Use it.  No depend of `locate-library'.

2003-10-06  David Ponce  <david@dponce.com>

	* tree-widget.el

	(tree-widget-image-type-available-p): Remove.
	(tree-widget-image-formats): Return supported formats.
	(tree-widget-find-image): Try each image file extension before
	searching in default theme.

Thanks for your interest in tree-widget.  Of course, I will be glad to
contribute it to GNU Emacs, and maintain it too, as my free time will
permit ;-)

David

Re: tree widget

[Per Abrahamsen]

Mario Lang <mlang@delysid.org> writes:

> Apart from that, since tree-widget is completely Widget based,
> you can easily create things like a node with a text entry
> field, without any major hassle.  I don't think that
> speedbar makes this easy in any way.

I haven't actually tried it, but being widget based, it ought to be
possible to use it as part of a customization type as well.

Re: tree widget

[David PONCE]

[...]
> How do you think including tree-widget developed by David PONCE 
> in emacs official distribution?

Hi All,

I received, and will shortly send back the signed paper
allowing to include tree-widget in the GNU Emacs distribution.  As I
got write access to CVS, I should be able to check it in myself.

In order to do so, I would like some advice about the following
points.

First, I suppose that tree-widget.el should go into the main lisp
directory?

The next point looks more promizing ;-)

tree-widget can use image themes to display nice-looking trees.  For
now, I created two graphical themes: a general purpose "default"
theme, and a file system oriented "folder" theme.  Each theme contains
a set of images with predefined names that represent the different
parts of the tree to draw.  When an image is not found in a particular
theme, the one in the "default" theme is used, so it is easy to create
a new theme by overriding only certain images.

>From an implementation point of view, a theme is a subdirectory in a
main theme directory:

 tree-widget-themes/
   default/
     <default-theme-images>
   folder/
     <folder-theme-images>

Choosing a theme, is simply to give the name of the corresponding
subdirectory.

The main theme directory is customizable, it can be an absolute name,
or the name of a subdirectory located respectively in the `load-path'
or in the `data-directory'.  By default, tree-widget search for a
"tree-widget-themes" subdirectory.

My question is where to install the theme directory?  In the lisp
directory (I am not convinced this is the right place), or in the
`data-directory' ("./etc"), which seems a better choice.

It is not clear to me where images (and other data files) specific to a
package should be installed.  To compare, in XEmacs things look
better: each package has its own data directory where you can put
images and other things.  A `locate-data-directory' function is
provided for packages to easily retrieve their data directory.  For
example tree-widget uses (locate-data-directory "tree-widget").

Perhaps it could be worth having a similar organization in "etc", that
is a sub-directory for each package that needs one for its data files.
This way the lisp directory would remain clean (only Elisp).

For example, there could be a "etc/tree-widget" directory where
tree-widget could search for the "built-in" themes.  It is easily to
use its own themes via a customized theme directory added to the
`load-path'.

I hope my explanations were clear enough.  Thank you so much for any
advice.

Regards.

David

Re: tree widget

[Kim F. Storm]

David PONCE <david.ponce@wanadoo.fr> writes:

> First, I suppose that tree-widget.el should go into the main lisp
> directory?

What about

        lisp/tree-widget/tree-widget.el

for the code and

        lisp/tree-widget/default/
        lisp/tree-widget/theme1/
        lisp/tree-widget/theme2/

etc for the various theme directories.
Then everything would be "self-contained".

> The main theme directory is customizable, it can be an absolute name,
> or the name of a subdirectory located respectively in the `load-path'
> or in the `data-directory'.  By default, tree-widget search for a
> "tree-widget-themes" subdirectory.

The lisp/tree-widget directory would automatically be added to the
load-path.

> Perhaps it could be worth having a similar organization in "etc", that
> is a sub-directory for each package that needs one for its data files.
> This way the lisp directory would remain clean (only Elisp).

Well, toolbar icons are in lisp/toolbar, so there is precedence for
having "support files" in lisp.

An alternative approach is to define those images directly in lisp
like gdb-ui.el does.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: tree widget

[David PONCE]

Hi Kim,

[...]
> What about
> 
>         lisp/tree-widget/tree-widget.el
> 
> for the code and
> 
>         lisp/tree-widget/default/
>         lisp/tree-widget/theme1/
>         lisp/tree-widget/theme2/
> 
> etc for the various theme directories.
> Then everything would be "self-contained".

That's a good idea!  If there is no objections, I will do that when possible.

Thanks!
David

Re: tree widget

[Richard Stallman]

    What about

	    lisp/tree-widget/tree-widget.el

    for the code and

	    lisp/tree-widget/default/
	    lisp/tree-widget/theme1/
	    lisp/tree-widget/theme2/

I don't want to add subdirectories of `lisp' that have
just a few files.  That would lead to lots of small subdirectories.
I don't see why a subdirectory would be helpful here.

Re: tree widget

[David Ponce]

Richard Stallman wrote:
>     What about
> 
> 	    lisp/tree-widget/tree-widget.el
> 
>     for the code and
> 
> 	    lisp/tree-widget/default/
> 	    lisp/tree-widget/theme1/
> 	    lisp/tree-widget/theme2/
> 
> I don't want to add subdirectories of `lisp' that have
> just a few files.  That would lead to lots of small subdirectories.
> I don't see why a subdirectory would be helpful here.

OK, but where do you suggest to put the images themes subdirectories
used by tree-widget?

What about my proposal based on `data-directory':

     etc/tree-widget/default/
     etc/tree-widget/theme1/
     etc/tree-widget/theme2/

Re: tree widget

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     What about
> 
> 	    lisp/tree-widget/tree-widget.el
> 
>     for the code and
> 
> 	    lisp/tree-widget/default/
> 	    lisp/tree-widget/theme1/
> 	    lisp/tree-widget/theme2/
> 
> I don't want to add subdirectories of `lisp' that have
> just a few files.  That would lead to lots of small subdirectories.
> I don't see why a subdirectory would be helpful here.

As I understand it, a tree-widget theme consist of a collection of
files (mostly images?) for that theme, and all files belonging to one
theme is contained in a separate subdirectory (so they can be named
equally.)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: tree widget

[Stefan Monnier]

> What about my proposal based on `data-directory':
>      etc/tree-widget/default/
>      etc/tree-widget/theme1/
>      etc/tree-widget/theme2/

Problem is that if it's in /usr/share/emacs/21.4/etc/tree-widget,
then user `monnier' can't add his own theme.
So we want to use a search-path like load-path or somesuch.
Until now we've just stuck to using load-path.


        Stefan

Re: tree widget

[David Ponce]

Stefan Monnier wrote:
>>What about my proposal based on `data-directory':
>>     etc/tree-widget/default/
>>     etc/tree-widget/theme1/
>>     etc/tree-widget/theme2/
> 
> 
> Problem is that if it's in /usr/share/emacs/21.4/etc/tree-widget,
> then user `monnier' can't add his own theme.
> So we want to use a search-path like load-path or somesuch.
> Until now we've just stuck to using load-path.

My proposal is to use `data-directory' for "built-in" themes.

tree-widget first lookup for a theme in the `load-path',
then in `data-directory'.

This way, you can add your own theme (or override a built-in theme)
via the load path.

David

Re: tree widget

[Richard Stallman]

    As I understand it, a tree-widget theme consist of a collection of
    files (mostly images?) for that theme, and all files belonging to one
    theme is contained in a separate subdirectory (so they can be named
    equally.)

That makes sense.  How many files are we talking about in each theme,
and how many themes?  What are the real names of the themes?