[OT] Editors & mac to Linux stories

[Derick Centeno]

I feel moved to quote Darth Vader when he encountered the fighting
ability of his son, in which he stated simply, "Impressive...But All to
Easy (to defeat)."  However, I have also used BBedit for a long time; so
long that I'm quite familiar with it's history and standing in the Mac
community.  I do not mean to belittle anything about it.  I upgraded
years back from the "free" package to the "full" version and was quite
content when I was programming in Codewarrior when the Mac OS was in
it's Classic phase. My respect for BBEdit as a product is reflected in
the fact that I bought the "full" version, whereas I NEVER bought the
full version which is MS Office.  I only have the licenses for the
Classic version of Word and Excel.

Even so, they nor Microsoft really have a clue as to what's happened as
a result of Apple's choice of supporting open source while continuing to
develop the proprietary components of OS X.  For instance, you mention
that Bare Bones is working on an inline spelling system for BBEdit...
fine, I hope they are successful. But xemacs and vim has is NOW and
they've had it for YEARS!!  

I hope that you are not holding back your research waiting for Bare
Bones to develop what already exists within vim and xemacs; that would
be a waste of time now wouldn't it?  Especially since the user base of
vim and xemacs is far beyond what Bare Bones would ever hope to
attract!  The kinks have been all worked out and expunged. 

Bare Bones, when the Mac was all alone, was great.  Those days no longer
exist and they should move on also to something else.  I will not be
upgrading for the same reason I will not be upgrading MS Office, or
Excel or Word.  It is not necessary because the "better" and most tested
products are already in existence, or in the case of OpenOffice and
gnuplot and Blender they are quite enough for my uses. 

The output header is the first few lines at the top of the page normally
stating date, filename, user name, sometimes even the time of the date
of printing or the day the file was saved together with the time. 
xemacs produces this information in an outstanding way which is called
Pretty printing, and it is much better than anything else for producing
programming output.  Most programmers however are not into printing
pretty things, they are into coding.  Even so, xemacs is the app to beat
and BBEdit can't do it...

Give in and try xemacs for your application Clint, you'll probably be
very surprised of what it can do.  You can even play towers of hanoi
within xemacs while accessing the psychologist and working within
multiple windows on separate projects.   C'mon... 
Resistance is Futile!  

Enjoy...

On Sun, 2004-06-06 at 15:24, Clinton MacDonald wrote:
> Derick:
> 
> Here's another off-topic rant of mine -- feel free to ignore it or 
> comment, as you see fit. As I re-read my response to Derick's comments, 
> I see that, once again, I mostly agree with him, but have to shoot off 
> my mouth anyway. :-)
> 
> The executive summary: I agree that vi and emacs (and their updated 
> cousins) are powerful and useful instruments (and not so bad as I make 
> out), and are essential in configuring Linux in any fashion. However, I 
> still see the need for powerful GUI-based text editors for the new 
> generation of Linux (and Mac OS X) users. BBEdit is only one example of 
> the power and ease-of-use that can be had in such GUI-based text editors.
> 
> Derick Centeno wrote:
> > I'm surprised that many don't know about vi or vim! vi is
> > THE UNIX programmer's editor; vim is vi with color display
> > and output abilities. Emacs and Xemacs are also very powerful
> > and flexible editors in their own rights.
> 
> I do know about them, and so, I am sure, do most people who have used 
> Yellow Dog Linux for more than a few days. In fact, I am *certain* that 
> I mentioned them in my earlier post.
> 
> I don't *like* using them, but I know about them. :-) vi and emacs were 
> invented in the pioneering days of Unix and its predecessor operating 
> systems. In those days, most editing was done using half-duplex 
> teletypes to edit code using ed. CRT monitors showing a limited text 
> character set were a major innovation. Since text was the only input 
> mode and there wasn't much in the way of meta keys, vi and emacs 
> developed mechanisms to change mode from keyboard input only. These were 
> hot and flashy items in the day, since keyboards were proprietary, and 
> one could not count on having as much as a shift key. I learned (but 
> have since forgotten) vi soon after that era. When it was the only game 
> in town, it was pretty cool.
> 
> > Anyone of them blow BBEdit out of the water as regards to
> > functions and flexibility.
> 
> Now, them's fightin' words! :-) BBEdit inspires its religious zealots, 
> just like open source software or the latest flavor from Ben & Jerry's. 
> Some users like function and flexibility, some like interface and 
> consistency. Don't confuse quality with quantity in every case. 
> Microsoft (spit) Word has a large *quantity* of functions, but that 
> doesn't make it the highest *quality* word processor available (the sad 
> fact that there are so few high quality word processors available for 
> Mac OS X is the subject of a different off-topic rant).
> 
> I'm an interface and consistency guy, myself. Unlike Unix/Linux, on the 
> Mac platform, there are not enough general-purpose tools that can 
> perform a wide range of functions within a single application interface. 
> For Unix/Linux, that application is vi or emacs, on the Mac it is BBEdit.
> 
> BBEdit is awfully good, though it falls short of being perfect, even for 
> a GUI-lovin' guy like myself (for instance, I would really love to see 
> inline spell checking for BBEdit, which I am told is on the way). 
> However, it has so many text-munging functions -- functions that are as 
> easily discoverable by a novice user as well as an expert -- that it is 
> generally the first application I open in the morning and the last one I 
> turn off at night. On the other hand, the few features it is missing irk 
> me, because I generally must have *two* text editors open at all times 
> with overlapping feature sets (SubEthaEdit -- whose name is tremendously 
> forgettable -- is a dark horse contender for BBEdit's crown, though it, 
> too, has limitations and annoyances).
> 
> > vi and vim can be modified via either writing scripts
> > within .profile or in our case, .bash_profile and
> > creating vim resource files directing vim to behave
> > in specific ways.
> 
> I only wish I had the brain cells left to learn how to write such 
> scripts. :-)
> 
> > Each program can guide you how to use it by itself!
> 
> That is true. emacs is famous for its self-directed tutorial, which I am 
> looking forward to using when time permits. Until then, I will use vi 
> and my brain-dead cheat sheet.
> 
> > I haven't yet figured out how to get vi to produce the
> > output header similar to how BBedit does it, but it's
> > just a matter of time. Once I've done that (which is
> > the only reason I like BBedit anyway) I will have no
> > use to use BBedit at all.
> 
> I don't know what is an "output header" (a programming thing, maybe?), 
> but I think this is an example of the kinds of things that the folks at 
> Bare Bones Software have been trying to put into BBEdit. I was 
> introduced to BBEdit in 1993 for a scientific project (this was in the 
> early days of the genome project). At the time, BBEdit was the only tool 
> available on the Mac to perform grep-style find-and-replaces (Mac-Perl 
> became available soon afterwards, but its learning curve was higher than 
> BBEdit's). BBEdit could also open files containing greater than 32 kB of 
> text, a major limitation in Mac text editors of the time. For the Mac OS 
> of that time, BBEdit was the closest thing we had to some of the 
> powerful text-munging tools that had been available on Unix (Linux was 
> still an infant) at the time. Nevertheless, non-hackers like myself 
> could use BBEdit without trouble because it conformed to Mac interface 
> conventions (cmd-right arrow to navigate to the end of a line, etc.). A 
> vi or emacs clone probably would have failed in the market because we 
> Mac users are so highly invested in our comfortable little human 
> interface guidelines. From then to now, BBEdit essentially grew up as a 
> Mac application that added features, but remained true to its roots.
> 
> > OpenOffice.org is not quite there yet, so MS Office
> > can probably survive for quite a bit longer. The
> > clock is ticking already, however.
> 
> I agree with your assessment 100%! OpenOffice.org is trying too hard to 
> be a clone of Microsoft <spit> Office *1997*, while Office on the Mac 
> (and on the PC, I assume) are actually becoming more and more refined, 
> and less and less buggy. I am looking forward to smaller, more elegant 
> applications like AbiWord to win over the Mac OS X market.
> 
> > There may be scientific and other tools available for
> > Mac OS X, but they are proprietary. One may be saving
> > time, but whether one is saving money depends strictly
> > upon one's planned use of the computer and what he/she
> > has in mind to develop.
> 
> Respectfully, I must disagree with you. This is one area in which I do 
> have some experience, and I believe you are wrong. There are many 
> scientific and other tools available for the Mac, AND MOST OF THEM ARE 
> *FREE*. most of the scientific packages I use in genome searching and 
> the like are the same ones that are used in Linux, except they have been 
> ported to Mac OS X. In fact, I am looking forward to "retiring" my 
> desktop Power Mac G4 to server status, and the major program we will run 
> is one called WU-BLAST, an important DNA searching tool. WU-BLAST is 
> open source and free (I am looking forward to this project -- lots of 
> fun). The ones that are not free, usually have considerable value, and 
> are worth the price (since I pay their salaries from grants, my lab 
> workers' time is the most expensive commodity I have).
> 
> I'm sorry I let this go on so long. I will now return you to your 
> regular program, already in progress.
> 
> Best wishes,
> Clint