danj1@ihlpa.att.com (02/28/90)
Help> shell-command-on-region [ ESC | ]:
Help> Execute string COMMAND in inferior shell with region as input.
Help> Normally display output (if any) in temp buffer;
Help> Prefix arg means replace the region with it.
But I should also get to insert (but not replace) the text too if I
want, using, say, an alternative prefix argument. Which brings up an
interesting point I recently discussed with SuperCite author Barry A. Warsaw:
> "Dan" == Me, <Dan_Jacobson@ATT.COM> writes:
Dan> Here's someting from sc-describe:
sc> Variable: sc-nested-citation-p
sc> controls citation style. If nil, non-nested citations
sc> are used. If non-nil, old-style nested citations are
sc> used. Default: nil.
Dan> I see this in a lot of lisp: shouldn't have said nil or
Dan> non-nil... Let's say later you want to have a three way
Dan> decision, instead of the present 2 way. Since you said
Dan> "non-nil", some users will have "t", some "1", etc. this makes
Dan> future differentiation of the non nil choices not upwardly
Dan> compatible with a person's .emacs file. You should have
Dan> specified "(at present) valid choices are nil and t".
Same above for shell-command-on-region. It would have been best not to
use up all the prefix arguments for the same outcome.
Dan> This isn't "your fault" but a common thing I see in people's
Dan> code for emacs. Since I'm a lisp dumbo, tell me if I'm not off
Dan> my rocker and if this kind of general complaint is worth
Dan> posting to comp.emacs, etc.
[I'm just gonna send this to bug-gnu-emacs for now.]
Barry> Yeah, I just kind of followed the conventions I noticed in the elisp
Barry> that I "consulted". So much of elisp programming (and probably
Barry> programming in general) is done by swiping bits and pieces of other
Barry> code. This is good in that we all learn from other's experience
Barry> through the propagation of good code, but we also, bad habits tend to
Barry> propagate as well. In general though, the "nil/non-nil" specification
Barry> is meant to say that this is a simple binary decision. The "-p"
Barry> suffix also indicates that this is a binary decision, the "p" standing
Barry> for predicate (or some would say it looks a bit like a question mark:
Barry> "?"). In general, if I make a change from a binary decision to a
Barry> multiple decision, I'll remove the "-p" and perhaps rename the
Barry> variable so that upgrades can provide either some backward
Barry> compatibility, will be easily caught, or will produce no unwanted side
Barry> effects. Not perfect, but that seems to be "the way its done".
[Ok, ok... I shouldn't have used a -p one for my example, but there
are lots of e-lisp out there that burn up all those different non-nil
values, giving them all the same meaning without regard to future
extensions perhaps wanting to differentiate between these values.]
[of course SuperCite and Barry are still super in my view. He is just
my unlucky example victim.]
Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364