Re: PATCH: 3.1.6-bart-7: Self-loading auto-functions

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> One change that may be controversial is the output of "functions".  As was
> mentioned in the exchange I had with Zefram, it no longer puts "undefined"
> in front of an autoloaded function name.  In the course of changing that,
> I found that it might also output "traced" in that position, which for the
> purposes of making `eval $(functions)' work was equally annoying.  Further,
> it might be useful to differentiate an actual autoloaded function from one
> that merely calls "autoload -X".
> 
> So it now outputs comments like this:
> 
> foo() {
> 	# undefined
> 	# traced
> 	builtin autoload -X
> }
> 
> The comments use the user's $histchars[2], and you can tell a defined
> function from an undefined one because of course defined functions always
> have their comments stripped.  If anyone has a better idea for this, I'd
> be glad to see it changed.

I've fiddled with `parameter.c' a lot over the weekend, adding
parameters for the `compgen'-replacement. There I made `functions'
prepend a `<disabled>' prefix to report disabled shell functions (and
the same string in other parameters). I was thinking about using
comments, too, and I still think they are ok for functions, but in my
case I needed something that also worked for aliases -- and I hope
`<disabled>' is uncommen enough to be usable there.

> ...
> 
> There's one partial bug fix in the paramter.c diff below: Unloading the
> module would dump core when trying to unset the $dirstack parameter.  The
> remaining badness after the patch is that the dirstack gets erased as a
> side-effect of unloading the module, but at 2:15 AM I didn't feel like
> tackling that part.

There were some other problems. E.g. the strings stored in the pparam
struct should all be dupstring()ed (because the new pattern matching
code may try to store the trailing '\0' again). Also, they shouldn't
be tricat()ed, because that uses zalloc()ed memory which isn't freed
anywhere.

Since my code is currently far too different from anyone else's, I
don't send a patch for it now, it'll come together with the completion 
code stuff.

While I'm at it: does anyone have an idea how we can make the
parameter module report stuff about zle widgets and keymaps? I don't
see a solution (other than making parameter depend on zle which I
don't want to do). So in the first implementation at least, parameters 
for them will be in the zle module. Sigh.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de