Re: Various issues

Adriaan de Groot wrote:

> On Sat, 9 Aug 2003, Bram Moolenaar wrote:
> 
> > > * :do something $source { filetype=h } sets the source name to
> > > $source{filetype=h} - not what you would expect. And sufreplace() on such
> > > a broken filename leaves the trailing } in place.
> >
> > Well, if you give attributes to the source file(s), they end up in the
> > value of $source.  That's what you specified.  You can use $-source to
> > get rid of the attributes.  An alternative would be to remove the
> > attribute from $source and put it on the node, but you probably wanted
> > this filetype to be used only when invoking the action, not as _the_
> > filetype for this source.
> 
> An example where $-source isn't trivial to realize is in Python code - the
> archetypical `sufreplace("",".h",source)`, say. I'm working around it now
> with tsrc=$-source and then using tsrc instead in my Python snippets.

It would be possible to add Python functions that do the equivalent of
$-var, $?var, etc.  But why add more functions to learn to use when
going through another variable does it with the existing functionality?

This is what you would use now:

	s = $-source
	@if s == "foo.c":

Is this really simpler?

	@if strip_attr(_no.source) == "foo.c":

I think it just makes things more complicated.  My intention was to only
use Python for flow control and where it's really needed.  Duplicating
things that you can also do with Aap commands is to be avoided.  Only
when there is a good reason it would be implemented as a Python
function.

> > That a trailing } is left behind is a bug in sufreplace().  Another bug
> > in that function in a short time.  I think I'll have to change it into
> > something more clever than just using a string replacement on the whole
> > argument.
> 
> I've coded up a replacement of sorts, that has the side effect that in the
> sufreplaced list all the attributes are gone. It's on another machine
> though, I'll send it in on the weekend.

Hmm, I don't think the side effect of dropping the attributes is
desired.  It's always better to have a function do one thing.  It should
be fairly simple to keep the attributes, using str2dictlist() and
dictlist2str().

> > > 	- adding support for dir supportin :child so you can say :child
> > > dirname and have AAP read that as :child dirname/main.aap
> >
> > I suppose you see this as a way to specify sub-projects by the name of
> > the directory.  Is leaving out "/main.aap" enough advantage to add code
> > for this and let the casual user guess that "/main.aap" is automatically
> > appended?
> 
> Ideally the same support would be added to :execute . After all, when
> running AAP if you don't mention the recipe name it looks for main.aap.
> That suggests to me that whenever you go about specifying another recipe,
> if there's no explicitly mentioned recipe, then it should look for
> main.aap (there) instead.

I can follow your reasons, but I do see a difference between a command
you type ("aap doit" instead of "aap -f main.aap doit") and a recipe
that's edited once and executed many times.

On the command line you don't give a directory name.  It's either
nothing, which makes Aap search for "main.aap", or the name of the
recipe.  Being consistent means ":execute" without an argument would
execute "main.aap".  Not very useful though (more likely to be a mistake
of the recipe writer).

> > > 	- adding support for multiple children, so you can say :child dir1
> > > dir2 dir3
> >
> > Why not use separate commands?
> 
> It's something of an automake holdover. :child $SUBDIRS seems much more
> convenient that "for i in var2list(SUBDIRS): :child $i". Maybe it never
> happens.

Ah, if you assign the list of subdirectories to a variable I can see the
point of ":child" accepting a list of recipes.  But you might as well
call it $CHILDREN and give the recipe names.  Note that they could be in
the same directory as the current recipe.  Mixing file names with
directory names may be a bit confusing.

Why not keep it simple and require mentioning the recipe name?
Supporting multiple recipes for ":child" would be possible.  Should also
do it for ":execute" then.

> A lot of this stuff is convenient for my automake wedge - a few aap
> patches and some recipes that make transitioning an automake+based
> application to AAP as simple as
> 
> :include am.aap
> 
> it works fairly well on KDE's Makefile.am's, except where exotic AM stuff
> like conditionals and includes comes in.

If you are experienced with automake you might have a specific view on
how things are "normally" done.  However, don't forget that someone that
doesn't know automake may be puzzled.  I don't like all the things the
automake does (especially the idea that other files are generated, which
means there are multiple file formats).

I think we should be selective in what we take over in Vim.  Trying to
keep it simple (no need to read the documentation to understand how it
works) and predictable (mistakes lead to an error message, not strange
behavior) are important.

-- 
hundred-and-one symptoms of being an internet addict:
108. While reading a magazine, you look for the Zoom icon for a better
     look at a photograph.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01