a good programming text editor (not IDE)

[BartlebyScrivener]

Emacs must be dying if this thread could get all the way to 20 with
nobody arguing with the vi folks. Will the Windows vim and gvim users
vouch for its stability on Windows?

rd

 

[Jarek Zgoda]

BartlebyScrivener napisa³(a):

Emacs must be dying if this thread could get all the way to 20 with
nobody arguing with the vi folks. Will the Windows vim and gvim users
vouch for its stability on Windows?

Sure. Do you need any legal assistance?

 

[Benji York]

Emacs must be dying if this thread could get all the way to 20 with
nobody arguing with the vi folks.

heh

Will the Windows vim and gvim users vouch for its stability on
Windows?

It's very stable on Windows.

 

[Istvan Albert]

To paraphrase someone else (their identity lost in my mental fog) about
learning VI:
"The two weeks you'll spend hating vi (or vim) as you learn it will
be repaid in another month, ad the rest is pure profit."

Time and again I hear this (no shortage of Vim fans, same with Emacs),
and I know I should know better but always believe them yet again.
Invariably I download Vim play with it for an hour, get increasingly
frustrated and give up. Most likely I'm greatly spoiled by using
EditPlus (Windows only), it just makes it so easy to do the basic
programming tasks that I need, everywhere else I turn I see far more
functionality but at the price of not being able to do basic tasks as
efficiently as I need them.

Say I want to be able to execute the python program I'm currently
editing. Nothing simpler in EditPlus, Tools->Configure Tools->Add Tool
then specify which program you want to run, what parameters it takes
and whether to capture the output or not ... total time it took me
first time I wanted to do this ... about 3 minutes ... from now on
pressing Ctrl-1 while editing the source will execute the python on the
current source *and* it displays the output in a lower pane as it runs
*and* it allows me to simultanously edit the file *while* the program
is running. Outstanding.

Yet after searching and reading stuff for more than an hour I was
unable to accomplish the same thing in Vim though I'm already familiar
enough with basic editing and setup (through my previous trials and
tribulations) ... I have a few solutions that end up doing something
similar but are quite a few keypresses longer both to invoke or to get
back to the source that I'm writing, or I lose editing control while
the program is running ... etc...

So if the OP is on windows just head over and get EditPlus (UltraEdit
and TextPad seem to be similar), and just accept the fact that you are
already using an editor that as good as an editor can get ... I know
I'd pay that registration once again for an editor that works the same
way on Linux...

i.

 

[Fredrik Lundh]

Emacs must be dying if this thread could get all the way to 20 with
nobody arguing with the vi folks.

hints: 1) editor wars are so last century. 2) emacs has already won.

</F>

 

[Jarek Zgoda]

Fredrik Lundh napisa³(a):

1) editor wars are so last century.

2) emacs has already won.

You died in last century with your editor, we have tabs.

 

[John Salerno]

hints: 1) editor wars are so last century. 2) emacs has already won.

Uh oh, here we go..............

 

[Sybren Stuvel]

John Salerno enlightened us with:

Ok, you guys are slowly converting me, but I do have one question: which
"version" of VIM should I use

The latest, version 7.0.

I mean, there seem to be at least two versions, a text version and
the GUI version you mention.

Pick whichever is comfortable for you. On Windows and Mac I always go
for GVim. On Linux I generally install both (except on my server,
which only has the console version).

Are the options shared between the two, or is it that you are more
or less "set" in one once you choose it, and if you move to the
other you have to redefine your preferences, etc.?

~/.vimrc is shared by both, ~/.gvimrc is only read by gvim. That way,
you can have both

Sybren

 

[Fredrik Lundh]

You died in last century with your editor, we have tabs.

real python programmers don't use tabs.

</F>

 

[Scott David Daniels]

Time and again I hear this (no shortage of Vim fans, same with Emacs),
and I know I should know better but always believe them yet again.
Invariably I download Vim play with it for an hour, get increasingly
frustrated and give up.

Surprise, surprise. One hour is not two weeks.

--Scott David Daniels
(e-mail address removed)

 

[Slawomir Nowaczyk]

On Thu, 15 Jun 2006 13:18:53 -0700

#> Emacs must be dying if this thread could get all the way to 20 with
#> nobody arguing with the vi folks.

We have learned the important lesson: those who are looking for true
enlightenment will find Emacs anyway. We no longer feel the need to
argue with people who praise various versions of notepad ;-) ;-) ;-)

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

Conscience is what hurts when everything else feels so good.

 

[Jarek Zgoda]

Fredrik Lundh napisa³(a):

real python programmers don't use tabs.

So I'll tab you the beer I owe you when we meet at EuroPython.

 

[Roel Schroeven]

(e-mail address removed) schreef:

If you use it for a little bit, one day you'll be editing a document in
Word, or notepad, or SciTE, or Eclipse; you'll instinctively type
'[ESC]:wq', and be suprised that the app is still open. That's when
you realize there's no turning back.

Exactly... it happens very regularly that my C++ compiler complains
about :w, jjj or kkkk in my code. Being able to keep your hands on the
base row instead of having to switch back and forth to the arrow keys is
a tremendous benefit, which I didn't appreciate that much until I
learned by experience that I unconsciously try, unsuccessfully of
course, to do it in other editors.

BTW, you can type :x instead of :wq. 33% shorter!

 

[Dave Hansen]

I know there's a request for a good IDE at least once a week on the ng,
but hopefully this question is a little different. I'm looking for
suggestions for a good cross-platform text editor (which the features
for coding, such as syntax highlighting, etc.) but not a full IDE with
all the fancy jazz (GUI developer, UML diagrams, etc.).

Ideally, it would be something I could even put on a flash drive and
move from computer to computer, but this isn't necessary. Just something
I can immediately use in either Windows or Linux (or Mac, if necessary).

Very small, very fast, very powerful, and very portable (though I'm
not sure about Mac...): Take a look at Jed from www.jedsoft.org.

You might not find it pretty, however...

Regards,
-=Dave

 

[Dave Cook]

I know there's a request for a good IDE at least once a week on the ng,
but hopefully this question is a little different. I'm looking for
suggestions for a good cross-platform text editor (which the features
for coding, such as syntax highlighting, etc.) but not a full IDE with
all the fancy jazz (GUI developer, UML diagrams, etc.).

For something very light, jed has a pretty good python mode that is based on
the emacs python-mode.

I still swear by XEmacs with python-mode, though I do wish for intelligent
code completion sometimes (pycomplete just gives me errors). The XEmacs
features that keep me from switching to Gnu Emacs are buffer tabs and
hyperlinked error messages.

Most IDEs are rather weak as text editors compared to emacsen.

On the Mac, you might try Aquamacs; though I don't like the default
behavior, a new user would probably have less of a problem with it.

Dave Cook

 

[BartlebyScrivener]

Most IDEs are rather weak as text editors compared to emacsen.

That's true, but even emacs and xemacs don't offer simple automatic
word wrap (i.e. wrap a line without splitting words or putting an eol
or hard carriage return at the end of every line). I don't know if vim
allows this. It's something writers just take for granted in non-Unix
text editors.

rd

 

[Tim Daneliuk]

Time and again I hear this (no shortage of Vim fans, same with Emacs),
and I know I should know better but always believe them yet again.
Invariably I download Vim play with it for an hour, get increasingly
frustrated and give up. Most likely I'm greatly spoiled by using

This is not a skill or competence issue - it is a mindset issue.
Some people are naturally more comfortable with point-n-shoot
GUI interfaces. Some of us old retrograde dinosaurs imagine GUIs
to be a place to run multiple xterms so we can use the keyboard
even more. That said, to the extent you learn to master the keyboard
with any tool, you will eventually become far more efficient doing
almost everything you do. I find GUI editors/browsers/et al easy
to learn or good for casual use, but an interference when I want
to do a lot fast. I got so frustrated with it all, I wrote my
own pure Python file browser that is *all* about the keyboard and
never having to say you're a mouse user (though you can):

<Shameless Self-Promotion>

http://www.tundraware.com/Software/twander/

</Shameless Self-Promotion>


GUIs are great for two classes of use: 1) For non-specialist or casual
users who need to be productive with minimal training or support, and
2) Classes of problems that are inherently graphical - photo editing
is such an example. But, I have yet to see a significant advantage
to programming under a GUI (beyond the aforementioned ability to run
multiple instances of emacs, xterm ...). Yes, a GUI editor is easy to
*learn* and use casually, but text intensive work is best done with
tools optimized for doing so.

BTW, when God created the heavens and earth, the OS was BSD Unix, the
config files were edited with emacs, and the doc was written in LaTeX
using the dvi2stonetablets backend...

 

[Slawomir Nowaczyk]

On Thu, 15 Jun 2006 15:52:49 -0700

#> >> Most IDEs are rather weak as text editors compared to emacsen.
#>
#> That's true, but even emacs and xemacs don't offer simple automatic
#> word wrap (i.e. wrap a line without splitting words or putting an eol
#> or hard carriage return at the end of every line).

Of course it does... there is longlines.el and longlines-mode in my
copy of GNU Emacs:

,--------------------------------------------------
| Toggle Long Lines mode.
| In Long Lines mode, long lines are wrapped if they extend beyond
| `fill-column'. The soft newlines used for line wrapping will not
| show up when the text is yanked or saved to disk.
`-------------------------------------------------

I do not use it, personally, but it does exist.

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

COMMAND: A suggestion made to a computer.

 

[Neil Hodgson]

John Salerno:

Based on another thread, I tried out Scite, but no matter what I do it
doesn't seem to remember the window size and position, or any options I
choose (like showing line numbers). It seems to always reset itself each
time I open it.

SciTE is configured by modifying options files rather than by
automatically remembering your choices. If you don't like this approach
then you probably won't like SciTE.

Neil

 

[david.reitter]

#> That's true, but even emacs and xemacs don't offer simple automatic
#> word wrap (i.e. wrap a line without splitting words or putting an eol
#> or hard carriage return at the end of every line).

Of course it does... there is longlines.el and longlines-mode in my
copy of GNU Emacs:

,--------------------------------------------------
| Toggle Long Lines mode.
| In Long Lines mode, long lines are wrapped if they extend beyond
| `fill-column'. The soft newlines used for line wrapping will not
| show up when the text is yanked or saved to disk.
`-------------------------------------------------

Not quite. Longlines Mode actually inserts real carriage returns into
the buffer, which you will notice in a lot of situations. For example,
text does not get rewrapped when you resize the frame to a different
width. Also, searching for two words (with a space in between them)
won't work when the target text happens to wrap them just there
(happens to me all the time when editing LaTeX). Thirdly, you'll find
that when you load a file, its lines won't automatically wrap at the
frame (actually, the window) width position.

All of these things don't bother long-time Emacs people, because most
of them tend to see a GUI as a way to display many terminals (something
like that has been said by someone else before in this thread), and
most of them rely on traditional Unix tools such as grep which work
line-by-line.

I have advocated seeing lines (with a CR and/or LF) as paragraphs, and
making the display of lines a matter of the particular display, not the
original data. That is much more natural for wrapped text, i.e. real
text rather than computer-parseable files.
A patch to Emacs 22 has been produced after that discussion, but sadly,
it isn't mature enough to make it into the final Emacs 22 release. But
I am confident we're going to see this in GNU Emacs 23, or at least in
Aquamacs Emacs in a little while.