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

[Jeremy Hankins <nowan nowan org>]

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.  ;)

-- 
Jeremy Hankins <nowan nowan org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03