Am Mittwoch, den 23.09.2009, 10:23 -0500 schrieb Jeremy Hankins: > Teika Kazura <teika lavabit com> writes: > > > I don't know if what I've displayed here is related to prompt[-*].jl > > problem, but remember, there *is* a bug(s). > > I can't say for sure either, but it may be related. It's true that > prompt.jl is doing stuff with redefinition of functions and manipulating > scope to get (prompt) calls to complete, etc., in the right way. > > > Now, dear Sawfish lovers, it's really welcome to show that librep is > > buggy, and to exhibit exactly how it turns us down. If it gets rid of > > an issue of real problem, then it's good. But > > On Sat, 19 Sep 2009 18:59:28 +0300, Timo Korvola wrote: > >> The original code looks fine to me. > > > > So, the simplest solution will be to go back to the original one. > > Remember that we're in short of developers. Please use your energy to > > actually improve Sawfish, and don't get stuck on aesthetics. > > I agree that there's no bug in the original prompt code -- the patch > I've offered isn't a bugfix, it's (possibly) an improvement. > > Currently prompt.jl works by exposing much of its internal structure via > a bunch of defvar statements. These special variables refer to the > values and functions for doing things like completing input, validating > input, etc. The prompt code calls the functions these variables refer > to. (This is where the compilation warnings showed up: the variables > are defvar'd to nil and then treated like functions and passed arguments > later on. As Timo said, the compiler ought to realize that these > variables are going to be redefined before being called, and so > shouldn't try to predict the args it will accept.) > > When you want to call the prompt function you override the values of any > of the special variables you wish to override via a let statement. If I > have a special kind of input I want to ask for, and I want > tab-completion to work, I need to write the appropriate completion, > validation, and possibly abbreviation functions, and then call prompt > like this: > > (let ((prompt-completion-fun my-completion-fun) > (prompt-validation-fun my-validation-fun) > (prompt-abbrev-fun my-abbrev-fun)) > (prompt "Enter something:" "Default-Option")) > > What my patch does is change the way prompt is called to make it a bit > more transparent. Internally to prompt.jl, all of the defvars are now > defines, so they're strictly internal to the prompt module. Then prompt > is called via keyword arguments like this: > > (prompt #:title "Enter something:" > #:start "Default-Option" > #:completion-fun my-completion-fun > #:validation-fun my-validation-fun > #:abbrev-fun my-abbrev-fun) > > The reason I think this is a good idea is that I'm struck by how few > scripts there are on the wiki that actually use prompt. Maybe it's just > me, but I use prompt for all kinds of things. I have prompts to enter > machines to ssh to, I access menus via prompt (tab-completing like it's > a filesystem tree), I access a lot of lesser-used commands via prompt, > etc. But I have to admit that the learning curve back when I was > starting out was quite steep, and my guess is that this is what turns a > lot of potential hackers away from using prompt. My hope (and I could > be wrong) is that by hiding some of the complexity away and streamlining > the interface we can make prompt easier for script writers to learn and > use. (It would probably be a good idea to write a tutorial and/or > documentation on using prompt. I can do this, but I don't want to get > started until we decide if the interface is going to change.) > > The other benefit to the patch is more aesthetic: the current prompt > module puts a lot of stuff into the global namespace -- not only are > there a lot of special vars used to control prompt's behavior, but all > of the functions are defun's. So the patch should make prompt more > friendly to the module system, and perhaps less touchy as far as use > with other modules goes -- though I don't know that there's really been > a problem on this point up to now. > > > I'm sorry for being lazy, staying away form your discussions. I've > > been aware of the problem, but I've deffered the analysis until > > today. (One reason for my truancy is that your arguments level is > > higher than my understandings. I don't know lisp well. I've never > > understood fluid ;) > > No problem! I have to admit, when Mathew mentioned fluids I had to go > look them up.... They seem to be something like a safer, lispy kind of > pointer. > > > Thank you Matthew, Jeremy, Chris and Timo for your sincerity. > > > > # I wonder if someone could summarize the util.prompt discussion. > > I hope this helped. I often don't realize how obscure I'm being -- my > training is in philosophy, and I'm so used to getting blank stares when > I talk that I often don't notice any more. ;) > defun -> define is good in general, but still hadn't had time to test .. will do at least on friday :) Chris
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil