librelist archives

« back to archive

[PATCH] y_or_n

[PATCH] y_or_n

Philip Hudson
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        
@UWascalWabbit                 PGP/GnuPG ID: 0x887DCA63

Re: [PATCH] y_or_n

Scott Jaderholm
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

  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 () {
      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;


Re: [conkeror] Re: [PATCH] y_or_n

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