How many other editors in use
Chetan
I am surprised to find that most of the posts here are about vi or
vim. Aren't there other editors (besides the ones that have their own
groups) that people use?
--
Chetan
What's news?
Malcolm Dew-Jones
: I am surprised to find that most of the posts here are about vi or
: vim. Aren't there other editors (besides the ones that have their own
: groups) that people use?
This ought to be called the comp.editors.vi group.
One reason no one but vi users ever post here is because pretty much no
one but vi users ever post here. A chicken and egg problem if you want
non-vi editor assistance on Usenet (other than things like emacs that have
their own groups).
Another reason is because most other editors simply have other ways that
people get support, typically a web forum provided by the people who
created the editor.
Also, many other editors are basic tools that do pretty much what you want
at the time without needing to ask anyone for assistance, often because
the available options are accessible on a menu. For example, how much
help do you need in eclipse to refactor a java program - simply select a
likely looking option from the menu and if it doesn't work quite right
then press undo and try the next likely looking option until you find the
one that does what you want.
Perhaps it is because many of us who are using other tools are people who
work with other people who can show us the key tricks that aren't obvious
without having to post on Usenet.
You ask: Aren't there other editors that people use?
There are many other editors in use. For example in the last few hours I
have used notepad, pl/sql Developer, Oracle Forms Builder, my old text
editor standby sedt, plus perl to make a number of batch mode edits to
files. And that's not including non-text-editor editing in MS Word,
Excel, Outlook, and of course this message written using pico.
$0.10
Chetan
I started reading this newsgroup thinking I will find discussion of
editors in general, or text editors or programmer's editors. However,
most of the questions seem to be related to help for using vi (all).
No discussion of features or comparisons or such.
I guess you are right. If only vi users hang out here, it is unlikely
others will hang on if they aren;t interested in vi alone.
--
Chetan
Jeff Schwab
> I started reading this newsgroup thinking I will find discussion of
> editors in general, or text editors or programmer's editors. However,
> most of the questions seem to be related to help for using vi (all).
> No discussion of features or comparisons or such.
>
> If only vi users hang out here, it is unlikely
> others will hang on if they aren;t interested in vi alone.
That doesn't mean you should drop off this group, just because it's not
an all-in-one solution. Anyway, there's no prohibition on discussing
other editors here. If you have specific questions about
(emacs|SlickEdit|Notepad++|.*), somebody (though probably not me) will
likely be able to answer them.
Thomas E. Dickey
...but bear in mind that a vim-user will almost certainly join the thread,
ignore the OP's actual question, and state that the solution is to use vim.
(one of the hazards of reading comp.editors...)
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Paul Bartlett
> I am surprised to find that most of the posts here are about vi or
> vim. Aren't there other editors (besides the ones that have their own
> groups) that people use?
I glance at this ng and delete most of the posts unread, as I do not
use vi/clones. I use joe, and the last time I asked a joe question
here I got *zero* responses. I think this ng ought to be renamed
comp.editors.vi+clones so the rest of us can safely just not subscribe
to it and know that we are not missing anything.
--
Paul Bartlett
Jeff Schwab
> On Thu, 2 Apr 2009, Chetan wrote:
>
>> I am surprised to find that most of the posts here are about vi or
>> vim. Aren't there other editors (besides the ones that have their own
>> groups) that people use?
>
> I glance at this ng and delete most of the posts unread, as I do not
> use vi/clones. I use joe, and the last time I asked a joe question
> here I got *zero* responses.
I've never heard of the "joe" editor, and it doesn't show up in the
first page (10 results) of a Google search for "joe". Maybe you got
*zero* responses because you're using an editor that doesn't have a very
large user-base. (There's nothing wrong with that, but blaming the
editor-interest community for not knowing about this particular tool is
a bit of a stretch.)
> I think this ng ought to be renamed
> comp.editors.vi+clones so the rest of us can safely just not subscribe
> to it and know that we are not missing anything.
...or maybe the non-vi-derived editor folks could actually contribute
something of value. A link to "joe", for example, would have been
helpful. I'd also be interested to know the dis/advantages relative to
vim et al.
Aaron W. Hsu
>I am surprised to find that most of the posts here are about vi or
>vim. Aren't there other editors (besides the ones that have their own
>groups) that people use?
As has already been mentioned, many other editors have their own lists
or groups to which people post. However, I myself regularly switch
between using Vi and NEdit. On Windows I use Boxer Text Editor, and
on Mac I often use BBEdit.
If you want to have a general discussion about text editors, I'd be
happy to read it. :-)
--
Aaron W. Hsu <arc...@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
Paul Bartlett
> Paul Bartlett wrote:
>> On Thu, 2 Apr 2009, Chetan wrote:
>>
>>> [...]
>> I glance at this ng and delete most of the posts unread, as I do not
>> use vi/clones. I use joe, and the last time I asked a joe question
>> here I got *zero* responses.
>
> I've never heard of the "joe" editor, and it doesn't show up in the
> first page (10 results) of a Google search for "joe".
Strange. When I did a Google search for "joe editor" the very first
hit was for the home page at http://joe-editor.sourceforge.net . And
I am not very adept at all at using Google. (I rarely use it for that
very reason.)
> Maybe you got
> *zero* responses because you're using an editor that doesn't have a
> very large user-base. (There's nothing wrong with that, but blaming
> the editor-interest community for not knowing about this particular
> tool is a bit of a stretch.)
There was a time when Joe Allen himself as well as other users
frequented this ng. Possibly they got frustrated at the lack of
interest in non-vi/clones editors and just went away, as possibly
others have (and as I have often been tempted to do).
>> I think this ng ought to be renamed
>> comp.editors.vi+clones so the rest of us can safely just not subscribe
>> to it and know that we are not missing anything.
>
> ...or maybe the non-vi-derived editor folks could actually contribute
> something of value. A link to "joe", for example, would have been
> helpful.
As I indicated, I got the very first hit on it from Google. And some
time ago a link would not have been necessary.
> I'd also be interested to know the dis/advantages relative to vim et
I know enough (but care less) about vi/clones to know that I myself
could not make an effective comparison. I would not think that
expertise in vi/clones should be a prerequisite for participation in a
newsgroups that at least theoretically should be about "editors" and
not just one particular editor and its clones.
--
Paul Bartlett
Laurianne Gardeux
> [...] A link to "joe", for example, would have been
> helpful. [...]
Luka Djigas
<je...@schwabcenter.com> wrote:
>
>I've never heard of the "joe" editor, and it doesn't show up in the
>first page (10 results) of a Google search for "joe".
<sarcasm> I wonder why. I mean, searching for "joe" can only mean an
editor, right ? </sarcasm>
regards, Luka
Jeff Schwab
> vi/clones
Do you keep saying that just to be offensive? Vim isn't just a clone of vi.
Jeff Schwab
Thanks. It did eventually occur to me to search for "joe editor." :) I
was not aware of it, but I gather it's an emacs-influenced take on
another editor I've never seen in the wild, MicroPro WordStar.
Kaz Kylheku
> Paul Bartlett wrote:
>> On Thu, 2 Apr 2009, Chetan wrote:
>>
>>> I am surprised to find that most of the posts here are about vi or
>>> vim. Aren't there other editors (besides the ones that have their own
>>> groups) that people use?
>>
>> I glance at this ng and delete most of the posts unread, as I do not
>> use vi/clones. I use joe, and the last time I asked a joe question
>> here I got *zero* responses.
>
> I've never heard of the "joe" editor, and it doesn't show up in the
I remember a `Joe's Own Editor' (JOE) that I might have run once or
twice some 15 or 16 years ago.
Aha, and the reason was that I was using Slackware Linux at that time.
It was bundled.
It looks like Slackware still bundles this editor, today.
``The joe editor, written by Joseph H. Allen, is very easy to use for folks who
are coming to Linux from a DOS environment.'' --Slackware docs
Kaz Kylheku
Someone keeps posting a ``vi FAQ'' to this newsgroup which uses the same
clone terminology.
FAQ quote:
1.5 - What are some of the vi clones that are available?
Just to list a few: STvi (STevie), elvis, lemmy, vile, vim, and
nvi, xvi.
Strictly speaking, there are no vi clones, only implementations. A vi command
is standardized by POSIX and the Single Unix Specification.
The FAQ neglects to mention this or give links.
http://www.opengroup.org/onlinepubs/009695399/utilities/vi.html
http://www.opengroup.org/onlinepubs/009695399/utilities/ex.html
Jeff Schwab
> FAQ quote:
>
> 1.5 - What are some of the vi clones that are available?
>
> Just to list a few: STvi (STevie), elvis, lemmy, vile, vim, and
> nvi, xvi.
They missed my second-favorite, calvin.
Aaron W. Hsu
>Paul Bartlett wrote:
>> vi/clones
Indeed, some of us would take offense to calling Vim a clone of our
beloved Vi. :-)
Using Nvi, *not* Vim, happily,
Aaron W. Hsu
I used to use Joe and Jed, and both were actually quite pleasant.
I got used to the WordStar stuff that I enabled, and it wasn't half
bad. In fact, in my library, I found an old WordStar reference,
and found it quite fun to see how people thought about editors back
then. ;-)
Jed is quite capable, but I know less about Joe.
Malcolm Dew-Jones
: Paul Bartlett wrote:
: > vi/clones
: Do you keep saying that just to be offensive? Vim isn't just a clone of vi.
Do you have a better term than "clone" ?
Biologically, we recognize that a clone would not end up being the same as
the original, it could be "better" or "worse", and would always be
somewhat different even though based on the same underlying commands
(biologically the commands are DNA seqences, but the word "commands"
just seems to have such a nice doubley singlular meaning when describing
an editor like vi (and etc) in the same breath as mentioning DNA - well
anyway I just had to say it). So anyway, clone doesn't really sound like
such a bad term for the
vi-"not-really-clones-according-to-some-traditional-meaning" editors.
perhaps vi-etc ?
$0.10
Chetan
> Chetan <chetan...@xspam.sbcglobal.net> writes:
>
>>I am surprised to find that most of the posts here are about vi or
>>vim. Aren't there other editors (besides the ones that have their own
>>groups) that people use?
>
> As has already been mentioned, many other editors have their own lists
> or groups to which people post. However, I myself regularly switch
> between using Vi and NEdit. On Windows I use Boxer Text Editor, and
> on Mac I often use BBEdit.
>
> If you want to have a general discussion about text editors, I'd be
> happy to read it. :-)
I thought I already did :-)
It is interesting that you mention using different editors on
different systems. My personal preference has been to use the same
editor as far as possible. But I decided to see what else is out
there that may work. I don't use NEdit, but it looks like it is
available on all platforms you mentioned. Is there any advantage in
using different editors?
--
Chetan
Ben C
More of a descendent than a clone. You wouldn't call a chicken a clone
of T-rex although they share a lot of DNA.
Mark
> However, I myself regularly switch between using Vi and NEdit. On
> Windows I use Boxer Text Editor, and on Mac I often use BBEdit.
Ah, another "Jack of all trades, master of none".
Sorry, just don't understand people who flip between editors.
Jeff Schwab
> Jeff Schwab (je...@schwabcenter.com) wrote:
> : Paul Bartlett wrote:
> : > vi/clones
>
> : Do you keep saying that just to be offensive? Vim isn't just a clone of vi.
>
> Do you have a better term than "clone" ?
Derivative.
(snipped a bunch of bs)
Jeff Schwab
> Jeff Schwab <je...@schwabcenter.com> writes:
>
>> Laurianne Gardeux wrote:
>>> Le Fri, 03 Apr 2009 18:42:58 -0400, Jeff Schwab a écrit :
>>>
>>>> [...] A link to "joe", for example, would have been
>>>> helpful. [...]
>>> http://joe-editor.sourceforge.net/
>
>> Thanks. It did eventually occur to me to search for "joe editor." :) I
>> was not aware of it, but I gather it's an emacs-influenced take on
>> another editor I've never seen in the wild, MicroPro WordStar.
>
> I used to use Joe and Jed, and both were actually quite pleasant.
> I got used to the WordStar stuff that I enabled, and it wasn't half
> bad. In fact, in my library, I found an old WordStar reference,
> and found it quite fun to see how people thought about editors back
> then. ;-)
>
> Jed is quite capable, but I know less about Joe.
I recall liking WordPerfect for word processing, and was not happy about
the wysiwig-only MS Word approach. It does my heart good to see
markup-based formatting coming back into fashion. You're absolutely
right about zeitgeists changing, but maybe everything old is new again.
Aaron W. Hsu
>It is interesting that you mention using different editors on
>different systems. My personal preference has been to use the same
>editor as far as possible. But I decided to see what else is out
>there that may work. I don't use NEdit, but it looks like it is
>available on all platforms you mentioned. Is there any advantage
>in using different editors?
Well, I am quite fickle in my editor preferences regardless of
whether I stay on the same Operating System or not. In fact, I
used to switch back and forth on differing Linux Distributions every
week for about six months or longer when I was hacking Linux stuff.
I would switch editors almost as often, simply because my whims
changed. Now, my choices and the frequency of my switching are
smaller. I stick with OpenBSD as an Operating System, and since
most of the time I use that OS, you'll usually find me using either
Vi or NEdit.
I use Nvi because it's built into my OpenBSD base installation, and
it's very efficient. It's light, featureful, and doesn't get in
my way at all. Moreover, I don't have to track it separately from
my OS, because it comes with my OS.
But then the whim will hit me and I go into a Motif fetish thing
or something. I switch my Window manager to Mwm (from cwm) and
switch my mail client over, and just about any software that I can
away from the base programs in OpenBSD to Motif based programs.
This would include NEdit. I find that I can work quite nicely in
NEdit, and it's quite effective for me, just as much as Vi is. I
know how to customize it, and I have customized it to suite my needs
as a Scheme programmer. I have all these niceties that I install.
It is nice because it's a very well designed GUI that doesn't get
in the way, but still takes full advantage of the Graphical features
it can when they make sense. Is it any better than Vi? Neh. Does
it make me work faster or slower? Neh. It's just a whim and fancy.
Even more rarely, I'll go on an Emacs thing and start using that,
but those times are becoming much less common now.
Occassionally I have to port my work to Windows, so I have a Windows
machine that I pull out of storage every so often and hack on it.
Back when I was using Windows, Boxer Text Editor was my thing. It
was a great editor, and had a wonderful developer that supported
it. It still has that, and it's still great to work with. It has
all the features I could want, and it integrates nicely with the
feel of the Operating System, except for the slow speed and crashes,
of course.
I probably could have installed Vi and/or NEdit on the system and
used it, but Boxer integrates so nicely, that I find it pleasant
to use. Not to mention, I like to support a developer that does a
good job.
On Mac, I do have the occassional whim to run everything under X11
and then you'll find me using Vi and NEdit, but usually, I stick
with Mac-ish programs. BBEdit is the quintessential Mac editor,
and so it fits with my frame of mind when I work in a Mac environment.
I could as equally well use most of the tools I currently use on
the other OSes that I occassionally use, and I know plenty of people
who do this. However, for me, since I don't really find myself
having trouble switching from one to the other, it's largely a
fanciful joy ride from one editor to the other, without any real
loss in productivity.
Perhaps the only real advantage is being able to really feel
integrated with the whole system. Vi doesn't *feel* like a Mac
program, and so you can't really be completely immersed in the 'Mac'
experience unless you use Mac programs. :-)
Then again, I program in Scheme for all platforms, so...go figure.
Aaron W. Hsu
Yeah, there really isn't any rhyme or reason for it. It's purely
having fun with different programs that I consider well written.
I will say that while I regularly switch editors if I switch OSes,
the amount of time that I spend on Windows and Mac machines nowadays
continues to grow shorter and smaller compared to the amount of
time I spend in UNIX type environments, so I mostly use Vi and
NEdit now. I don't know if you could call me a master of either,
but I don't think I use either one in a naive way either.
I have written all sorts of Scheme supporting tools to make
NEdit work well, and I have taken advantage of most of its functionality
plenty of times. Likewise, I use lot's of Vi's tools and I have
adding Lisp mode back into Nvi on my list of things to do.
For me, it's just a thing that I do, for no particular reason, because
I don't think I really gain too much productivity one way or the
other, and because I get bored easily.
Paul Bartlett
No offense intended. Others have already responded in this thread. I
was/am only using a shorthand to refer to vi and editors which may be
*conceptually* derived from its *functionality* and therefore have a
more or less general superficial resemblance, not that one is derived
from another on the source code level (which obviously they are not).
Indeed, the only time I ever used vim I had a vi reference card as my
only guide.
--
Paul Bartlett
Eric Pozharski
>> On Thu, 2 Apr 2009, Chetan wrote:
>>
>>> I am surprised to find that most of the posts here are about vi or
>>> vim. Aren't there other editors (besides the ones that have their own
>>> groups) that people use?
>>
>> I glance at this ng and delete most of the posts unread, as I do not
>> use vi/clones. I use joe, and the last time I asked a joe question
>> here I got *zero* responses.
>
> I've never heard of the "joe" editor, and it doesn't show up in the
> first page (10 results) of a Google search for "joe".
That seems you should train google. 'joe's own editor' is #8 for me.
> Maybe you got *zero* responses because you're using an editor that
> doesn't have a very large user-base. (There's nothing wrong with
> that, but blaming the editor-interest community for not knowing about
> this particular tool is a bit of a stretch.)
Looking at http://qa.debian.org/popcon.php?package=joe I would say: "It
depends".
>> I think this ng ought to be renamed
>> comp.editors.vi+clones so the rest of us can safely just not subscribe
>> to it and know that we are not missing anything.
I think, if someone would post regularly kind of welcome-note it would
be more constructive.
> ...or maybe the non-vi-derived editor folks could actually contribute
> something of value. A link to "joe", for example, would have been
> helpful. I'd also be interested to know the dis/advantages relative to
> vim et al.
If IRC 'joe' isn't modal; then I'm uninterested.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
Florian Rehnisch
> I am surprised to find that most of the posts here are about vi or
> vim. Aren't there other editors (besides the ones that have their own
> groups) that people use?
Well, the first editor that I used was TxEd (IIRC) on an
Amiga 500 back in 92. Then someday GoldEd, again Amiga.
When I came to Unix, I first used NEdit, but had to try
this Vi thingy, HP-UX flavor. Then Bram released Vim/6.0
and from then on, I've mostly used Vim (yes, even now).
I looked very early at MicroEmacs, and eventually tested
Emacs from time to time, but didn't liked it. I
recently discovered how to have viper mode, emacs flavor
of vi, running all the time, so I can edit my posts in a
way I'm used to when I try gnus. But when I'm really
crazy, I use /bin/ed. ;-)
ZZ
--
flori
Komfortables Web2News-Gateway http://www.newsoffice.de/
Vim-Hilfe auf Deutsch http://www.florianrehnisch.de/vimhelp/
Mark
> For me, it's just a thing that I do, for no particular reason, because
> I don't think I really gain too much productivity one way or the other
But you're wrong Aaron. If you are a software developer than you really
can improve your productivity significantly by learning your editor
thoroughly.
As a professional developer I spend much/most of my day in my editor
(vim). It's my paintbrush with which I create beautiful worlds. I'm just
not going to blithely pick up and use any old brush.
I'm not exactly sure I understand the chain of creative or physiological
process that occurs when I write software but I do know, for me, that
vim is part of it.
Jeff Schwab
OK, so I'm a vim-geek, too, but your analogy seems to favor Aaron's
point of view. A true artist doesn't restrict himself to just one
brush: he uses the tool that is appropriate to the job.
Chetan
I find this interesting way to look at things. In the past, I have
tried many different editors. Most of the time I am looking for
things that I cannot currently do. But I don't want to spend a lot of
time learning how to make things efficient in the new environment with
the result that I am back to where I am comfortable. There have been
cases where the I had to work with remote systems which did not have
anything of my choice. In such cases, it turned out to be easier to
edit files locally with FTP (part of the editor or separately). With
remote version control and such tools, things are easier now.
--
Chetan
Paul Bartlett
> On Sat, 04 Apr 2009 17:30:31 -0500, Aaron W. Hsu wrote:
>> For me, it's just a thing that I do, for no particular reason, because
>> I don't think I really gain too much productivity one way or the other
>> ..
>
> But you're wrong Aaron. If you are a software developer than you really
> can improve your productivity significantly by learning your editor
> thoroughly.
> [trim]
This, certainly, is an important point. Some editors are lacking in
features that a so-called "power user" might need and use regularly,
but that there might be a significant learning curve to use effectively
and well. However, others' editing needs might be modest, and an
editor with fewer features might be adequate.
For instance, under Windows XP at home I still sometimes use an editor
that if I understand correctly was originally written for MSDOS Version
1! For simple tasks tasks it meets my needs and I know it well. For
tasks which are beyond its capabilities (such as the infrequent times
that regular expressions really are an elegant and efficient way of
doing things), I use something else (TextPad, in my case, for the Win
environment). When I am logged into my (netBSD) shell account over a
text-based SSH2 link, I use joe, which meets my needs.
Obviously and certainly, it all depends on what your needs are. It is
a Certified Good Thing that there are powerful, feature-rich editors for
those who need those features. It is also a Certified Good Thing that
there are simpler, less-feature-rich editors for those whose needs are
more modest and which have a gentler learning curve, and in any case,
learning your editor well, as Mark says, is vitally important, perhaps
more important than getting lost in a forest of features.
--
Paul Bartlett
void main()
I get bored sometimes and try to use another editor just to "unbore" me.
But I run back to vim/70 after every "incident", and be glad that I am
working with vim/70, not some other tools.
--
Wei
Remove xxx to email.
Aaron W. Hsu
>But when I'm really crazy, I use /bin/ed. ;-)
I actually used Ed for most of my note taking and essay writing throughout
my high school time. It really is a perfectly decent editor.
Carl
with several of
the comments above that knowing your editor well is a major plus.
Consider your
"needs" and what you might like to do, how extensible it should be,
and pick one.
Building on past knowledge is surely an advantage but looking at new
editors can
be enlightening. I found one, Manfield's KEdit, many tears back and
embraced it :)
It isn't free, has some quirks, and the company is dropping support.
It is quite nice,
has a neat extensible macro language, several sites that provide
sample macros,
and people who use it who are extremely helpful.
The Editors Group is interesting but doesn't provide the "gee, I'd
like to see only
code that begins to the left of this column" or "what data is unique
in these
columns." Maybe an Editors Concepts group is needed. But, to address
the
initial thread start, if you have a question on Joe or whatever, ASK!
I've posted
notifications here of KEdit's changes as well as questions and been
happily
surprised. YMMV!
Aaron W. Hsu
>On Sat, 04 Apr 2009 17:30:31 -0500, Aaron W. Hsu wrote:
>> For me, it's just a thing that I do, for no particular reason, because
>> I don't think I really gain too much productivity one way or the other
>> ..
>But you're wrong Aaron. If you are a software developer than you really
>can improve your productivity significantly by learning your editor
>thoroughly.
>As a professional developer I spend much/most of my day in my editor
>(vim). It's my paintbrush with which I create beautiful worlds. I'm just
>not going to blithely pick up and use any old brush.
True, you don't use some piece of junk just because. However, artists
can and do switch up their medium of choice. Sometimes I want to do a
charcoal, and other times, I wish to pain with oils. I can learn both,
and I can become very good in both.
That's not to say that I don't spend a significant time in one editor
over the other, and that I may know one much better than the other, but
why take away the fun of switch editors at times? Spend a little time
refreshing yourself in your spare time, and you're back up to the same
productivity. That is, assuming you can train your muscle memory to
work with both equally effeciently.
Yes, I do learn my tools pretty thoroughly, and I enjoy delving deeper
into their power when I use them, but that doesn't mean I'm going to
just drop all the other editors I play with either. I enjoy the switch,
and so I'll keep switching.
Mark
> Mark wrote:
>> But you're wrong Aaron. If you are a software developer than you
>> really can improve your productivity significantly by learning your
>> editor thoroughly.
>>
>> As a professional developer I spend much/most of my day in my editor
>> (vim). It's my paintbrush with which I create beautiful worlds. I'm
>> just not going to blithely pick up and use any old brush.
>>
>> I'm not exactly sure I understand the chain of creative or
>> physiological process that occurs when I write software but I do
>> know, for me, that vim is part of it.
>
> OK, so I'm a vim-geek, too, but your analogy seems to favor Aaron's
> point of view. A true artist doesn't restrict himself to just one
> brush: he uses the tool that is appropriate to the job.
You're probably right Jeff. Actually my last paragraph indicated my
intentions better. What I was getting at is that vim is actually part of
my creative chain, sort of like part of my hands, when I paint a scene.
Vim is infused into me. I think about code and structure and somehow it
appears nicely presented on my screen. I'm not sure where vim starts and
I end. I certainly know I'm not nearly as good at creating software when
vim is not around.
RS Wood
> Chetan <chetan...@xspam.sbcglobal.net> writes:
>
>>I am surprised to find that most of the posts here are about vi or
>>vim. Aren't there other editors (besides the ones that have their own
>>groups) that people use?
>
> on Mac I often use BBEdit.
>
> happy to read it. :-)
>
>
I think the reason most questions are about vim is because other editors
don't provide so many "hidden" tricks" or offer so much functionality.
I use vim and occasionally emacs, but in different contexts: I prefer
vim for config file editing but emacs for email and longer works. But
in GUI environments I mostly enjoy jedit, a java editor that works
equally well on every platform I use - that's handy. I carry my macros
and config files on a USB key and can instantly work the way I like to
on any machine I use. I also find it easier to customize than emacs,
whose lisp I've never really gotten the hang of.
But if I don't post any questions about jedit here it's because it's
been pretty easy to figure out and I haven't got any questions to ask.
Still, I think a comp.editors.vim group would be appropriate, since the
emacites have a separate group.
For the record, I, too, like switching around my editors from time to
time, but mostly because it's fun to learn new software. I've used jed,
and joe as well: they're fun for what they are. Joe is actually good on
usenet because it defaults to hard wrapping, something I want on usenet
but don't want on longer works. (yeah yeah yeah, vim and emacs can do
that too. I get it, I get it).
Cheers.
--
http://www.therandymon.com
Antony Scriven
wrote:
> Jeff Schwab <j...@schwabcenter.com> wrote:
> > Chetan wrote:
>
> > > I started reading this newsgroup thinking I will find
> > > discussion of editors in general, or text editors or
> > > programmer's editors. However, most of the questions
> > > seem to be related to help for using vi (all). No
> > > discussion of features or comparisons or such.
>
> > > If only vi users hang out here, it is unlikely others
> > > will hang on if they aren;t interested in vi alone.
>
> > That doesn't mean you should drop off this group, just
> > because it's not an all-in-one solution. Anyway,
> > there's no prohibition on discussing other editors
> > here. If you have specific questions about
> > (emacs|SlickEdit|Notepad++|.*), somebody (though
> > probably not me) will likely be able to answer them.
>
> ...but bear in mind that a vim-user will almost certainly
> join the thread, ignore the OP's actual question, and
> state that the solution is to use vim.
>
> (one of the hazards of reading comp.editors...)
Ha ha! I do like your bitter humour Thomas! Sadly your analysis
is true; but, happily, the solution is true also. (-; --Antony
Steve Kostecke
> I use Nvi because it's built into my OpenBSD base installation, and
> it's very efficient. It's light, featureful, and doesn't get in
> my way at all. Moreover, I don't have to track it separately from
> my OS, because it comes with my OS.
I don't have to "track Vim separately" on my Debian systems. That's what
a package management system is for.
--
Steve Kostecke <st...@kostecke.net>
"I am a citizen, not a consumer. I am a human being, not a revenue source."
Public Key at gopher://kostecke.net or `finger st...@kostecke.net`
Kaz Kylheku
> On 2009-04-04, Aaron W Hsu <arc...@sacrideo.us> wrote:
>
>> I use Nvi because it's built into my OpenBSD base installation, and
>> it's very efficient. It's light, featureful, and doesn't get in
>> my way at all. Moreover, I don't have to track it separately from
>> my OS, because it comes with my OS.
Also, I see that the OpenBSD CVS repository has src/usr.bin/vim.
Doh!
> I don't have to "track Vim separately" on my Debian systems. That's what
> a package management system is for.
The most widely version of nvi is still 1.79, which is at least ten years old.
This is what is packaged in various BSD distributions, and some Linux
distributions too.
The Wikipedia currently says that:
BSD projects continue to use version 1.79 due to licensing
differences between Berkeley Database 1.85 and the later versions
by Sleepycat Software. nvi is unusual because it uses a database
to store the text as it is being edited. Sven Verdoolaege's
changes after version 1.79 use locking features not available
in the 1.85 database.
Is this out of date? I'm looking at the README file in the OpenBSD CVS
repository under src/usr.bin/vi. The revision is eight years old, and says:
# $OpenBSD: README,v 1.10 2001/01/29 01:58:25 niklas Exp $
# @(#)README 8.149 (Berkeley) 7/14/97
This is version 1.79 (7/14/97) of nex/nvi, a reimplementation of the ex/vi
text editors originally distributed as part of the Fourth Berkeley
Software Distribution (4BSD), by the University of California, Berkeley.
People who advocate nvi based on its inclusion in their OpenBSD system are
actually talking about this old crap.
I evaluated nvi 1.79 back in 1999 or so as an alternative to Vim, which I had
been using since around 1994. I found that it didn't compare to the
/then/-current version of Vim. Even if my evaluation was biased then, Vim has
undergone a decade of development.
From the changelogs, not all that much has changed between between 1.79 and the
latest 1.81. So there is no compelling reason to upgrade, which explains why
nobody bothers resolving the issue.
Here is a kicker. According to the Wikipedia page, nvi was originally derived
from the first version of Kirkendall's Elvis. nvi is not related to any
ancient historic BSD software, except by look-and-feel; it is a
reimplementation of the vi interface, just like vim.
If you want Elvis, go get the real thing, not some stagnant offshoot of its
early version.
Vim predates Elvis by two years; the first public release of Elvis is dated
August 1990. Vim dates back to 1988, when it ran on Amiga machines.
So, there you have some facts you may find it helpful to recall when some rabid
BSD fanatic tells you that you are using some ``pale imitation'' of vi intended
for clueless Linux users, instead of the real BSD thing. :)
DMcCunney
I think which editor you use depends upon where you start and what you
grow accustomed to.
For instance, the first editor I used was back in the late 70's at a
bank. It was a product called ACEP, intended to replace TSO/SPF on
IBM mainframes running OS/VS1 and OS/MVS (now zOS). It was accessed
through 3270 terminals or compatibles. 3270s were "block-mode"
terminals, not character mode, and had a completely different idea of
full-screen editing than what most people think of. On a 3270, you
moved the cursor around the screen, made changes, pressed the Submit
key, and the entire *screen* was sent to the host. ACEP's developers
developed under Unix, and it had features inspired by Unix. When my
shop replaced ACEP with "real" TSO/SPF, I thought it a step backward.
This was back when the IBM PC was first becoming popular in corporate
environments, and Lotus 1,2,3 was forcing everyone to upgrade theier
256KB PCs to a full 640KB of RAM to accomodate huge Lotus
spreadsheets. So the second editor I learned was WordStar. Back
then, WordStar was probably the second editor you learned, because the
one you preferred might not be available on the machine you had to
use, but WordStar probably was.
The third editor I learned was vi, because I left the bank and found
myself working for a small Unix systems house. This was the early
80s, and Vim wasn't around -- vi was the original Bill Joy product,
running under AT&T System V. Vi was a rude shock, until I started to
grasp the design concepts, whereupon it made sense. (And I found a
set of macros that made the arrow keys work in insert mode, which
eased a lot of the pain...)
Vi and WordStar shared.a design concept: they were keyboard
independent. If you had a qwerty keyboard with a Control key, you
could use them. It made sense, because a lot of odd things got used as
terminals on early Unix systems, some of which didn't *have* arrow
keys or F-keys, and there was almost as much variation in the early CP/
M systems on which WordStar originated.
As I started using PCs more, back in the MS-DOS days, I kept some
WordStar fluency because many PC editors either used the WordStar
command set or could be told to. For that matter, I loaded a WordStar
emulation package in Gnu Emacs on *nix boxes to avoid retraining my
fingers, and wrote a WordStar emulation macro package for the
MicroEMACS editor I ran on the PC.
In the process, I got interested in editor design and implementation,
and collected them. I have a hundred or so here for various
platforms, and am aware of many more. (Like, someone actually wrote a
partial vi clone for the Commodore 64...)
Which I use depends on what I'm doing. My standard editor on the PC
under Windows XP is Don Ho's Notepad++, with a tabbed interface and
based on Neil Hodgson's Scintilla edit control, which provides code
folding and syntax highlighting for a large number of languages.
http://http://notepad-plus.sourceforge.net/uk/site.htm
On Solaris, I use vi. On some flavors of Linux, I use Vim, but I
might as well be using vi - I have no need for and have never used
most of the fancy features Vim implements.
There are a number of other things in the mix. For instance, I have
an old Fujitsu Lifebook running Puppy Linux. Puppy is intended for
lower end hardware (and thre are people reporting running it on P200s
with 64MB of RAM). The Puppy devs make a point of a small distribtion
(the ISO is about 100MB), and do various things to save space. For
instance, Albrecht Kliene's e3 editor is bundled and linked as vi for
console usage. e3 partially emulates vi, emacs, WordStar, Pico, and
Nedit. Which personality it assumes depends upon which name it was
called by. http://www.sourcefiles.org/Editors/Console/e3-2.7.0.tar.gz
- tarball with source and binaries for DOS, Windows, Linux, and *BSD
The standard GUI editor on Puppy is Geany, a cross-platform editor
based on Scintilla, with tabbed interface, code folding, and syntax
highlighting. http://www.geany.org/Main/HomePage
There are a few things I'm looking at in the background but don't use
regularly. One is IBM's open source Eclipse IDE. Eclipse is written
in Java, and will run on anything with a current Sun JVM. While
intended for Java development, it can be used for a large number of
other languages, and is extensible through plugins. Eclipse seems to
have largely killed off the commercial IDE market. MS Visual Studio
is still out there for the Windows only folks, and Embarcadero
Technologies (formerly Codegear, formerly Borland's compiler and tools
division) still offers things like C++ Builder and Delphi, but they
seem to be catering to an existing market which is too deeply embedded
to make switching easy. Everyone else just opts for the free, open
source product. :-) http://www.eclipse.org
Another interesting direction is ActiveState's Komodo Edit, which is
an open source component of their commercial Komodo IDE. Komodo is
built on the Mozilla code baee, using the Gecko rendering engine to
display the editor on the screen. Because it's based on Mozilla code,
it's cross platform, and it can be be customized with themes and
extensions. Komodo incorporates Scintilla, so code folding and syntax
highlighting are part of the package. http://www.activestate.com/products/komodo_edit/
There are over 1,000 different text editors out there for various
platforms, based on a variety of paradigms and intended uses. I don't
believe in a "one-size-fits-all" editor, and use what best suits what
I'm doing at the moment. I roll my eyes at emacs vs vi Holy Wars.
Folks interested in exploring a bit should visit http://TextEditors.org,
a wiki devoted to the topic. If you know of something not listed, or
have updates/corrections for stuff that is listed, please add them.
______
Dennis
Aaron W. Hsu
>On 2009-04-04, Aaron W Hsu <arc...@sacrideo.us> wrote:
>> I use Nvi because it's built into my OpenBSD base installation, and
>> it's very efficient. It's light, featureful, and doesn't get in
>> my way at all. Moreover, I don't have to track it separately from
>> my OS, because it comes with my OS.
>I don't have to "track Vim separately" on my Debian systems. That's what
>a package management system is for.
Heh, sure, I could install Vim with packages, but why do that when I have
a happily installed program in the base system? :-P No, I know, package
management systems are nice, but I do like to have as few programs
installed as is productive.
Aaron W. Hsu
>On 2009-04-18, Steve Kostecke <st...@kostecke.net> wrote:
>> On 2009-04-04, Aaron W Hsu <arc...@sacrideo.us> wrote:
>Also, I see that the OpenBSD CVS repository has src/usr.bin/vim.
>Doh!
Heh, not in my source tree it doesn't. Vim is definitely in the
ports though, and lots of people use it.
>People who advocate nvi based on its inclusion in their OpenBSD system are
>actually talking about this old crap.
Crap? Hah! Certainly not that featureful compared to something like
Vim, but does it have to be?
>I evaluated nvi 1.79 back in 1999 or so as an alternative to Vim, which I had
>been using since around 1994. I found that it didn't compare to the
>/then/-current version of Vim. Even if my evaluation was biased then, Vim has
>undergone a decade of development.
Vim has a lot more features, and has much more active development, if that
is what you want, then Vim is all well and good.
>Here is a kicker. According to the Wikipedia page, nvi was originally
>derived from the first version of Kirkendall's Elvis. nvi is not
>related to any ancient historic BSD software, except by look-and-feel;
>it is a reimplementation of the vi interface, just like vim.
But it does so with a little more accuracy than Vim. Not that Vim
doesn't work as a fine editor, but just because it's bigger, has
more features, and happens to have the ability to a compatibility
mode, doesn't mean that all of us care to use it.
>So, there you have some facts you may find it helpful to recall
>when some rabid BSD fanatic tells you that you are using some ``pale
>imitation'' of vi intended for clueless Linux users, instead of the
>real BSD thing. :)
*chuckle* Nice. Of course, I wouldn't call Vim some pale immitation
of Vi intended for clueless Linux users. (Wish I could.) It's one powerful
editor with lot's of features and a whole lot of capability.
Still, some people like myself *do* like to use nvi compared to the
stuff like Vim.
Jeff Schwab
> Eclipse is written
> in Java, and will run on anything with a current Sun JVM.
Not so. For example, when I used to do embedded development, I could
run vi on the actual system under test; however, when I used Eclipse, I
had to run it on a separate, development machine. Eclipse insists on a
windowing environment, plenty of RAM, and other expensive luxuries. To
make matters worse, the Terminal plugin to Eclipse was so buggy as to be
unusable; I ended up using minicom, cutting and pasting to communicate
with Eclipse.
Eclipse tries to "shelter" you from the underlying system, but often
just ends up getting in the way.
> While
> intended for Java development, it can be used for a large number of
> other languages, and is extensible through plugins.
That was the theory. However, IME, Eclipse-based commercial IDEs are
always meant to be self-contained. Vendor plugins do not play well with
each other. For example, when I used Wind River Workbench, I was
instructed to run it separately from my existing Eclipse installation.
Running two copies of Eclipse would bring my laptop to a stand-still, so
I had to do all my Wind River stuff, then exit, then start a different
Eclipse to do my other development. When I asked Wind River about
running Workbench as a plugin to an existing Eclipse installation, I got
non-answers of the form "it's probably possible, but you're on your own."
> I roll my eyes at emacs vs vi Holy Wars.
Back at ya. :) Seriously, there is an important distinction between the
philosophies of these editors. Most modern vi/emacs users' attitudes
re. the editors themselves are "use whatever makes you happy." The
philosophical differences are big-picture stuff, though, with
far-reaching implications.
The vi family stays fast and light-weight by relying on the underlying
platform to the greatest extent possible. It's meant to be one part of
a larger eco-system, to support extremely fast start-up and exit, and to
be extended using your choice of languages. Vim does have its own
customization language, but it also has direct bindings to other popular
scripting languages. (At the moment, I'm using a Vim installation with
an embedded Ruby interpreter.) The down-side is that serious
development requires you to know the particular tools available on the
platform you're using. Even going from one Unix to another can require
a little mental reconfiguration.
Emacs is the other direction: An all-in-one functionality-fest. The
default Gnome icon for Emacs used to be a cartoon image of a kitchen
sink. The recommended installation package for XEmacs newcomers is
actually called "the sumo tarball." To use the tool effectively, you
have to buy into it whole-heartedly, e.g. using its particular flavor of
a single programming language. The advantage is that you rarely have to
leave your editor; for example, when I was an XEmacs user, even my email
client was just another plugin (VM). The down-side is that every piece
of software you ever want to use has to be specifically written as a
plugin to the editor, or the paradigm breaks down. In practice, this is
just not feasible, because you're never going to get a majority of
developers to buy into a single editor and programming language. For
example, most web sites looked like crap in the built-in Emacs web
browser (I kid you not), W3.
Eclipse is in the Emacs philsophical family. Instead of eLisp, it uses
Java+SWT, but the attitude is the same: One heavy-weight editor to rule
them all. (In fact, by comparison, Emacs seems almost svelte.)
Eclipse also has an important short-coming relative to both vi and
emacs: Java has only mediocre support for run-time metaprogramming. RT
metaprogramming support may not be a critical distinction for
general-purpose programming, but within the context of a development
environment, it's vital. Vim has direct support for interactive
metaprogramming, and eLisp is a nearly ideal RT metaprogramming language.
> Folks interested in exploring a bit should visit http://TextEditors.org,
> a wiki devoted to the topic. If you know of something not listed, or
> have updates/corrections for stuff that is listed, please add them.
In the embedded community, SlickEdit is very popular.
Geoff Clare
> I evaluated nvi 1.79 back in 1999 or so as an alternative to Vim, which
> I had been using since around 1994. I found that it didn't compare to
> the /then/-current version of Vim. Even if my evaluation was biased
> then, Vim has undergone a decade of development.
Interesting. I also evaluated nvi and vim in 1999, and chose nvi.
I had been using "real" vi for 15 years and nvi behaved the way I
was used to, whereas vim had a number of annoying differences.
Also, all but one of my macros worked in nvi (and soon afterwards
they all worked, when the author Keith Bostic fixed the problem I
reported). In vim a lot of my macros didn't work.
Presumably vim's compatibility has improved since then.
> Here is a kicker. According to the Wikipedia page, nvi was originally
> derived from the first version of Kirkendall's Elvis. nvi is not
> related to any ancient historic BSD software, except by look-and-feel;
> it is a reimplementation of the vi interface, just like vim.
It's true that nvi is a reimplementation, but Keith Bostic went to
great pains to ensure it behaved exactly the same as "real" vi. At the
same time, he worked on corrections to the POSIX description of vi to
make sure it matched "real" vi and nvi. (There were so many corrections
that the POSIX.2b amendment had complete descriptions of ex and vi
instead of a list of changes as for most other utilities.)
--
Geoff Clare <net...@gclare.org.uk>
DMcCunney
DMcCunney wrote:
>> Eclipse is written in Java, and will run on anything with a current Sun JVM.
>Not so. For example, when I used to do embedded development, I could
>run vi on the actual system under test; however, when I used Eclipse, I
>had to run it on a separate, development machine. Eclipse insists on a
>windowing environment, plenty of RAM, and other expensive luxuries. To
>make matters worse, the Terminal plugin to Eclipse was so buggy as to be
>unusable; I ended up using minicom, cutting and pasting to communicate
>with Eclipse.
Like I said, anything with a current JVM. I wouldn't expect the
target platform for embedded development to be able to run Eclipse.
But then, If I'm using GCC to cross-compile for a target architectire,
I don't expect GCC and my development environment to run on it. If it
could, I probably wouldn't *have* to cross-compile. I could build
"native".
(An example is the Palm OS SDK, which offers Eclipse and a custom
Cygwin distribution, with GCC built to cross-compile to MC68K code.
You develop on the PC side, then port your code to the Palm device to
test in the simulator.)
> Eclipse tries to "shelter" you from the underlying system, but often
> just ends up getting in the way.
Well, *Java* tries to shelter you from the underslying system. Java
code compiles for the system implemented by the Java Virtual Machine,
and the JVM tries to abstract the hardware differences. (The Chief
Software Architect at a former employer doing lots of Java development
was eloquent about the funny little differences between Java on
different platforms and how Java code was not necessarily 100%
portable.)
>> While intended for Java development, it can be used for a large number of
>> other languages, and is extensible through plugins.
>That was the theory. However, IME, Eclipse-based commercial IDEs are
>always meant to be self-contained. Vendor plugins do not play well with
>each other. For example, when I used Wind River Workbench, I was
>instructed to run it separately from my existing Eclipse installation.
>Running two copies of Eclipse would bring my laptop to a stand-still, so
>I had to do all my Wind River stuff, then exit, then start a different
>Eclipse to do my other development. When I asked Wind River about
>running Workbench as a plugin to an existing Eclipse installation, I got
>non-answers of the form "it's probably possible, but you're on your own."
I'm aware of Wind River (and know a couple of folks who work there)
but haven't seen their Workbench. How specialized is it? Apparently,
you couldn't just do all of your development in Workbench.
>> I roll my eyes at emacs vs vi Holy Wars.
>Back at ya. :)
Hey, *everybody* knows WordStar is the One True Command set... :)
> Seriously, there is an important distinction between the
>philosophies of these editors. Most modern vi/emacs users' attitudes
>re. the editors themselves are "use whatever makes you happy." The
>philosophical differences are big-picture stuff, though, with
>far-reaching implications.
Agreed wholeheartedly.
>The vi family stays fast and light-weight by relying on the underlying
>platform to the greatest extent possible. It's meant to be one part of
>a larger eco-system, to support extremely fast start-up and exit, and to
>be extended using your choice of languages. Vim does have its own
>customization language, but it also has direct bindings to other popular
>scripting languages. (At the moment, I'm using a Vim installation with
>an embedded Ruby interpreter.) The down-side is that serious
>development requires you to know the particular tools available on the
>platform you're using. Even going from one Unix to another can require
>a little mental reconfiguration.
Sure. I've logged time as an Admin on Unix System V R2, 3, and 4,
Solaris 7, 8, and 9, and several flavors of Linux. They look largely
alike to a logged in user, but differ in precisely the places I play
in.
>Emacs is the other direction: An all-in-one functionality-fest. The
>default Gnome icon for Emacs used to be a cartoon image of a kitchen
>sink. The recommended installation package for XEmacs newcomers is
>actually called "the sumo tarball." To use the tool effectively, you
>have to buy into it whole-heartedly, e.g. using its particular flavor of
>a single programming language.
Yep. Emacs can be customized and extended in pretty much any way you
like with Emacs. The downside is you laregy *have* to customize it to
be relly productive, and there's a learning curve to get to the point
where you can.
> The advantage is that you rarely have to eave your editor; for example,
> when I was an XEmacs user, even my email client was just another plugin
> (VM).
A former contact of mine said "Why would you ever leave it?" He
invoked Emacs on login, and did everything from within it. Emacs
became his shell, mail/news client, and interface to compilers and
debuggers as well as his editor. Of course, this was back before X
and GUIs were prevalent, and you mostly did everything from the
command line.
> The down-side is that every piece of software you ever want to use has to
> be specifically written as a plugin to the editor, or the paradigm breaks
> down. In practice, this is just not feasible, because you're never going
> to get a majority of developers to buy into a single editor and programming
> language.
If you employ them, you can say "Thou shalt develop in Mobyfoo, using
the Foobaz IDE!", and they do so or seek other employment...
> For example, most web sites looked like crap in the built-in Emacs web
> browser (I kid you not), W3.
I'll take your word for it. :-P I collect browsers, and have looked at
most of them, but for day to day use I prefer Firefox.
> Eclipse is in the Emacs philsophical family. Instead of eLisp, it uses
> Java+SWT, but the attitude is the same: One heavy-weight editor to rule
> them all. (In fact, by comparison, Emacs seems almost svelte.)
Because Eclipse is intended as a full IDE. Emacs *can* be one, but I
don't think of that as the intent of the product.
> Eclipse also has an important short-coming relative to both vi and
> emacs: Java has only mediocre support for run-time metaprogramming.
> RT metaprogramming support may not be a critical distinction for
> general-purpose programming, but within the context of a development
> environment, it's vital. Vim has direct support for interactive
> metaprogramming, and eLisp is a nearly ideal RT metaprogramming language.
I have Vim, and use it on Linux. But as mentioned, I learned vi using
the original Bill Joy written product. For what I do, Vim might as
well *be* vi, as I seldom use most of the fancy extensions it offers.
I don't think most folks back in the day ever did more than scratch
the surface of what original vi could do, let alone the stuff offered
by something like Vim.
A design blog I read had a comment about a student feeling he was a
failure because he didn't know all about Photoshop and couldn't get it
to do what he wanted. His professor said "*Nobody* knows *all* about
Photoshop! It's too big and complex. Designers learn the parts that
do what they require." I think that's true for software tools in
general.
On another line, Rex Conn, developer of the popular 4DOS/4OS2/4NY/TCC
replacement command processors commented that "80% of the users of my
software use 20% of the features. But they all use a *different*
20%!"
>> Folks interested in exploring a bit should visit http://TextEditors.org,
>> a wiki devoted to the topic. If you know of something not listed, or
>> have updates/corrections for stuff that is listed, please add them.
> In the embedded community, SlickEdit is very popular.
I'm not surprised. It seems to be almost "last man standing" of the
commercial programmer's editor offerings, and all I know about it
makes it very good indeed.
______
Dennis
Jeff Schwab
> On Apr 19, 12:02 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> DMcCunney wrote:
>>> Eclipse is written in Java, and will run on anything with a current Sun JVM.
>
>> Not so. For example, when I used to do embedded development, I could
>> run vi on the actual system under test; however, when I used Eclipse, I
>> had to run it on a separate, development machine. Eclipse insists on a
>> windowing environment, plenty of RAM, and other expensive luxuries. To
>> make matters worse, the Terminal plugin to Eclipse was so buggy as to be
>> unusable; I ended up using minicom, cutting and pasting to communicate
>> with Eclipse.
>
> Like I said, anything with a current JVM. I wouldn't expect the
> target platform for embedded development to be able to run Eclipse.
The embedded platform, like many embedded platforms, has a current JVM.
That is not sufficient to let it run Eclipse. Eclipse has
requirements above and beyond the JVM.
> But then, If I'm using GCC to cross-compile for a target architectire,
> I don't expect GCC and my development environment to run on it. If it
> could, I probably wouldn't *have* to cross-compile. I could build
> "native".
It's not just a question of building (although one certainly can build
natively on many embedded systems), but of editing configuration files,
viewing logs, etc. I don't want to use totally different applications
for editing different kinds of files. I want one editor that runs
everywhere. Eclipse was designed to scale up, but not to scale down.
Vim (and to some extent, even Emacs) can scale either way.
>> Eclipse tries to "shelter" you from the underlying system, but often
>> just ends up getting in the way.
>
> Well, *Java* tries to shelter you from the underslying system.
Yep. To some extent, Lisp does, too. Java is a good fit for the
Emacs/Eclipse philosophy.
>>> While intended for Java development, it can be used for a large number of
>>> other languages, and is extensible through plugins.
>
>> That was the theory. However, IME, Eclipse-based commercial IDEs are
>> always meant to be self-contained. Vendor plugins do not play well with
>> each other. For example, when I used Wind River Workbench, I was
>> instructed to run it separately from my existing Eclipse installation.
>> Running two copies of Eclipse would bring my laptop to a stand-still, so
>> I had to do all my Wind River stuff, then exit, then start a different
>> Eclipse to do my other development. When I asked Wind River about
>> running Workbench as a plugin to an existing Eclipse installation, I got
>> non-answers of the form "it's probably possible, but you're on your own."
>
> I'm aware of Wind River (and know a couple of folks who work there)
> but haven't seen their Workbench. How specialized is it?
It's Eclipse plus a bunch of plugins to ease embedded Linux and VxWorks
development. It's meant to replace Tornado. I think a lot of the code
is Open Source, originally developed by Monta Vista.
> Apparently,
> you couldn't just do all of your development in Workbench.
For every Eclipse-based IDE I use that can't plugin into an existing
Eclipse, I need a separate Eclipse installation. (It's now been about
three years since I used Eclipse, so maybe the situation has improved.)
> A former contact of mine said "Why would you ever leave it?" He
> invoked Emacs on login, and did everything from within it.
I knew an IT guy like that. If you asked him for help with something,
the first thing he'd ask is: You left Emacs, didn't you?
>> The down-side is that every piece of software you ever want to use has to
>> be specifically written as a plugin to the editor, or the paradigm breaks
>> down. In practice, this is just not feasible, because you're never going
>> to get a majority of developers to buy into a single editor and programming
>> language.
>
> If you employ them, you can say "Thou shalt develop in Mobyfoo, using
> the Foobaz IDE!", and they do so or seek other employment...
...and accept the enormous productivity hit that comes with making
people switch editors. And get all your tool vendors to provide plugins
for this particular IDE. And instantly disqualify a large field of
potential hires, enabling the hires who are willing to deal with editor
X to jack up their price on you.
>> For example, most web sites looked like crap in the built-in Emacs web
>> browser (I kid you not), W3.
>
> I'll take your word for it. :-P I collect browsers, and have looked at
> most of them, but for day to day use I prefer Firefox.
The problem I have now is that I need to see how things look in IE, but
don't have a Windows machine on which to run it. I'm told even VMware
isn't really sufficient for seeing how IE behaves in the wild. If you
can offer any guidance on this, oh collector of browsers, I'd appreciate
it. :)
>> Eclipse is in the Emacs philsophical family. Instead of eLisp, it uses
>> Java+SWT, but the attitude is the same: One heavy-weight editor to rule
>> them all. (In fact, by comparison, Emacs seems almost svelte.)
>
> Because Eclipse is intended as a full IDE. Emacs *can* be one, but I
> don't think of that as the intent of the product.
The name IDE is misleading in this case. It's not just integrating
existing tools, but requiring heavy-weight, custom plugins. Vim on
Linux is a more "integrated" development environment than Eclipse on,
um, whatever, IMO. (Unless, of course, what you develop are Eclipse
plugins.)
> I have Vim, and use it on Linux. But as mentioned, I learned vi using
> the original Bill Joy written product. For what I do, Vim might as
> well *be* vi, as I seldom use most of the fancy extensions it offers.
> I don't think most folks back in the day ever did more than scratch
> the surface of what original vi could do, let alone the stuff offered
> by something like Vim.
Fair enough. If you were going to use Vim instead of Eclipse, you'd
certainly find it worth your while to learn more of the functionality.
There's a very smooth transition from the vi subset. I guess my point
is that I don't see any compelling advantage of Eclipse over Vim, except
that the very basics of editing may be easier to learn in Eclipse. If
you're already comfortable with vi, I don't see any advantage to Eclipse
at all, unless you happen to be developing a particular kind of Java
application. By contrast, there are a lot of disadvantages to using
huge, one-size-fits-all IDEs, rather than small, customizable tools that
are meant to fit into (rather than abstract away) many different
environments.
FWIW, I also came from vi (on AIX), and mostly just used the basic
features. The one thing I missed when I came to vim was the use of u as
a sort of toggle; because vim supports multi-level undo, hitting u twice
undoes two actions, whereas in vi, the second u undid the first undo,
enabling you to quickly compare how a document looked with and without a
particular change by toggling it with the u key. (The vim-ese for this
is u ^r, but that takes some getting used to.)
> A design blog I read had a comment about a student feeling he was a
> failure because he didn't know all about Photoshop and couldn't get it
> to do what he wanted. His professor said "*Nobody* knows *all* about
> Photoshop! It's too big and complex. Designers learn the parts that
> do what they require." I think that's true for software tools in
> general.
100% agreed. Most of my development is in C++, and people often
criticize it with a similar question: "How do they expect me to learn
all this? It's too big and complex!" Of course, the answer is that no
individual is ever really expected to know the whole thing. The idea
is for functionality to be available if and when you need it.
> On another line, Rex Conn, developer of the popular 4DOS/4OS2/4NY/TCC
> replacement command processors commented that "80% of the users of my
> software use 20% of the features. But they all use a *different*
> 20%!"
I read the same stats in a Joel Spolsky blog. Didn't realize he was
quoting.
>> In the embedded community, SlickEdit is very popular.
>
> I'm not surprised. It seems to be almost "last man standing" of the
> commercial programmer's editor offerings, and all I know about it
> makes it very good indeed.
I haven't used it, but people do seem to love it. A lot of job postings
now seem to require Visual Studio, though, so I don't see it dying any
time soon, either.
Aaron W. Hsu
>DMcCunney wrote:
>I want one editor that runs everywhere.
You should be careful for what you desire, because of the editors
out there, the only one that I know of that truly runs just about
everywhere -- even then there are places it won't run -- is ed.
Not that ed(1) is a bad editor. It really is a good editor, but
most people don't like to use it for their day to day editing.
>Eclipse was designed to scale up, but not to scale down. Vim (and
>to some extent, even Emacs) can scale either way.
Vim will largely scale down to what you need, but there are some
places where it will not scale down. That's not necessarily a bad
thing. Wanting an editor to go everywhere with you is nice, but
there are some places that you can't go with any editor you choose,
vi and ed included.
>> Because Eclipse is intended as a full IDE. Emacs *can* be one, but I
>> don't think of that as the intent of the product.
>The name IDE is misleading in this case. It's not just integrating
>existing tools, but requiring heavy-weight, custom plugins. Vim on
>Linux is a more "integrated" development environment than Eclipse on,
>um, whatever, IMO. (Unless, of course, what you develop are Eclipse
>plugins.)
The whole concept of integration needs qualification. IDEs are generally
tools which graphically connect multiple functionality into one system.
On the other hand, the UNIX shell is a pretty integrated development
environment. Good ol' vi has a remarkably large set of features that
enable it to work in a pretty integrated manner with lot's of other
programs through shell and other commands, which would make it a very
integrated development environment.
Likewise, Emacs is the same thing. The UNIX shell was designed to
integrate programs, so in some sense, it has the same goals as Eclipse,
but nonetheless, all of these solutions differ widely. I think the
term IDE fails to capture the main intent of most of these programs.
Eclipse really aims to be a Point and Click interface encapsulating
a large set of functionality into a single frame of reference
centralized around the construction of programs.
>FWIW, I also came from vi (on AIX), and mostly just used the basic
>features. The one thing I missed when I came to vim was the use of u as
>a sort of toggle; because vim supports multi-level undo, hitting u twice
>undoes two actions, whereas in vi, the second u undid the first undo,
>enabling you to quickly compare how a document looked with and without a
>particular change by toggling it with the u key. (The vim-ese for this
>is u ^r, but that takes some getting used to.)
Actually, most of the people with whom I talk that differ in their
choice of Vi all complain of the little nuanced differences in Vim
compared to their editor. Many of these relate to the way Undo is
handled. This seems to be enough to cause them to stick with the
editor they are used to rather than spring for Vim's more "extensive"
functionality.
Jeff Schwab
> Jeff Schwab <je...@schwabcenter.com> writes:
>> DMcCunney wrote:
>
>> I want one editor that runs everywhere.
>
> You should be careful for what you desire
I should have said "one family of editors with a large common subset."
For example, I'm considering vim and calvin to be opposite ends of the
functionality spectrum, but in the same editor family.
>> Eclipse was designed to scale up, but not to scale down. Vim (and
>> to some extent, even Emacs) can scale either way.
>
> Vim will largely scale down to what you need, but there are some
> places where it will not scale down. That's not necessarily a bad
> thing. Wanting an editor to go everywhere with you is nice, but
> there are some places that you can't go with any editor you choose,
> vi and ed included.
Huh? What platform, that supports any text editor at all, does not
support some vi derivative?
> Actually, most of the people with whom I talk that differ in their
> choice of Vi all complain of the little nuanced differences in Vim
> compared to their editor. Many of these relate to the way Undo is
> handled. This seems to be enough to cause them to stick with the
> editor they are used to rather than spring for Vim's more "extensive"
> functionality.
That seems very odd. I'm not aware of such extensive differences.
DMcCunney
>
> Building on past knowledge is surely an advantage but looking at new
> editors can be enlightening. I found one, Manfield's KEdit, many tears
> back and embraced it :)
> It isn't free, has some quirks, and the company is dropping support.
Mansfield has announced support will be continued beyond the original
drop date:
"December 4, 2008
KEDIT Support Dates Extended
In the article below, we said that we planned to continue selling
KEDIT for Windows through this web site until at least the end of
2008, and to continue e-mail support until at least September 2009. We
have decided to extend these dates, and we now plan to continue
selling KEDIT for Windows through the web site until at least the end
of 2009, and to provide e-mail support for it until at least September
2010.
KEDIT for Windows 1.6, released in December 2007, is still the current
version of the program."
> It is quite nice,
> has a neat extensible macro language, several sites that provide
> sample macros, and people who use it who are extremely helpful.
It's effectively a Windows clone with extensions of the IBM mainframe
Xedit editor.
Mark Hessling's The Hessling Editor (http://hessling-
editor.sourceforge.net/index.html), Blair Thompson's X2 (http://
www.tangbu.com/x2main.shtml), and Mizumaki-machi's Hybrib Editor XE
(http://www.geocities.jp/sakachin2/index.htm) are similar (and open
source.)
Dr. Nikolai Bezroukov classifies them as "Eastern Orthodox Editors" on
his Softpanorama page at http://www.softpanorama.org/Articles/orthodox_editors.shtml,
which I think is apt.
Eastern Orthodox editors are characterized by a command line, code
folding, and a macro language, with Xedit as the progenitor.
Western Orthodox editors are characterized by support for regular
expressions and piping through external filters, with vi as the
archtypical example.
______
Dennis
DMcCunney
> Aaron W. Hsu wrote:
>> Jeff Schwab <je...@schwabcenter.com> writes:
>>> Eclipse was designed to scale up, but not to scale down. Vim (and
>>> to some extent, even Emacs) can scale either way.
>>
>> Vim will largely scale down to what you need, but there are some
>> places where it will not scale down. That's not necessarily a bad
>> thing. Wanting an editor to go everywhere with you is nice, but
>> there are some places that you can't go with any editor you choose,
>> vi and ed included.
>
> Huh? What platform, that supports any text editor at all, does not
> support some vi derivative?
Things that aren't Intel based PCs.
IBM mainframes under DOS/VSE, MVS, VM/CMS, or zOS, where the standard
editor is ICCF (DOS/VSE) TSO/ISPF (MVS, zOS) or Xedit (VM/CMS), likewise
the IBM AS/400, where the default editor is SEU. Third-party products
also exist, but none bear any relation to vi. (And can't, since
terminals in that environment re block mode, not character mode.)
Unisys big iron, including the former Sperry and Burroughs boxes.
Sperry had the @ED editor, and the Burroughs systems use CannE. Unisys
machines are still out there.
Wang VS systems, whose top-end editor is Adept, based on Emacs. Wang is
gone, but Wang VS got ported to Intel, and you can run it on blade servers.
Honeywell systems running GCOS. Honeywell is out of the computer
business here, but Groupe Bull bought that side of it and the stuff is
still in use in Europe.
Hewlett Packard mini-computers, like the HP-3000, running EDIT/3000 or
Qedit.
Palm OS, where the most powerful editor I'm aware of is Paul Nevai's
pEdit, which includes all the editing features you might expect *and* a
script language, but bears no resemblance to vi. (And pEdit is intended
for Memopad records, which aren't quite text files, but can be exported
to them.)
I was about to include the Coomodore 64, but someone wrote a partial vi
clone for it.
I don't believe a vi variant existed for CP/M systems, either, though
there was a port of Emacs.
There are more, but those are off the top of my head. Vi is nowhere
near ubiquitous.
______
Dennis
Geoff Clare
>> Huh? What platform, that supports any text editor at all, does not
>> support some vi derivative?
>
> Things that aren't Intel based PCs.
>
> IBM mainframes under DOS/VSE, MVS, VM/CMS, or zOS, where the standard
> editor is ICCF (DOS/VSE) TSO/ISPF (MVS, zOS) or Xedit (VM/CMS),
z/OS is a certified UNIX95 conforming system, and the CSQ at
http://www.opengroup.org/csq/view.mhtml?RID=ibm%2FCV1%2F6
indicates that it supports the _POSIX2_UPE and _POSIX2_CHAR_TERM
options, which means it must have vi.
--
Geoff Clare <net...@gclare.org.uk>
Aaron W. Hsu
>Huh? What platform, that supports any text editor at all, does not
>support some vi derivative?
There are some limited systems on which one can program which only
have line editors much like ed. Most of them are not what you would
call general purpose computers, but they do exist. Some embedded
systems, and I think some firewalls by default only have such things,
if any at all.
>> Actually, most of the people with whom I talk that differ in their
>> choice of Vi all complain of the little nuanced differences in Vim
>> compared to their editor. Many of these relate to the way Undo is
>> handled. This seems to be enough to cause them to stick with the
>> editor they are used to rather than spring for Vim's more "extensive"
>> functionality.
>That seems very odd. I'm not aware of such extensive differences.
Well, undo definitely differs in the Vi-type editors. Additionally,
some people have a load of macros that don't run by default on Vim,
because they are used by Vim's defaults. On one system I use, even
setting compatible mode and disabling syntax for a given file still
results in some sort of strange non-default (for nvi) behaviors
from the Vim installation. Namely, whitespace highlighting isn't
disabled when compatible mode is set. So, compatible mode doesn't
necessarily make things 100% compatible, though it comes closer.
Another one of note is that sometimes Vim tries to be too smart by
default, and only lots of tweaking will get Vim to behave like
another Vi, in which case, why not just run the other Vi? One thing
that creeps up is the treatment of word and sentence navigation in
different languages. In Scheme for instance, some Vi-type editors
break words on the -'s that are often inside identifiers, but in
Vim, by default, it recognizes that they are one identifier and
meshes them into one word. If you have spent your whole career in
one mode, then changing over to Vim with this kind of subtle
difference is going to really smart when it comes to quickly
navigating through all that code.
Jerry Peters
mode, not character mode. There's even a note to that effect in the
USS documentation for vi.
Jerry
DMcCunney
Well, I sit partially connected.
I'd forgotten that IBM made zOS UNIX conforming. Anything that passed
Spec 1170 could call itself UNIX, so it was theoretically possible for
an IBM mainframe OS to become so. I recall being deeply amused when I
heard that IBM had actually *done* it.
IBM also had their own AIX implementation for the s390 architecture, and
there's an s390 Linux version as well. There's a report from some time
back about a systems programmer with an unused partition on a DOS/VSE
box, who decided to play with the s390 Linux port, and spawned 44,100
executing Linux images before the system ran out of resources. :-)
But as Jerry Peters noted, vi won't work on block mode terminals like
the 3270.
______
Dennis
(Who hasn't worked on a mainframe since well before zOS was released)
DMcCunney
> DMcCunney wrote:
>> On Apr 19, 12:02 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>> DMcCunney wrote:
>>
>> Like I said, anything with a current JVM. I wouldn't expect the
>> target platform for embedded development to be able to run Eclipse.
>
> The embedded platform, like many embedded platforms, has a current JVM.
> That is not sufficient to let it run Eclipse. Eclipse has requirements
> above and beyond the JVM.
I should have been more precise. I was referring to a current Sun JVM
aimed at desktops/servers. There are JVMs and JVMs, and not all are
created equal. I have an IBM JVM on my Palm OS PDA, and it's adequate
for the intended purposes, (which is mostly running the Java based Opera
Mini browser) but I'd hardly expect it to support Eclipse, even if the
rest of the hardware was up to it. (There would also be the challenge
of getting Eclipse to do anything sensible on a 320x480 display...)
>> But then, If I'm using GCC to cross-compile for a target architecture,
>> I don't expect GCC and my development environment to run on it. If it
>> could, I probably wouldn't *have* to cross-compile. I could build
>> "native".
>
> It's not just a question of building (although one certainly can build
> natively on many embedded systems), but of editing configuration files,
> viewing logs, etc. I don't want to use totally different applications
> for editing different kinds of files. I want one editor that runs
> everywhere. Eclipse was designed to scale up, but not to scale down.
> Vim (and to some extent, even Emacs) can scale either way.
I largely concur, save that I *don't* necessarily expect (or even want)
to use the same editor across the board. I've learned an assortment of
different editors over the years, and don't have a large problem
switching between them. On Windows, for example, my default text editor
is Don Ho's Notepad++, based on Neil Hodgson's Scintilla edit control.
NP++ offers a tabbed interface, syntax highlighting a and code folding
for a large number of languages (courtesy of Scintilla), and a variety
of functions to diddle text. It lacks a macro language, but that's not
a problem for what I do with it.)
The GUI editor on a flavor of Linux I'm playing with is Geany, also
based on Scintilla. Again, no macro language, but adequate for what I
do with it. There are several editor variants based on Scintilla,
including Neil Hodgson's SciTE (developed originally as a demo for
Scintilla) that use Lua as a script language.
>>> Eclipse tries to "shelter" you from the underlying system, but often
>>> just ends up getting in the way.
>>
>> Well, *Java* tries to shelter you from the underlying system.
>
> Yep. To some extent, Lisp does, too. Java is a good fit for the
> Emacs/Eclipse philosophy.
Or you could say that Eclipse is a good fit for the Java philosophy. :-)
As far as I can tell, if you develop in Java, you probably use Eclipse.
If you develop in another language, you may well use Eclipse, unless
you develop only for Windows using an MS language, in which case you use
Visual Studio.
But there are an awful lot of things calling themselves IDEs out there,
and all seem to have some sort of following.
>> Apparently, you couldn't just do all of your development in Workbench.
>
> For every Eclipse-based IDE I use that can't plugin into an existing
> Eclipse, I need a separate Eclipse installation. (It's now been about
> three years since I used Eclipse, so maybe the situation has improved.)
I wouldn't know. I've been fiddling with Eclipse more as something it
will be useful to know than as something I actually use (or need to) on
a daily basis.
>> A former contact of mine said "Why would you ever leave it?" He
>> invoked Emacs on login, and did everything from within it.
>
> I knew an IT guy like that. If you asked him for help with something,
> the first thing he'd ask is: You left Emacs, didn't you?
<grin>
>> If you employ them, you can say "Thou shalt develop in Mobyfoo, using
>> the Foobaz IDE!", and they do so or seek other employment...
>
> ...and accept the enormous productivity hit that comes with making
> people switch editors. And get all your tool vendors to provide plugins
> for this particular IDE. And instantly disqualify a large field of
> potential hires, enabling the hires who are willing to deal with editor
> X to jack up their price on you.
In a better economy, perhaps. I think the salad days when developers
could afford to be picky about stuff like that are largely over.
They pretty much have to all use the same language on a project, unless
you are doing something really different, and it's not too outrageous to
require everyone to use the same development environment, simply to
reduce potential confusion. It helps if the development framework will
let you plug in your preferred editor, but you may not be so lucky.
>>> For example, most web sites looked like crap in the built-in Emacs web
>>> browser (I kid you not), W3.
>>
>> I'll take your word for it. :-P I collect browsers, and have looked at
>> most of them, but for day to day use I prefer Firefox.
>
> The problem I have now is that I need to see how things look in IE, but
> don't have a Windows machine on which to run it. I'm told even VMware
> isn't really sufficient for seeing how IE behaves in the wild. If you
> can offer any guidance on this, oh collector of browsers, I'd appreciate
> it. :)
I've worked a bit with VMWare, but haven't tried to do that. No, I'm
afraid I can't help you -- you want a browser for environments other
than Windows that is bug-compatible with IE, and I'm not aware of one. :)
>>> Eclipse is in the Emacs philsophical family. Instead of eLisp, it uses
>>> Java+SWT, but the attitude is the same: One heavy-weight editor to rule
>>> them all. (In fact, by comparison, Emacs seems almost svelte.)
>>
>> Because Eclipse is intended as a full IDE. Emacs *can* be one, but I
>> don't think of that as the intent of the product.
>
> The name IDE is misleading in this case. It's not just integrating
> existing tools, but requiring heavy-weight, custom plugins. Vim on
> Linux is a more "integrated" development environment than Eclipse on,
> um, whatever, IMO. (Unless, of course, what you develop are Eclipse
> plugins.)
It depends upon what you think of as integration. The *nix model of
"one tool for one job", and using piping, redirection, and scripts to
tie things together makes a lot possible, but you probably have to do
some fiddling to get it set up as desired. (You can glue the parts
together any way you want, but you have to supply the glue.)
>> I have Vim, and use it on Linux. But as mentioned, I learned vi using
>> the original Bill Joy written product. For what I do, Vim might as
>> well *be* vi, as I seldom use most of the fancy extensions it offers.
>> I don't think most folks back in the day ever did more than scratch
>> the surface of what original vi could do, let alone the stuff offered
>> by something like Vim.
>
> Fair enough. If you were going to use Vim instead of Eclipse, you'd
> certainly find it worth your while to learn more of the functionality.
I don't really *use* Eclipse, save to play and learn. And I'm not a
developer, I'm a SysAdmin. Most of what I do in an editor is write
scripts and diddle config files. So most of the advanced features Vim
offers are things I simply won't need to use.
> There's a very smooth transition from the vi subset. I guess my point
> is that I don't see any compelling advantage of Eclipse over Vim, except
> that the very basics of editing may be easier to learn in Eclipse. If
> you're already comfortable with vi, I don't see any advantage to Eclipse
> at all, unless you happen to be developing a particular kind of Java
> application. By contrast, there are a lot of disadvantages to using
> huge, one-size-fits-all IDEs, rather than small, customizable tools that
> are meant to fit into (rather than abstract away) many different
> environments.
I actually concur. I seldom use a real IDE, and attempt to stay
somewhat current largely out of curiosity.
>> A design blog I read had a comment about a student feeling he was a
>> failure because he didn't know all about Photoshop and couldn't get it
>> to do what he wanted. His professor said "*Nobody* knows *all* about
>> Photoshop! It's too big and complex. Designers learn the parts that
>> do what they require." I think that's true for software tools in
>> general.
>
> 100% agreed. Most of my development is in C++, and people often
> criticize it with a similar question: "How do they expect me to learn
> all this? It's too big and complex!" Of course, the answer is that no
> individual is ever really expected to know the whole thing. The idea
> is for functionality to be available if and when you need it.
And stay out of your way if you don't. That's something Vim is good at.
You can use it largely just like vi, and save for things like the Undo
behavior, not even be aware that what you are using *isn't* the real vi.
That's something Photoshop isn't very good at. An old friend is a
former Art Director who now makes his living as a photo retoucher. He's
several releases back on Photoshop, and has no plans to upgrade, because
what he does is doable with the version he has, and every new release
seems to radically change the interface and move everything around so
you have to relearn it before you can use the new features.
>> On another line, Rex Conn, developer of the popular 4DOS/4OS2/4NT/TCC
>> replacement command processors commented that "80% of the users of my
>> software use 20% of the features. But they all use a *different*
>> 20%!"
>
> I read the same stats in a Joel Spolsky blog. Didn't realize he was
> quoting.
He wasn't. I think it's a fairly common situation, and he's encountered
the same things Rex has and stated the fact the same way.
(I read "Joel on Software", too. Good stuff.)
>>> In the embedded community, SlickEdit is very popular.
>>
>> I'm not surprised. It seems to be almost "last man standing" of the
>> commercial programmer's editor offerings, and all I know about it
>> makes it very good indeed.
>
> I haven't used it, but people do seem to love it. A lot of job postings
> now seem to require Visual Studio, though, so I don't see it dying any
> time soon, either.
It won't. An awful lot of shops are all Microsoft, all the time. If
you will only ever develop in a Microsoft language for a Windows
platform, Visual Studio may be an appropriate tool. All I've of heard
of it indicates it does the job well if you want an IDE for Windows
development.
______
Dennis
Jerry Peters
> Geoff Clare wrote:
>> DMcCunney wrote:
>>
>>>> Huh? What platform, that supports any text editor at all, does not
>>>> support some vi derivative?
> >>
>>> Things that aren't Intel based PCs.
>>>
>>> IBM mainframes under DOS/VSE, MVS, VM/CMS, or zOS, where the standard
>>> editor is ICCF (DOS/VSE) TSO/ISPF (MVS, zOS) or Xedit (VM/CMS),
>>
>> z/OS is a certified UNIX95 conforming system, and the CSQ at
>>
>> http://www.opengroup.org/csq/view.mhtml?RID=ibm%2FCV1%2F6
>>
>> indicates that it supports the _POSIX2_UPE and _POSIX2_CHAR_TERM
>> options, which means it must have vi.
>
> Well, I sit partially connected.
>
> I'd forgotten that IBM made zOS UNIX conforming. Anything that passed
> Spec 1170 could call itself UNIX, so it was theoretically possible for
> an IBM mainframe OS to become so. I recall being deeply amused when I
> heard that IBM had actually *done* it.
From the documentation, it seemed to be a fairly complete UNIX
implementation. I always wondered what kind of performance you'd get
from a shell pipline that creates say 5 or 6 processes, or something
like "find . -name '*.c' -exec grep -iH 'string' \;" in a large source
directory, considering how heavy-weight creating an address space is
in MVS.
DMcCunney
> DMcCunney <pl...@xyzzy.com> wrote:
>> I'd forgotten that IBM made zOS UNIX conforming. Anything that passed
>> Spec 1170 could call itself UNIX, so it was theoretically possible for
>> an IBM mainframe OS to become so. I recall being deeply amused when I
>> heard that IBM had actually *done* it.
>
> From the documentation, it seemed to be a fairly complete UNIX
> implementation. I always wondered what kind of performance you'd get
> from a shell pipline that creates say 5 or 6 processes, or something
> like "find . -name '*.c' -exec grep -iH 'string' \;" in a large source
> directory, considering how heavy-weight creating an address space is
> in MVS.
That depends on how they did it. (I haven't looked into it, and don't
know.) If you don't assume an address space is equivalent to a process,
I think you might go through the trouble of creating an address space
once, then have all of that stuff running as processes within that
address space.
I kind of wonder about using vi to edit a member of a PDS...
______
Dennis
Jerry Peters
I vaguely remember some sort of option to use tasks in a single AS in
place of separate processes, undoubtably for performance reasons. I
never used USS. I read the documentation more out of curiosity than
any actual need. Got out of MVS systems programming over 10 years ago
when I got tired of the IBM motto "we make the simple difficult", ie
things that used to take me half an hour or so turned into half day
chores.
How about accessing VSAM files in a UNIX-like program? There was
probably some way to do it, and I'll bet it wasn't pretty.
Jerry
DMcCunney
> DMcCunney <pl...@xyzzy.com> wrote:
>> Jerry Peters wrote:
>>> DMcCunney <pl...@xyzzy.com> wrote:
>>>> I'd forgotten that IBM made zOS UNIX conforming. Anything that passed
>>>> Spec 1170 could call itself UNIX, so it was theoretically possible for
>>>> an IBM mainframe OS to become so. I recall being deeply amused when I
> >>> heard that IBM had actually *done* it.
>>>
>>> From the documentation, it seemed to be a fairly complete UNIX
>>> implementation. I always wondered what kind of performance you'd get
>>> from a shell pipline that creates say 5 or 6 processes, or something
>>> like "find . -name '*.c' -exec grep -iH 'string' \;" in a large source
>>> directory, considering how heavy-weight creating an address space is
>>> in MVS.
>>
>> That depends on how they did it. (I haven't looked into it, and don't
>> know.) If you don't assume an address space is equivalent to a process,
>> I think you might go through the trouble of creating an address space
>> once, then have all of that stuff running as processes within that
>> address space.
>
> place of separate processes, undoubtably for performance reasons. I
There are an assortment of mainframe programs that advertise things like
"Allows up to 200 users to share a single address space", so I think you
are quite right.
> never used USS. I read the documentation more out of curiosity than
> any actual need. Got out of MVS systems programming over 10 years ago
> when I got tired of the IBM motto "we make the simple difficult", ie
> things that used to take me half an hour or so turned into half day
> chores.
<grin> I encountered that for other reasons. The machine I started on
was a 370 plug-compatible under VS1, "supporting" 300 CICS users with
2MB of physical memory supporting 16MB of virtual memory. "Death by
thrashing" was a common occurrence.
I had a cartoon in my cube of a service tech walking in to a site saying
"System been down long?" to a skeleton in a chair draped with cobwebs.
Someone put a copy in the office of the VP/IT. He was not amused. He
had begun as a COBOL programmer, and there was still one program on the
system that was "his" program that he maintained for fun. He sat down
at the terminal to do some work on his program, and Lo! The system was
down...
>> I kind of wonder about using vi to edit a member of a PDS...
> How about accessing VSAM files in a UNIX-like program? There was
> probably some way to do it, and I'll bet it wasn't pretty.
Arghhh! "Generation Dataset Error"
Back when I was in the mainframe world, my experience was that I would
encounter a problem, pull down the manula for the part of the system I
was dealing with, turn to the chapter covering the utility I was using,
and where my problem should have been mentioned there was a reference to
another manual I didn't have, no matter how many manuals I accumulated.
I have never seen a *complete* set of s390 (though it was s370 back
then) manuals. I suspect they would have filled the cube I worked in.
When I started playing with Unix, and a complete set of manuals was
three small sized binders taking about a foot of space on the shelf, I
was awe struck. I was reminded of the mainframer in a letter to
Computerworld or some such who recalled getting information on Unix, and
walking in to his boss, laying it his boss' desk, and plaintively saying
"How could we have been so wrong for so long, and nobody told us?"
> Jerry
______
Dennis
Jerry Peters
Yeah, TONE Software, also ROSCOE from ADP.
>
>> never used USS. I read the documentation more out of curiosity than
>> any actual need. Got out of MVS systems programming over 10 years ago
>> when I got tired of the IBM motto "we make the simple difficult", ie
>> things that used to take me half an hour or so turned into half day
>> chores.
>
> <grin> I encountered that for other reasons. The machine I started on
> was a 370 plug-compatible under VS1, "supporting" 300 CICS users with
> 2MB of physical memory supporting 16MB of virtual memory. "Death by
> thrashing" was a common occurrence.
I worked at a large (for the time) bank. We had a pair of 370-155's
with 2MB of storage running MVT. We had a CICS region for credit card
processing that ran in 305KB IIRC. It ran very nicely too.
>
> I had a cartoon in my cube of a service tech walking in to a site saying
> "System been down long?" to a skeleton in a chair draped with cobwebs.
> Someone put a copy in the office of the VP/IT. He was not amused. He
> had begun as a COBOL programmer, and there was still one program on the
> system that was "his" program that he maintained for fun. He sat down
> at the terminal to do some work on his program, and Lo! The system was
> down...
>
I remember that cartoon!
I was once at a site as a contractor where some of us gave the ops
manager a yoyo, since the system was up and down so much.
> >> I kind of wonder about using vi to edit a member of a PDS...
>
>> How about accessing VSAM files in a UNIX-like program? There was
>> probably some way to do it, and I'll bet it wasn't pretty.
>
> Arghhh! "Generation Dataset Error"
>
> Back when I was in the mainframe world, my experience was that I would
> encounter a problem, pull down the manula for the part of the system I
> was dealing with, turn to the chapter covering the utility I was using,
> and where my problem should have been mentioned there was a reference to
> another manual I didn't have, no matter how many manuals I accumulated.
>
> I have never seen a *complete* set of s390 (though it was s370 back
> then) manuals. I suspect they would have filled the cube I worked in.
> When I started playing with Unix, and a complete set of manuals was
> three small sized binders taking about a foot of space on the shelf, I
> was awe struck. I was reminded of the mainframer in a letter to
> Computerworld or some such who recalled getting information on Unix, and
> walking in to his boss, laying it his boss' desk, and plaintively saying
> "How could we have been so wrong for so long, and nobody told us?"
>
>> Jerry
When I was a sysprog at ALCOA we had the "software library" which was
a good sized room filled with large bookcases containing most of
the IBM manals for MVS, IMS, CICS, & our hardware; probably several
hundred.
The software library & the 4381 dedicated to tech support use were
two of the major reasons I took the job.
Now, of course, they're available on CD & probably DVD. And alot of
them are available at IBM's web site in PDF format. Made searching
Message & Codes much easier, especially for those IDC messages that
had multiple sub-codes that went on for pages.
> ______
> Dennis
DMcCunney
> DMcCunney <pl...@xyzzy.com> wrote:
>> Jerry Peters wrote:
>>> DMcCunney <pl...@xyzzy.com> wrote:
>>>> Jerry Peters wrote:
>>>>> DMcCunney <pl...@xyzzy.com> wrote:
>>> never used USS. I read the documentation more out of curiosity than
>>> any actual need. Got out of MVS systems programming over 10 years ago
>>> when I got tired of the IBM motto "we make the simple difficult", ie
>>> things that used to take me half an hour or so turned into half day
>>> chores.
>>
>> <grin> I encountered that for other reasons. The machine I started on
>> was a 370 plug-compatible under VS1, "supporting" 300 CICS users with
>> 2MB of physical memory supporting 16MB of virtual memory. "Death by
>> thrashing" was a common occurrence.
>
> I worked at a large (for the time) bank. We had a pair of 370-155's
> with 2MB of storage running MVT. We had a CICS region for credit card
> processing that ran in 305KB IIRC. It ran very nicely too.
I think part of the problem at my shop was the "plug compatible". I saw
the numbers once, and they'd managed to bring in a complete IBM
mainframe data center for just under $1 million. (This was in 1976 or
so.) To do that, they were third-party all the way, with an Itel (IIRC)
system, Trivex 3270 emulator terminals, etc. And because it wasn't
genuine IBM kit, they were releases back on OS/VS1, CICS, and other things.
(I had a Trivex terminal tht was a total lemon. The field service tech
replaced everything that *could* be replaced: CRT, keyboard, circuit
boards - everything save the metal housing - and it still didn't work.
He finally gave up and replaced it with a new one. I asked what he
planned to do with the lemon, and I said "I'm going to put it in a
storage closet in the basement, and periodically I'll come over, pull it
out, and beat it with a stick!")
We moved to a different location, and they upgraded to two 4341's
loosely coupled under JES2, and reliability soared. Of course, not long
after that, they decided to re centralize at the Division level, and
take away our data center. The difficulty of getting anything out of
the Divisional data center had been the chief impulse toward giving the
Region its own system...
My years at that shop gave me a long list of Things Not To Do if I ever
became a corporate senior manager.
>> I had a cartoon in my cube of a service tech walking in to a site saying
>> "System been down long?" to a skeleton in a chair draped with cobwebs.
>> Someone put a copy in the office of the VP/IT. He was not amused. He
>> had begun as a COBOL programmer, and there was still one program on the
>> system that was "his" program that he maintained for fun. He sat down
>> at the terminal to do some work on his program, and Lo! The system was
>> down...
>>
> I remember that cartoon!
> I was once at a site as a contractor where some of us gave the ops
> manager a yoyo, since the system was up and down so much.
I told the Systems Programmer about the VP/IT's experience, and he
turned purple and spluttered. He dreaded an on-line systems demo.
(One of the trophies in his office was a circuit board that was a cause
of major reliability problems. It would periodically freak out and issue
a channel check, bring everything to a screeching halt. A 99 cent board
as the Achilles Heel of a million dollar installation...)
>> I have never seen a *complete* set of s390 (though it was s370 back
>> then) manuals. I suspect they would have filled the cube I worked in.
>> When I started playing with Unix, and a complete set of manuals was
>> three small sized binders taking about a foot of space on the shelf, I
>> was awe struck. I was reminded of the mainframer in a letter to
>> Computerworld or some such who recalled getting information on Unix, and
>> walking in to his boss, laying it his boss' desk, and plaintively saying
>> "How could we have been so wrong for so long, and nobody told us?"
>
> When I was a sysprog at ALCOA we had the "software library" which was
> a good sized room filled with large bookcases containing most of
> the IBM manals for MVS, IMS, CICS, & our hardware; probably several
> hundred.
Sounds about right. I *did* see a complete set of manuals for a VAX/VMS
installation, and it wasn't quite as bad, but was in the running.
> The software library & the 4381 dedicated to tech support use were
> two of the major reasons I took the job.
> Now, of course, they're available on CD & probably DVD. And alot of
> them are available at IBM's web site in PDF format. Made searching
> Message & Codes much easier, especially for those IDC messages that
> had multiple sub-codes that went on for pages.
Yes, I've collected some of the IBM documents. I recently discovered I
still had a binder full of the IBM OS/MVS JCL manual. That amused me:
JCL has something like seven statements, but JCL programming was
considered a black art, and everyone at my shop used someone else's
canned procs.
______
Dennis
JussiJ
> I am surprised to find that most of the posts here are about vi or
> vim. Aren't there other editors (besides the ones that have their own
> groups) that people use?
On the Windows platform, the Zeus editor/IDE:
Zeus is a scriptable programmer's editor.
DMcCunney
With configurable keymaps for WordStar, Brief, Emacs, and Epsilon, and
scripting in Lua, Python, Tcl, VB, or JavaScript.
______
Dennis
Jerry Peters
The bank had a lot of OEM stuff, STC disks, REI check sorters, and
some really lousy 3270 look likes. Most of this stuff was on one
channel which hung regularly.
Just before I left, the bank installed an Amdahl mainfame.
>
> (I had a Trivex terminal tht was a total lemon. The field service tech
> replaced everything that *could* be replaced: CRT, keyboard, circuit
> boards - everything save the metal housing - and it still didn't work.
> He finally gave up and replaced it with a new one. I asked what he
> planned to do with the lemon, and I said "I'm going to put it in a
> storage closet in the basement, and periodically I'll come over, pull it
> out, and beat it with a stick!")
>
One of the junk 3270's developed a habit of sending an interrupt in,
but with no id byte, for other terminals in the cluster, which the FE
claimed was impossible.
> We moved to a different location, and they upgraded to two 4341's
> loosely coupled under JES2, and reliability soared. Of course, not long
> after that, they decided to re centralize at the Division level, and
> take away our data center. The difficulty of getting anything out of
> the Divisional data center had been the chief impulse toward giving the
> Region its own system...
ALCOA (and PPG) did something similar, they put various sized DOS/VSE
systems in the plants, with local administrators but supported out of
HQ. About 10 years later we re-centralized because the distributed
stuff was costing too much.
I have a friend who's contracting at a large regional bank like that,
they don't allow any of the new stuff in JCL, like if and set. He put
an "if lastcc" in an IDCAMS file and was asked what COBOL code was
doing in there.
ALCOA tended to be conservative, but nowhere near that bad. And of
course, tech support didn't really have to follow standards, I could
get just about any JCL installed in production.
Discussing editors again, I never thought SPF was that bad. Then again
I'd experienced several really primitive editors before SPF became
dominant. Its major weakness, which it shared with all IBM products
was a complete lack of regular expression support (picture strings were
a joke, especially as you couldn't use special characters in the
replacement string). I use regexes a lot! Saves enormous amounts of
time and effort.
Jerry
> ______
> Dennis
DMcCunney
> DMcCunney <pl...@xyzzy.com> wrote:
>> Jerry Peters wrote:
>>> DMcCunney <pl...@xyzzy.com> wrote:
>>>> Jerry Peters wrote:
>>> I worked at a large (for the time) bank. We had a pair of 370-155's
>>> with 2MB of storage running MVT. We had a CICS region for credit card
>>> processing that ran in 305KB IIRC. It ran very nicely too.
>>
>> I think part of the problem at my shop was the "plug compatible". I saw
>> the numbers once, and they'd managed to bring in a complete IBM
>> mainframe data center for just under $1 million. (This was in 1976 or
>> so.) To do that, they were third-party all the way, with an Itel (IIRC)
>> system, Trivex 3270 emulator terminals, etc. And because it wasn't
>> genuine IBM kit, they were releases back on OS/VS1, CICS, and other things.
>
> The bank had a lot of OEM stuff, STC disks, REI check sorters, and
> some really lousy 3270 look likes. Most of this stuff was on one
> channel which hung regularly.
> Just before I left, the bank installed an Amdahl mainfame.
I was aware of the Amdahl stuff, but never worked on it. Gene Amdahl
later founded Trilogy Systems, working on "wafer-scale integration".
Unfortunately, that proved a bit too much, even for him, and Trilogy
folded before actually shipping a product.
>> (I had a Trivex terminal that was a total lemon. The field service tech
>> replaced everything that *could* be replaced: CRT, keyboard, circuit
>> boards - everything save the metal housing - and it still didn't work.
>> He finally gave up and replaced it with a new one. I asked what he
>> planned to do with the lemon, and I said "I'm going to put it in a
>> storage closet in the basement, and periodically I'll come over, pull it
>> out, and beat it with a stick!")
>>
> One of the junk 3270's developed a habit of sending an interrupt in,
> but with no id byte, for other terminals in the cluster, which the FE
> claimed was impossible.
<chuckle> Sounds like code I've seen with comments stating "This error
should never happen..."
>> We moved to a different location, and they upgraded to two 4341's
>> loosely coupled under JES2, and reliability soared. Of course, not long
>> after that, they decided to re centralize at the Division level, and
>> take away our data center. The difficulty of getting anything out of
>> the Divisional data center had been the chief impulse toward giving the
>> Region its own system...
>
> ALCOA (and PPG) did something similar, they put various sized DOS/VSE
> systems in the plants, with local administrators but supported out of
> HQ. About 10 years later we re-centralized because the distributed
> stuff was costing too much.
Part of the fun at my old shop would have been justifying it. I once
instigated a project to get an interface built between the accounting
system and the financial modeling system the analysts used to prepare
the monthly numbers. Each month, the GL first post would come out, the
analysts would get a foot high stack of print out, and spend two weeks
manually transcribing the actual expenses numbers from the printout into
the modeling systems to be compared with budget and forecast. Since
both systems ran on the same mainframe, I didn't understand why there
was no feed from one to the other. (Putting it to the financial folks
as "Why are you paying MBSs $30K a year to be data entry clerks" got the
users I supported to vote yes on the idea.)
The VP of Applications Development was enthusiastic: it gave his
programmers a project that would actually be useful to the Region, and
for which they see a finished product ship. Apparently, the data center
had been created originally to support Marketing, but Marketing could
never make up its mind what it wanted, and everything got mired in a
pool of changing specs.
Hard to justify the expense of a mainframe data center in that circumstance.
>> Yes, I've collected some of the IBM documents. I recently discovered I
>> still had a binder full of the IBM OS/MVS JCL manual. That amused me:
>> JCL has something like seven statements, but JCL programming was
>> considered a black art, and everyone at my shop used someone else's
>> canned procs.
>
> I have a friend who's contracting at a large regional bank like that,
> they don't allow any of the new stuff in JCL, like if and set. He put
> an "if lastcc" in an IDCAMS file and was asked what COBOL code was
> doing in there.
Because nobody there understands it, either...
My experience at my old shop was that I'd have a problem with a system
run out of another part of the bank, track down the folks responsible
for it, and be told "We're sorry, but that program was written five
years ago by a consultant. He's no longer with the bank, and no one
here knows the language he wrote it in. We just run it. If you have a
problem, you're on your own..."
> ALCOA tended to be conservative, but nowhere near that bad. And of
> course, tech support didn't really have to follow standards, I could
> get just about any JCL installed in production.
You could in some cases *create* the standards, I should think.
> Discussing editors again, I never thought SPF was that bad. Then again
> I'd experienced several really primitive editors before SPF became
> dominant. Its major weakness, which it shared with all IBM products
> was a complete lack of regular expression support (picture strings were
> a joke, especially as you couldn't use special characters in the
> replacement string). I use regexes a lot! Saves enormous amounts of
> time and effort.
Agreed, SPF wasn't bad. I'd simple been spoiled by the ACEP program
that preceded it. It did what SPF did, and an assortment of things it
didn't do. (Like supporting up to ten simultaneous editing sessions you
could switch between.)
Dr. Nikolai Bezroukov on his Softpanorama site has an interesting
classification of editors into "Eastern Orthodox" and "Western
Orthodox". (http://www.softpanorama.org/Articles/orthodox_editors.shtml)
Eastern Orthodox editors are distinguished by a command line and support
for code folding, with the archetype being Xedit.
Western Orthodox editors are distinguished by regular expressions and
the ability to pipe buffers through external filters, with the archetype
being vi.
We're seeing editors now that combine the paradigms, but it took a while...
> Jerry
______
Dennis
Tom Morris
> Jeff Schwab <je...@schwabcenter.com> wrote:
>> Chetan wrote:
>>
>> Anyway, there's no prohibition on discussing other editors here. If
>> you have specific questions about (emacs|SlickEdit|Notepad++|.*),
>> somebody (though probably not me) will likely be able to answer them.
>
> ...but bear in mind that a vim-user will almost certainly join the
> thread, ignore the OP's actual question, and state that the solution
> is to use vim.
>
They may have a point though. I mean, the Emacs people are lost forever,
but if you use Jed or Nano or whatnot, you *are* an ideal potential
convert for the Cult.
--
Tom Morris
<http://tommorris.org/>