Variable namespaces, goals for ZLE, etc.

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 9,  9:02pm, Zefram wrote:
} Subject: Re: User-defined zle widgets and built-in widget failure
}
} Bart Schaefer wrote:
} >I think I'd rather not have to rewrite my .z* scripts again.  How much
} >"moving" are we talking about?
} 
} Actually, I don't anticipate permanently removing names established
} in 3.0.  An option, on by default in zsh mode, would enable the current
} names.  Those that take the time to rewrite their .z* scripts can then
} disable the current names, and get a parameter namespace as clean as
} possible.

What we need is a way to link variable names to one another, with a few
options for how the linkage is accomplished.  The options would include
having the names share a value, automatic array-to-colon-list conversion
(and back), etc.  It'd also be useful to be able to define the way that
import and export are performed (in which case the imported and exported
values might be separate).

} If we *don't* introduce a proper namespace scheme, I hate to think what
} will happen when modules gain the ability to define special parameters.

I don't expect it'd be any worse than the current situation with external
programs having to come up with names for their environment variables.
If you can explain why a namespace like "zsh." is better than a simple
convention like "ZSH_", I'm willing to be persuaded.  However, the only
reason for introducing naming hierarchy (even if only one level of it as
you've so far proposed) is to be able to manipulate entire hierarchies
as single entities.  If the name of the space is not useful except as a
differentiating prefix, then it's better simply to use a prefix.

} This is probably a good time to talk about what I've been doing for the
} past year.

Sounds like a pretty fun job.

} three basic aims:
} 
} 	(1) as little as possible should be built into the base zle module
} 
} 	(2) built-in widgets should use the same interfaces as
} 	    user-defined ones, so that they behave *as if* they were
} 	    shell functions
} 
} 	(3) as much of the ZLE state as possible should be directly
} 	    manipulable by user-defined widgets

I don't disagree with any of those.  However, don't go overboard with (1).
An example of a case where I think that idea was carried too far is with
the removal of so many of the default compctls in 3.1.4.  It seems quite
contradictory to me to turn on by default every flashy zle option, but to
turn off all the even-more-useful completion defaults. 

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com