[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] cygwin support for tla, thoughts
From: |
michael Josenhans |
Subject: |
Re: [Gnu-arch-users] cygwin support for tla, thoughts |
Date: |
Tue, 04 Nov 2003 23:50:02 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 |
>>>>>> "Tobias" == Tobias C Rittweiler <address@hidden> writes:
> >> Tom, your design sense is generally excellent; can you explain
> >> that design decision to us?
> Tobias> AFAIK one reason is, because it this way works better for
> Tobias> him and his emacs filemanager thingy. At least, he told me
> Tobias> so once, probably sarcastically.
>It wasn't sarcasm.
>This is good design given the infrastructure. In Unix, it's easy to
>do (split-string path "/"). With Tom's design, you do
>(split-string (last (split-string path "/")) "--")
>and now the program knows at what depth you are, simply by counting
>the elements of the return value. Similarly, for presentation to
>humans, simply (last (split-string path "/")) tells a human exactly
>where in the hierarchy you are. The use of Lisp here is deliberate;
>even if you never learned any Emacs Lisp, the algorithm is so
>straightforward I bet you can tell what those expressions do.
>With a .../$CAT/$BRN/$VER structure, on the other hand, the parsing
>program needs to know a lot more about arch. This means that
>separately written tools will quickly start to constrain the
>Arch-itect's options for redesign. Helper programs get complex and
>fault-prone; algorithms are abandoned in favor of heuristic
Then why not have the depth level at the end of every directory
E.g. why not have
gar:0/mainline:1/1.0:2/patch-*:3
instead of
gar/gar--mainline/gar--mainline--1.0/patch-*
This should cut down the length and would surely work with LISP too.
Michael
- Re: [Gnu-arch-users] cygwin support for tla, thoughts,
michael Josenhans <=