Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ihlpa.att.com!danj1 From: danj1@ihlpa.att.com Newsgroups: gnu.emacs.bug Subject: shell-command-on-region should also insert result; LISP args Message-ID: <9002271824.AA20556@life.ai.mit.edu> Date: 27 Feb 90 18:18:00 GMT Sender: daemon@tut.cis.ohio-state.edu Distribution: gnu Organization: GNUs Not Usenet Lines: 56 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, 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