Re: [patch] sawfish.wm.util.prompt

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 :)


Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]