librelist archives

« back to archive

[PATCH] y_or_n

[PATCH] y_or_n

From:
Philip Hudson
Date:
2014-01-24 @ 11:26
Trying to get the moral equivalent of emacs' (fset 'yes-or-no-p
'y-or-n-p). The attached refactoring patch introduces a JS var
`options_for_yes_or_no', initialized with the pre-existing value of [
"yes", "no" ]. This enables the user to set a value of [ "y", "n" ] in
their rc. Should be minimal impact; only question is whether this
should be a user preference. (I vote no).



-- 
Phil Hudson                  http://hudson-it.no-ip.biz
@UWascalWabbit                 PGP/GnuPG ID: 0x887DCA63

Re: [PATCH] y_or_n

From:
Scott Jaderholm
Date:
2014-01-24 @ 13:57
Personally I hope this feature can get accepted. I wrote a similar patch
several years ago, but it was rejected because it actually added y and n
instead of leaving it up to the user.

On Fri, Jan 24 2014,Philip Hudson wrote:

> This enables the user to set a value of [ "y", "n" ] in their rc.

I think as-is your patch won't work in that case because it leaves the
line:

  yield co_return(result == "yes")

which maybe should be:

  yield co_return(result == options_for_yes_or_no[0])

Note I haven't actually tried it.

A feature that might be nice, though I realize it adds more complexity
and I'm fine with it being absent, would be to allow more than two
options for yes and no, such as allowing both yes, no, y, and n. I'm not
sure the best way to support this, and the code below won't work because
Object.keys isn't supported in Xulrunner 1.9.x, but the general idea is:

  var options_for_yes_or_no = {yes: true, no: false};
  minibuffer.prototype.read_yes_or_no = function () {
      keywords(arguments);
      var result = yield this.read_explicit_option(forward_keywords(arguments),
          $options = Object.keys(options_for_yes_or_no));
      yield co_return(options_for_yes_or_no[result]);
  };

Then the user could use this:

  options_for_yes_or_no["y"] = true;
  options_for_yes_or_no["n"] = false;

Cheers,
Scott

Re: [conkeror] Re: [PATCH] y_or_n

From:
Philip Hudson
Date:
2014-01-24 @ 19:59
could not decode message