Date: Wed, 3 Oct 2001 01:22:59 -0500 From: Mike Meyer <mwm@mired.org> To: Paul Robinson <paul@akita.co.uk>, Rahul Siddharthan <rsidd@physics.iisc.ernet.in>, j mckitrick <jcm@FreeBSD-uk.eu.org>, Brad Knowles <brad.knowles@skynet.be>, Jonathan Chen <jonathan.chen@itouch.co.nz> Cc: "Gary W. Swearingen" <swear@blarg.net>, freebsd-chat@FreeBSD.ORG, David Scheidt <rufus@brain.mics.net> Subject: Editors et. al (Was: code density vs readability) Message-ID: <15290.44739.763131.336545@guru.mired.org> In-Reply-To: <20011002145631.C33832@jake.akitanet.co.uk> References: <20010927141333.A44288@dogma.freebsd-uk.eu.org> <p05100334b7d8e6544d17@[194.78.144.27]> <20011002133112.B98079@dogma.freebsd-uk.eu.org> <20011002135226.A33832@jake.akitanet.co.uk> <20011002142257.C98079@dogma.freebsd-uk.eu.org> <dxitdxlx44.tdx@localhost.localdomain> <20011003091251.A80459@jonc.itouch> <20011002204238.B22031@lpt.ens.fr> <20011002195955.C148@dogma.freebsd-uk.eu.org> <20011002213051.A28111@lpt.ens.fr> <p05100323b7dfe42a5979@[194.78.144.27]> <Pine.BSI.4.20.0110021606080.7990-100000@brain.mics.net> <20011002214655.A1713@dogma.freebsd-uk.eu.org> <20011002145631.C33832@jake.akitanet.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Robinson <paul@akita.co.uk> types:
> for(
> i = 0;
> i < top_of_count;
> i++
> ){
>
> ...
>
> }
>
> Which I dare say you won't find on any other sites, and you probably
> wouldn't use yourself. Indenting is fine, but the idea behind this is that
> in ed I can do say '/i++' and it will find the above line, which I can
> replace with 's/i/i = a' to produce the line 'i = a++', but perhaps with
> some escaping on the command to be safe. Seems weird, but sometimes it needs
> to be done that way. Thankfully not very often. :-)
Um - you just saved one (1) keystroke. Is that really worth the cost
you're paying by not using:
for (i = 0; i < top_of_count; i++) {
This has the same number of characters as your example, and you make
your change with '/i++' and 's//i = a++' or 's/++/ = a&'. It also has
the advantage that you know *which* for loop you've found with '/i++'.
Rahul Siddharthan <rsidd@physics.iisc.ernet.in> types:
> Gary W. Swearingen said on Oct 2, 2001 at 11:23:23:
> > I got to worrying about the amount of Emacs code there is and to suspect
> > that much of it changes often and is seen by only a few eyes and am
> > thinking it will be safer from a security standpoint to run vi.
> > Is that overly paranoid? Do other people have this concern?
> It certainly never occurred to me to worry about the security of an
> editor. Now that you have mentioned it, I'm still not worrying. (I
> use vim, not emacs. <flamebait>I love vim and detest FreeBSD's
> default nvi, one of the few things I dislike in FreeBSD but it's
> easily fixed.</flamebait>)
I think it's a *little* paranoid. If the emacs in questions evaluated
the value of file variables, it would certainly be justified. On the
other hand, I use the gnuclient feature and just leave one copy of
emacs around for everything. I don't like the idea of doing that as
root, so I tend to use vi there to make sure I don't start it. Unless
the change is for only one line, in which case I tend to use ed
because it's faster than vi.
Since the vi clones are being discussed, would someone know if one of
them had an incremental search ability? That would make vi faster than
ed for those one-line changes when I'm on a fast connection.
j mckitrick <jcm@FreeBSD-uk.eu.org> types:
> Why do some people, especially advanced programmers, hate this feature
> so much? Isn't it great for catching misspellings before compiling, and
> for helping the eye locate a target? It also seems good for helping the
> mind quickly understand the structure of the code. It simply includes
> more valuable information. I realize it can be overdone, but since you
> can configure it any way you like, why is it so bad? Why does
> everything that makes programming easier get labeled a 'crutch' at some
> point? I mean, LINT could be called a remedy for poor programming
> skills in the first place, but many accomplished programmers us it,
> correct? </rant>
I don't think all advanced programmers hate this feature. I can take
it or leave it. If I were forced to use an editor without syntactic
indenting - which helps catch some of the problems you named - I might
want it more often.
As for LINT, that's a remedy for poor language design, not poor
programming skills. [Donning flame retardant suit.]
Brad Knowles <brad.knowles@skynet.be> types:
> I've never seen anything from any other program that could begin
> to compare with the paragraph formatting available in "par". Does
> vim incorporate this code from par, or have you compared the two?
From looking at the pkg description, it looks like the emacs paragraph
formatting code is comparable. It allows the user to specify
paragraph delimiters and protected lines, and handles prefixes as
described. It works wonders for squaring quots in mail.
Jonathan Chen <jonathan.chen@itouch.co.nz> types:
> On Tue, Oct 02, 2001 at 11:23:23AM -0700, Gary W. Swearingen wrote:
>
> [...]
> > I got to worrying about the amount of Emacs code there is and to suspect
> > that much of it changes often and is seen by only a few eyes and am
> > thinking it will be safer from a security standpoint to run vi.
>
> Yup. You never know what's hidden as easter-eggs in emacs. I came
> across one the other day at:
>
> http://ars.userfriendly.org/cartoons/read.cgi?id=20010928&tid=134701
That one's documented, and not in the emacs I'm using, but I run
xemacs from xemacs.org, not the ports tree. You might also try the
"zippy" command, which spits out quotes from zippy the pinhead. I even
have - or maybe had - a function that conntected the two, so that the
doctor was analyzing zippy the pinhead.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/
Q: How do you make the gods laugh? A: Tell them your plans.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15290.44739.763131.336545>