Re: Non-patch: zle argument handling

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jun 20,  4:31pm, Peter Stephenson wrote:
} Subject: Non-patch: zle argument handling
}
} Here is what I think I've done:

Sounds good to me.

} Another possible suggestion: We could remove all the feep()'s from the code
} and feep() if and only if the widget returned 1.

I like this idea.

} For user-defined widgets, we could have a special function to allow
} them to feep and a special option to zle that will suppress the feep
} for any other widget, so that simple zle -N's work without extra error
} handling.

I presume that in this scheme an un-suppressed feep() would abort the
widget, as I believe currently happens?

} (By the way, what does feep mean?)

It means "failure beep."  (Actually, it probably just means "beep", but
I think some curses packages already have a beep() function so PF had to
pick a different name.)

} --- Doc/Zsh/builtins.yo.argdoc	Thu Jun 17 16:53:03 1999
} +++ Doc/Zsh/builtins.yo	Sun Jun 20 16:09:55 1999
} @@ -682,12 +682,15 @@
}  With this flag set the return value is zero only if the character was
}  `tt(y)' or `tt(Y)'.  Note that this always reads from the terminal, even
}  if used with the tt(-p) or tt(-u) or tt(-z) flags or with redirected input.
} +May be called from a zle widget, in which case it will use zle to retrieve
} +a key.
}  )

How about:

   With this flag set the return value is zero only if the character was
   `tt(y)' or `tt(Y)'.  Note that this always reads from the terminal, even
   if used with the tt(-p) or tt(-u) or tt(-z) flags or with redirected input.
  +When called from a zle widget, zle is used to read from the terminal.

However, I don't see what possible difference this makes, as only one key
is read in any case, and it's still going to be interpreted as either `y'
for `yes' or anything else for `no'.

}  item(tt(-k) [ var(num) ])(
}  Read only one (or var(num)) characters.  All are assigned to the first
}  var(name), without word splitting.  This flag is ignored when tt(-q) is
}  present.  Input is read from the terminal unless one of tt(-u) or tt(-p)
} -is present.
} +is present.  May be called from a zle widget with no tt(-u)
} +or tt(-p) argument, in which case it will use zle to retrieve a key.
}  )

Does this imply when called from that var(num) is ignored and exactly one
key is read regardless?  That seems broken to me.  If that's not what it
means, then what difference does it make that zle is involved?  Things
should only get documented if they are visible behavior changes; and then
what you need to document is the behavior, not the implementation.

} +++ Doc/Zsh/zle.yo	Sun Jun 20 16:27:38 1999
} @@ -102,6 +102,8 @@
}  User-defined widgets, being implemented as shell functions,
}  can execute any normal shell command.  They can also run other widgets
}  (whether built-in or user-defined) using the tt(zle) builtin command.
} +They can use tt(read -k) or tt(read -q) to read characters from standard
} +input, which will use the appropriate tt(zle) key input mechanism.
}  Finally, they can examine and edit the ZLE buffer being edited by
}  reading and setting the special parameters described below.

Again, what does it *mean* to "use the appropriate key input mechanism"?

Otherwise this stuff all looks great.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com