The introductory paper Orthodox Editorsintroduced
some ideas on which this page was build. Here is the abstract of the paper:
This paper tried to introduce a new concept: orthodox editors as a special category of editors.
All of them have command line set of commands and respective glue macrolanguage. We have found two
such families:
Eastern Orthodox family represented by such editors as XEDIT, Kedit, THE. All of
them use REXX as a glue macrolanguage. All of them support folding which the second
important feature typical for this category of editors
Western Orthodox family represented by vi and its derivatives with VIM as the top
representative of the category. They are characterized by extensive support for regular
expressions and ability to pipe the editing buffer through external filters. The
letter is the key advantage as it provides the unique and unmatched ability to use Unix
utilities and shell scripts as an extension of the
command set. Some of them (VIM) also support folding. They often have ad-hoc macro language
(primitive in VI, better but still ugly in VIM)
We define the notion of "orthodox editors" as having the following distinct features:
They have a well-defined command set that is comparable
in power to GUI based commands and command line can be used to enter editor commands.
For some of them (vi - line ) that comes naturally, from the fact that they were
initially designed for typewriters.
They permit doing any editing task using keyboard (although mouse can speed
up or simplify many of those tasks and is not rejected in the extremist way)
They use a standard scripting language as a macrolanguage (TCL, REXX) or unique for
the application (YASL - yet another scripting language) like in vim 6 as a macrolanguage.
It serves as a glue for the command set implemented by the editor. With some reservations we
can accept a unique for the application (YASL - yet another scripting language)
like in VIM. This is definitely less attractive solution as it is difficult to master the language
that you use only for a specific application (in this case an editor). The same consideration
is applicable to Emacs.
They support folding (all
command in XEDIT and its derivatives; folding capabilities
in VIM )
They distinguish between editing buffer and the windows in which this editing buffer
is displayed allowing multiple windows to display the same buffer.
They support regular expressions
They permit processing selected part of the editing buffer or all the buffer via pipe
connected to external command (! command in vi)
They support multiple views of the same editing buffer.
They allow piping in output from arbitrary pipe into the current position of cursor,
selection, or all buffer as well as exporting a selection or all buffer as an input stream for
an arbitrary pipe.
This article is a modest attempt to create a basic classification useful for further studying
this important class of editors. The author argues that this class of editors can serve as viable
mid-weight editors for programmers (see a companion paper
A Note on Size-based Classification
of Text Editors for this further discussion of related ideas).
This article is a modest attempt to create a basic classification
useful for further studying this important class of editors. The author argues that this class of
editors can serve as viable editors for programmers providing despite Spartan interface rich functionality
absent in almost any other editor with possible exception of vi and its derivatives. Despite integrating
a macro language they are actually pretty small, mid-weight by some standards (see a companion paper
A Note on Size-based Classification
of Text Editors for this further discussion of related ideas).
Please note that both subclasses of orthodox editors were pioneers in introducing several important
for any modern editor features, features that unfortunately still are absent or poorly implemented
in most other editors:
Eastern orthodox editors introduced
folding (all command in XEDIT)
Usage of a standard scripting language as a macro language (REXX).
Multiple views on editing buffer
Ability to bind execution of a command on the command line to the selection on the screen
Western Orthodox editors have command set of ex editor. They introduced
regular expressions as a editing tool
extremely powerful concept of editing buffer via Unix pipes; the latter is still
mostly missing in most other advanced editors.
The idea of two command channels: channel to internal interpreter (":" commands) and
channel to OS shell ("!" commands).
This paper explores two sets of deep interconnections that
were previously unnoticed in the literature:
There is a deep interconnection between OFMs and Orthodox
Editors. Actually OFM can be implemented on the base of EOE and VM/CMS actually contains
a file manager that is XEDIT-based.
There is a subtle similarity between XEDIT family and VI
family, those two seemingly unconnected families of editors one originating at East
Coast and the other in West coast (that's why I used names Eastern Orthodox and Western Orthodox
for them ;-).
Actually the second point was the main reason that I decided to use
a superclass term "orthodox editors" that includes as subclasses both XEDIT editors line and VI
editors lines. Not only because I like to invent new terms (that goes with Ph.D ;-), but I really
see deep similarities between them and their connection to a similar phenomenon that I studied earlier
in case of File Managers (see OFM page for details). Those tools
are representative of a different approach to GUI interface then Apple GUI or Microsoft GUI (which
are converging). Interface that can be called "Orthodox Interface". And this Spartan interface
with ancient-looking, "half-baked" GUI with command line present give users important and unique
capabilities that are missing in other similar "pure GUI" Tools. They survived because they are
capable of giving advanced users the ability to achieve an extremely high productivity, beating
competition. Although some design decisions in those editors were dictated by limitation of old
hardware they withstand the test of time and proved to be useful and extremely productive tools
for modern environments.
Another interesting for me issue is the value of editors
of different sizes (lightweight, mid-weight and heavyweight). My thought on this issue are reflected
in another paper A Note on Size-based
Classification of Text Editors Here is the abstract:
The article presents an attempt to understand correlation between features of text editors and
editor size based of tasks each weight category performs better and1 propose size based classification
of editors
The concept of "editor weight" is useful for explaining why most programmers use several editors
(usually three: standalone lightweight editor like Notepad, midweight editor like Vim, Kedit or
SlickEdit and heavyweight editor /IDE type of environments like Microsoft Visual Studio .Net, Emacs, etc).
That suggests that there are tasks for which one editor of a certain
size suit best and perfoming of which with the editor of a different category is less efficient
despite the additional power it might provide. This paradox that most programmers use several
editors while leading one would be more efficient can be explained by the hypothesis that editors
can be classified into three distinct categories and that each category of editors has its own unique
set of features In this case one size does not fit all. We will distinguish
lightweight editors (editors
that does not need installation and can be fully functional if the computer contains one executable
and a user can start editing after moving this executable to new computer. They can They
can use additional initialization and configuration files but they should be optional of at
max two files (editor executable and optional initialization file/files)
midweight editors should have
powerful macro language, folding and full multi-windows support. That's the category were orthodox
editors fall into.
heavyweight editors are essentially
in IDE in disguise. Emacs is classic example of heavyweight editor, Visual Studio .Net is another
example.
The main idea here that there are tasks that are better, quicker performed by lightweight editors
and they're are tasks that are better performed by midweight/heavyweight editors, so those categories
of editors develop in different directions.
Most programmers spend a lot of time editing the code (may as much as 40%). If that's the case,
finding the best tool available and, if necessary, spending a few extra dollars for it definitely is
a good investment.
"... Komodo Edit is my favorite text web editor. It includes a lot of great features for HTML and CSS development. Additionally, you can get extensions to add language support or other helpful features, like special characters. ..."
"... Komodo doesn't outshine as the best HTML editor, but it's great for for the price, especially if you build in XML where it truly excels. I use Komodo Edit every day for my work in XML, and I use it a lot for basic HTML editing as well. This is one editor I'd be lost without. ..."
There are two versions of Komodo
available - Komodo Edit
and Komodo IDE. Komodo Edit is open source and free to download. It is a trimmed down
counterpart to IDE.
Komodo Edit is my favorite text web editor. It includes a lot of great features for HTML and
CSS development. Additionally, you can get extensions to add language support or other helpful
features, like special characters.
Komodo doesn't outshine as the best HTML editor, but it's great for for the price,
especially if you build in XML where it truly excels. I use Komodo Edit every day for my work in XML, and I
use it a lot for basic HTML editing as well. This is one editor I'd be lost without.
To open multiple files, command would be same as is for a single file; we just add the file
name for second file as well.
$ vi file1 file2 file 3
Now to browse to next file, we can use
$ :n
or we can also use
$ :e filename
Run external commands inside the editor
We can run external Linux/Unix commands from inside the vi editor, i.e. without exiting the
editor. To issue a command from editor, go back to Command Mode if in Insert mode & we use
the BANG i.e. '!' followed by the command that needs to be used. Syntax for running a command
is,
$ :! command
An example for this would be
$ :! df -H
Searching for a pattern
To search for a word or pattern in the text file, we use following two commands in command
mode,
command '/' searches the pattern in forward direction
command '?' searched the pattern in backward direction
Both of these commands are used for same purpose, only difference being the direction they
search in. An example would be,
$ :/ search pattern (If at beginning of the file)
$ :/ search pattern (If at the end of the file)
Searching & replacing a
pattern
We might be required to search & replace a word or a pattern from our text files. So
rather than finding the occurrence of word from whole text file & replace it, we can issue
a command from the command mode to replace the word automatically. Syntax for using search
& replacement is,
$ :s/pattern_to_be_found/New_pattern/g
Suppose we want to find word "alpha" & replace it with word "beta", the command would
be
$ :s/alpha/beta/g
If we want to only replace the first occurrence of word "alpha", then the command would
be
$ :s/alpha/beta/
Using Set commands
We can also customize the behaviour, the and feel of the vi/vim editor by using the set
command. Here is a list of some options that can be use set command to modify the behaviour of
vi/vim editor,
$ :set ic ignores cases while searching
$ :set smartcase enforce case sensitive search
$ :set nu display line number at the begining of the line
$ :set hlsearch highlights the matching words
$ : set ro change the file type to read only
$ : set term prints the terminal type
$ : set ai sets auto-indent
$ :set noai unsets the auto-indent
Some other commands to modify vi editors are,
$ :colorscheme its used to change the color scheme for the editor. (for VIM editor only)
$ :syntax on will turn on the color syntax for .xml, .html files etc. (for VIM editor
only)
This complete our tutorial, do mention your queries/questions or suggestions in the comment
box below.
Posted on Vim will show you
the decimal, octal, and hex index of the character under the cursor if you type ga
in normal mode. Keying this on an ASCII a character yields the following in the
status bar:
<a> 97, Hex 61, Octal 141
This information can be useful, but it's worth it to extend it to include some other
relevant information, including the Unicode point and name of the character, its HTML entity
name (if applicable), and any digraph entry method . This
can be done by installing the characterize plugin by Tim Pope .
With this plugin installed, pressing ga over a yields a bit more
information:
<a> 97, \141, U+0061 LATIN SMALL LETTER A
This really shines however when inspecting characters that are available as HTML entities,
or as Vim digraphs, particularly commonly used characters like an EM DASH:
Note that ga shows you all the Unicode information for the character, along
with any methods to type it as a digraph, and an appropriate HTML entity if applicable.
If you work with multibyte characters a lot, whether for internationalization reasons or for
typographical correctness in web pages, this may be very useful to you.
You can tell a lot about a shell user by looking at their prompt. Most shell users
will use whatever the system's default prompt is for their entire career. Under many GNU/Linux
distributions, this prompt includes the username, the hostname, and the current working
directory, along with a $ sigil for regular users, and a # for
root .
tom@sanctum:~$
This format works well for most users, and it's so common that it's often used in tutorials
to represent the user's prompt in lieu of the single-character standard $ and
# . It shows up as the basis for many of the custom prompt setups you'll find
online.
Some users may have made the modest steps of perhaps adding some brackets around the prompt,
or adding the time or date:
[10:11][tom@sanctum:~]$
Still others make the prompt into a grand multi-line report of their shell's state, or
indeed their entire system, full of sound and fury and signifying way too much:
Then there are the BSD users and other minimalist contrarians who can't abide anything more
than a single character cluttering their screens:
$
Getting your prompt to work right isn't simply a cosmetic thing, however. If done right and
in a style consistent with how you work, it can provide valuable feedback on how the system is
reacting to what you're doing with it, and also provide you with visual cues that could save
you a lot of confusion -- or even prevent your making costly mistakes.
I'll be working in Bash. Many of these principles work well for Zsh as well, but Zsh users
might want to read Steve Losh's article on his prompt setup first to
get an idea of the syntactical differences.
Why is this important?
One of the primary differences between terminals and windowed applications is that there
tends to be much less emphasis on showing metadata about the running program and its
environment. For the most part, to get information about what's going on, you need to
request it with calls like pwd , whoami ,
readlink , env , jobs , and echo $? .
The habit of keeping metadata out of the terminal like this unless requested may appeal to a
sense of minimalism, but like a lot of things in the command line world, it's partly the olden
days holding us back. When mainframes and other dinosaurs roamed the earth, terminal screens
were small, and a long or complex prompt amounted to a waste of space and cycles (or even
paper). In our futuristic 64-bit world, where tiny CRTs are a thing of the past and we think
nothing of throwing gigabytes of RAM at a single process, this is much less of a problem.
Customising the prompt doesn't have many "best practices" to it like a lot of things in the
shell; there isn't really a right way to do it. Some users will insist it's valuable to have
the path to the terminal device before every prompt, which I think is crazy as I almost never
need that information, and when I do, I can get it with a call to tty . Others
will suggest that including the working directory makes the length of the prompt too variable
and distracting, whereas I would struggle to work without it. It's worth the effort to design a
prompt that reflects your working style, and includes the information that's consistently
important to you on the system.
So, don't feel like you're wasting time setting up your prompt to get it just right, and
don't be so readily impressed by people with gargantuan prompts in illegible rainbow colors
that they copied off some no-name wiki. If you use Bash a lot, you'll be staring at your prompt
for several hours a day. You may as well spend an hour or two to make it useful, or at least
easier on the eyes.
The basics
The primary Bash prompt is stored in the variable PS1 . Its main function is to
signal to the user that the shell is done with its latest foreground task, and is ready to
accept input. PS1 takes the form of a string that can contain escape
sequences for certain common prompt elements like usernames and hostnames, and which is
evaluated at printing time for escape sequences, variables, and command or function
calls within it.
You can inspect your current prompt definition with echo . If you're using
GNU/Linux, it will probably look similar to this:
tom@sanctum:~$ echo $PS1
\u@\h:\w\$
PS1 works like any other Bash variable; you can assign it a new value, append
to it, and apply substitutions to it. To add the text bash to the start of my
prompt, I could do this:
There are other prompts -- PS2 is used for "continued line" prompts, such as
when you start writing a for loop and continue another part of it on a new line,
or terminate your previous line with a backslash to denote the next line continues on from it.
By default this prompt is often a right angle bracket > :
$ for f in a b c; do
> do echo "$f"
> done
There are a couple more prompt strings which are much more rarely seen. PS3 is
used by the select structure in shell scripts; PS4 is used while
tracing output with set -x . Ramesh Natarajan breaks this down very well in his
article on the Bash prompt . Personally, I only ever modify PS1 , because I
see the other prompts so rarely that the defaults work fine for me.
As PS1 is a property of interactive shells, it makes the most sense to put its
definitions in $HOME/.bashrc on GNU/Linux or BSD systems. It's likely there's
already code in there doing just that. For Mac OS X, you'll likely need to put it into
$HOME/.bash_profile instead.
Escapes
Bash will perform some substitutions for you in the first pass of its evaluation of your
prompt string, replacing escape sequences with appropriate elements of information
that are often useful in prompts. Below are the escape sequences as taken from the Bash
man page:
\a an ASCII bell character (07)
\d the date in "Weekday Month Date" format (e.g., "Tue May 26")
\D{format}
the format is passed to strftime(3) and the result is inserted into
the prompt string; an empty format results in a locale-specific time
representation. The braces are required
\e an ASCII escape character (033)
\h the hostname up to the first `.'
\H the hostname
\j the number of jobs currently managed by the shell
\l the basename of the shell's terminal device name
\n newline
\r carriage return
\s the name of the shell, the basename of $0 (the portion following
the final slash)
\t the current time in 24-hour HH:MM:SS format
\T the current time in 12-hour HH:MM:SS format
\@ the current time in 12-hour am/pm format
\A the current time in 24-hour HH:MM format
\u the username of the current user
\v the version of bash (e.g., 2.00)
\V the release of bash, version + patch level (e.g., 2.00.0)
\w the current working directory, with $HOME abbreviated with a tilde
(uses the value of the PROMPT_DIRTRIM variable)
\W the basename of the current working directory, with $HOME
abbreviated with a tilde
\! the history number of this command
\# the command number of this command
\$ if the effective UID is 0, a #, otherwise a $
\nnn the character corresponding to the octal number nnn
\\ a backslash
\[ begin a sequence of non-printing characters, which could be used to
embed a terminal control sequence into the prompt
\] end a sequence of non-printing characters
As an example, the default PS1 definition on many GNU/Linux systems uses four
of these codes:
\u@\h:\w\$
The \! escape sequence, which expands to the history item number of the current
command, is worth a look in particular. Including this in your prompt allows you to quickly
refer to other commands you may have entered in your current session by history number with a
! prefix, without having to actually consult history :
$ PS1="(\!)\$"
(6705)$ echo "test"
test
(6706)$ !6705
echo "test"
test
Keep in mind that you can refer to history commands
relatively rather than by absolute number. The previous command can be referenced by using
!! or !-1 , and the one before that by !-2 , and so on,
provided that you have left the histexpand option on.
Also of particular interest are the delimiters \[ and \] . You can
use these to delimit sections of "non-printing characters", typically things like terminal
control characters to do things like moving the cursor around, starting to print in another
color, or changing properties of the terminal emulator such as the title of the window. Placing
these non-printing characters within these delimiters prevents the terminal from assuming an
actual character has been printed, and hence correctly manages things like the user deleting
characters on the command line.
Colors
There are two schools of thought on the use of color in prompts, very much a matter of
opinion:
Focus should be on the output of commands, not on the prompt, and using color in the
prompt makes it distracting, particularly when output from some programs may also be in
color.
The prompt standing out from actual program output is a good thing, and judicious use of
color conveys useful information rather than being purely decorative.
If you agree more with the first opinion than the second, you can probably just skip to the
next section of this article.
Printing text in color in terminals is done with escape sequences, prefixed with the
\e character as above. Within one escape sequence, the foreground, background, and
any styles for the characters that follow can be set.
For example, to include only your username in red text as your prompt, you might use the
following PS1 definition:
PS1='\[\e[31m\]\u\[\e[0m\]'
Broken down, the opening sequence works as follows:
\[ -- Open a series of non-printing characters, in this case, an escape
sequence.
\e -- An ASCII escape character, used to confer special meaning to the
characters that follow it, normally to control the terminal rather than to enter any
characters.
[31m -- Defines a display attribute, corresponding to foreground red, for
the text to follow; opened with a [ character and terminated with an
m .
\] -- Close the series of non-printing characters.
The terminating sequence is very similar, except it uses the 0 display
attribute to reset the text that follows back to the terminal defaults.
The valid display attributes for 16-color terminals are:
Style
0 -- Reset all attributes
1 -- Bright
2 -- Dim
4 -- Underscore
5 -- Blink
7 -- Reverse
8 -- Hidden
Foreground
30 -- Black
31 -- Red
32 -- Green
33 -- Yellow
34 -- Blue
35 -- Magenta
36 -- Cyan
37 -- White
Background
40 -- Black
41 -- Red
42 -- Green
43 -- Yellow
44 -- Blue
45 -- Magenta
46 -- Cyan
47 -- White
Note that blink may not work on a lot of terminals, often by design, as it tends to be
unduly distracting. It'll work on a linux console, though. Also keep in mind that
for a lot of terminal emulators, by default "bright" colors are printed in bold.
More than one of these display attributes can be applied in one hit by separating them with
semicolons. The below will give you underlined white text on a blue background, after first
resetting any existing attributes:
\[\e[0;4;37;44m\]
It's helpful to think of these awkward syntaxes in terms of opening and closing, rather like
HTML tags, so that you open before and then reset after all the attributes of a section of
styled text. This usually amounts to printing \[\e[0m\] after each such
passage.
These sequences are annoying to read and to type, so it helps to put commonly used styles
into variables:
This may be preferable if you use some esoteric terminal types, as it queries the
terminfo or termcap databases to generate the appropriate escapes for
your terminal.
The set of eight colors -- or sixteen, depending on how you look at it -- can be extended to 256
colors in most modern terminal emulators with a little extra setup. The escape sequences
are not very different, but their range is vastly increased to accommodate the larger
palette.
A useful application for prompt color can be a quick visual indication of the privileges
available to the current user. The following code changes the prompt to green text for a normal
user, red for root , and yellow for any other user attained via sudo
:
color_root=$(tput setaf 1)
color_user=$(tput setaf 2)
color_sudo=$(tput setaf 3)
color_reset=$(tput sgr0)
if (( EUID == 0 )); then
PS1="\\[$color_root\\]$PS1\\[$color_reset\\]"
elif [[ $SUDO_USER ]]; then
PS1="\\[$color_sudo\\]$PS1\\[$color_reset\\]"
else
PS1="\\[$color_user\\]$PS1\\[$color_reset\\]"
fi
Otherwise, you could simply use color to make different regions of your prompt more or less
visually prominent.
Variables
Provided the promptvars option is enabled, you can reference Bash variables
like $? to get the return value of the previous command in your prompt string.
Some people find this valuable to show error codes in the prompt when the previous command
given fails:
$ shopt -s promptvars
$ PS1='$? \$'
1 $ echo "test"
test
0 $ fail
-bash: fail: command not found
127 $
The usual environment variables like USER and HOME will work too,
though it's preferable to use the escape sequences above for those particular variables. Note
that it's important to quote the variable references as well, so that they're
evaluated at runtime, and not during the assignment itself.
Commands
If the information you want in your prompt isn't covered by any of the escape codes, you can
include the output of commands in your prompt as well, using command substitution with the syntax
$(command) :
This requires the promptvars option to be set, the same way variables in the
prompt do. Again, note that you need to use single quotes so that the command is run when the
prompt is being formed, and not immediately as part of the assignment.
This can include pipes to format the data with tools like awk or
cut , if you only need a certain part of the output:
Note that as a normal part of command substitution, trailing newlines are stripped from the
output of the command, so here the output of uptime appears on a single line.
A common usage of this pattern is showing metadata about the current directory, particularly
if it happens to be a version control repository or working copy; you can use this syntax with
functions to show the type of version control system, the current branch, and whether any
changes require committing. Working with Git, Mercurial, and Subversion most often, I include
the relevant logic as part of my prompt
function .
When appended to my PS1 string, $(prompt vcs) gives me prompts
that look like the following when I'm in directories running under the appropriate VCS. The
exclamation marks denote that there are uncommitted changes in the repositories.
In general, where this really shines is adding pieces to your prompt conditionally
, to make them collapsible. Certain sections of your prompt therefore only show up if they're
relevant. This snippet, for example, prints the number of jobs running in the background of the
current interactive shell in curly brackets, but only if the count is non-zero:
prompt_jobs() {
local jobc
while read -r _; do
((jobc++))
done < <(jobs -p)
if ((jobc > 0)); then
printf '{%d}' "$jobc"
fi
}
It's important to make sure that none of what your prompt does takes too long to run; an
unresponsive prompt can make your terminal sessions feel very clunky.
Note that you can also arrange to run a set of commands before the prompt is
evaluated and printed, using the PROMPT_COMMAND . This tends to be a good place to
put commands that don't actually print anything, but that do need to be run before or after
each command, such as operations working with history :
PROMPT_COMMAND='history -a'
Switching
If you have a very elaborate or perhaps even computationally expensive prompt, it may
occasionally be necessary to turn it off to revert to a simpler one. I like to handle this by
using functions, one of which sets up my usual prompt and is run by default, and another which
changes the prompt to the minimal $ or # character so often used in
terminal demonstrations. Something like the below works well:
You can then switch your prompt whenever you need to by typing prompt_on and
prompt_off .
This can also be very useful if you want to copy text from your terminal into documentation,
or into an IM or email message; it removes your distracting prompt from the text, where it
would otherwise almost certainly differ from that of the user following your instructions. This
is also occasionally helpful if your prompt does not work on a particular machine, or the
machine is suffering a very high load average that means your prompt is too slow to
load.
Further reading
Predefined prompt strings are all over the web, but the above will hopefully enable you to
dissect what they're actually doing more easily and design your own. To take a look at some
examples, the relevant page on the Arch Wiki is
a great start. Ramesh Natarajan over at The Geek Stuff has a great article with some examples
as well, with the curious theme of making your prompt as
well-equipped as Angelina Jolie .
Finally, please feel free to share your prompt setup in the comments (whether you're a Bash
user or not). It would be particularly welcome if you explain why certain sections of your
prompt are so useful to you for your particular work.
"... Update 2016: Recent Hacker News discussion has reminded me of my long-standing mistake in asserting that ed(1) is included in every Unix and Unix-like system's base installation. This is not even close to true–many others exclude it–and the claim has been removed, which I should have done years ago. ..."
"... Thanks to A. Pedro Cunha for a couple of fixes to show correct typical output. ..."
The classic ed
editor is a really good example of a sparse, minimal, standard Unix tool that does one thing, and
does it well. Because there are so many good screen-oriented editors for Unix, there's seldom
very much call for using ed , unless you're working on very old or very limited
hardware that won't run anything else.
However, if part of the reason you use vi is because you think it will always
be there (it may not be), then you should learn ed too. If your terminal is broken
and neither vi nor nano will work, or you break it some other way,
your choices may well be between cat and ed . Or even the grand
heresy of sed -i
Not a friendly editor
Even more than its uppity grandchild ex / vi , ed has
developed a reputation as terse and intimidating to newcomers. When you type ed at
the command line, nothing happens, and the only error message presented by default is
? . If you're reading this, it's likely your first and only experience with
ed went something like this:
$ ed
help
?
h
Invalid command suffix
?
?
^C
?
exit
?
quit
?
^Z
$ killall ed
$ vi
So, ed is not a terribly intuitive editor. However, it's not nearly as hard to
learn as it might seem, especially if you're a veteran vi user and thereby
comfortable with the ex command set. With a little practice, you can actually get
rather quick with it; there's an elegance to its almost brutal simplicity.
It's also very interesting to learn how ed works and how to use it, not just
because it might very well be useful for you one day, but because it occupies an important
position in the heritage of the sed stream editor, the ex line
editor, the vi visual editor, the grep tool, and many other
contexts.
Why is ed so terse?
When ed was developed, the usual method of accessing a Unix system was via a
teletype device, on which it wouldn't have been possible to use a screen-oriented editor like
vi . Similarly, modems were slow, and memory was precious; using abbreviated
commands and terse error messages made a lot of sense, because the user would otherwise be
wasting a lot of time waiting for the terminal to react to commands, and didn't have a whole
lot of memory to throw around for anything besides the buffer of text itself.
Of course, this is almost a non-issue for most Unix-like systems nowadays, so one of the
first things we'll do is make ed a little bit less terse and more
user-friendly.
Error messages
Start ed up the usual way:
$ ed
We'll start by deliberately doing something wrong. Type b and press Enter:
b
?
There's that tremendously unhelpful ? again. But if you press h ,
you can see what went wrong:
h
Unknown command
Of course, since it's the future now, we can spare the terminal cycles to have
ed print the error message for us every time. You can set this up by pressing
H :
H
b
?
Unknown command
That's a bit more useful, and should make things easier.
Quitting
You can quit ed with q . Go ahead and do that. If you had unsaved
changes in a buffer, you could type Q to quit unconditionally. Repeating yourself
works too:
q
?
Warning: buffer modified
q
Command prompt
Let's invoke ed again, but this time we'll use the -p option to
specify a command prompt :
$ ed -p\*
*
We'll use that from now on, which will make things clearer both for interpreting this
tutorial and for remembering whether we're in command mode, or entering text. It might even be
a good idea to make it into a function
:
$ ed() { command ed -p\* "$@" ; }
Basic text input
We'll start by adding a couple of lines of text to the new buffer. When you start
ed with no filename, it starts an empty buffer for you, much like vi
does.
Because there are no lines at all at present, press a to start adding some at
the editor's current position:
*a
Start typing a few lines.
Anything you want, really.
Just go right ahead.
When you're done, just type a period by itself.
.
That's added four new lines to the buffer, and left the editor on line 4. You can tell
that's the case because typing p for print, just by itself, prints the fourth
line:
*p
When you're done, just type a period by itself.
A little more useful is n (or pn in some versions), which will
show both the line number and the contents of the line:
*n
4 When you're done, just type a period by itself.
So just like in ex , the current line is the default for most
commands. You can make this explicit by referring to the current line as . :
*.n
4 When you're done, just type a period by itself.
You can move to a line just by typing its number, which will also print it as a side
effect:
*3
Just go right ahead.
*.n
3 Just go right ahead.
Pressing a like you did before will start inserting lines after the current
line:
*a
Entering another line.
.
*n
4 Entering another line.
Pressing i will allow you to insert lines before the current line:
*i
A line before the current line.
.
*n
4 A line before the current line.
You can replace a line with c :
*c
I decided I like this line better.
.
*n
4 I decided I like this line better.
You can delete lines with d :
*6d
And join two or more lines together with j :
*1,2j
You can prepend an actual line number to any of these commands to move to that line before
running the command on it:
*1c
Here's a replacement line.
.
*1n
1 Here's a replacement line.
For most of these commands, the last line to be changed will become the new current
line.
Ranges
You can select the entire buffer with 1,$ or , for short (
% works too):
*,p
Here's a replacement line.
Just go right ahead.
I decided I liked this line better.
Entering another line.
Or a limited range of specific lines:
*2,3p
Just go right ahead.
I decided I liked this line better.
These ranges can include a reference to the current line with . :
*2
Just go right ahead.
*.,4p
Just go right ahead.
I decided I liked this line better.
Entering another line.
They can also include relative line numbers, prefixed with + or
- :
*2
*-1,+1p
Here's a replacement line.
Just go right ahead.
I decided I liked this line better.
You can drop a mark on a line with k followed by a lowercase letter such as
a , and you're then able to refer to it in ranges as 'a :
*3ka
*'ap
I decided I liked this line better.
Moving and copying
Move a line or range of lines to after a target line with m :
*1,2m$
*,p
I decided I liked this line better.
Entering another line.
Here's a replacement line.
Just go right ahead.
Copy lines to after a target line with t :
*2t4
*,p
I decided I liked this line better.
Entering another line.
Here's a replacement line.
Just go right ahead.
Entering another line.
Regular expressions
You can select lines based on classic regular expressions with the g operator.
To print all lines matching the regular expression /re/ :
*g/re/p
Here's a replacement line.
(Hmm, where have I seen that command before?)
You can invert the match to work with lines that don't match the expression with
v :
*v/re/p
I decided I liked this line better.
Entering another line.
Just go right ahead.
Entering another line.
Just like numbered line ranges, ranges selected with regular expressions can have other
operations applied to them. To move every line containing the expression /re/ to
the bottom of the file:
*g/re/m$
*,p
I decided I liked this line better.
Entering another line.
Just go right ahead.
Entering another line.
Here's a replacement line.
Searching
You can move to the next line after the current one matching a regular expression with
/ . Again, this will print the line's contents as a side effect.
*/like
I decided I like this line better.
You can search backward with ? :
*?Here
Here's a replacement line.
Substituting
You can substitute for the first occurrence per line of an expression within a range of
lines with the s command:
*1s/i/j
I decjded I like this line better.
You can substitute for all the matches on each line by adding the /g
suffix:
*1s/i/j/g
*p
I decjded I ljke thjs ljne better.
Reading and writing
You can write the current buffer to a file with w , which will also print the
total number of bytes written:
*w ed.txt
129
Having done this once, you can omit the filename for the rest of the session:
*w
129
Like most ed commands, w can be prefixed with a range to write
only a subset of lines to the file. This would write lines 1 to 4 to the file
ed.txt :
*1,4w ed.txt
102
You can use W to append to a file, rather than replace it. This would
write lines 3 to 5 to the end of the file ed.txt :
*3,5W
71
You can read in the contents of another file after the current line (or any other line) with
r . Again, this will print the number of bytes read.
*r /etc/hosts
205
The output of a command can be included by prefixing it with ! :
*r !ps -e
5571
If you just want to load the contents of a file or the output of a command into the buffer,
replacing what's already there, use e , or E if you've got an
unmodified buffer and don't care about replacing it:
*E ed.txt
173
If you don't like seeing the byte counts each time, you can start ed with the
-s option for "quiet mode".
Familiar syntax
Almost all of the above command sets will actually be familiar to vi users who
know a little about ex , or Vimscript in Vim. It will also be familiar to those
who have used sed at least occasionally.
Once you get good with ed , it's possible you'll find yourself using it now and
then to make quick edits to files, even on systems where your favourite screen-based editor
will load promptly. You could even try using ex .
Update 2016: Recent Hacker News discussion has reminded me of my long-standing mistake
in asserting that ed(1) is included in every Unix and Unix-like system's base
installation. This is not even close to true–many others exclude it–and the claim
has been removed, which I should have done years ago.
Thanks to A. Pedro Cunha for a couple of fixes to show correct typical output.
Posted on Registers in Vim
are best thought of as scratch spaces for text, some of which are automatically filled by the
editor in response to certain actions. Learning how to use registers fluently has a lot of
subtle benefits, although it takes some getting used to because the syntax for using them is a
little awkward.
If you're reasonably fluent with Vim by now, it's likely you're already familiar with the
basic usage of the 26 named registers , corresponding to the letters of the alphabet. These are
commonly used for recording macros ; for example, to
record a series of keystrokes into register a , you might start recording with
qa , and finish with q ; your keystrokes could then be executed with
@a .
Similarly, we can store text from the buffer itself rather than commands in these registers,
by prepending "a to any command which uses a register, such as the c
, d , and y commands:
"ayy -- Read current line into register a .
"bP -- Paste contents of register b above current line.
"cc3w -- Change three words, putting the previous three words into register
c .
Like many things in Vim, there's a great deal more functionality to registers for those
willing to explore.
Note that here I'll be specifically ignoring the * , + , and
~ registers; that's another post about the generally unpleasant business of making
Vim play nice with system clipboards. Instead, I'll be focussing on stuff that only applies
within a Vim session. All of this is documented in :help registers
.
Capital registers
Yanking and deleting text into registers normally replaces the previous contents of
that register. In some cases it would be preferable to append to a register, for
example while cherry-picking different lines from the file to be pasted elsewhere. This can be
done by simply capitalizing the name of the register as it's referenced:
"ayy -- Replace the contents of register a with the
current line.
"Ayy -- Append the current line to register a .
This works for any context in which an alphabetical register can be used. Similarly, to
append to a macro already recorded in register a , we can start recording with
qA to add more keystrokes to it.
Viewing register contents
A good way to start getting a feel for how all the other registers work is to view a list of
them with their contents during an editing session with :registers . This will
show the contents of any register used in the editing session. It might look something like
this, a little inscrutable at first:
:registers
--- Registers ---
"" Note that much of it includes
"0 execut
"1 ^J^J
"2 16 Oct (2 days ago)^J^Jto Jeff, Alan ^JHi Jeff (cc Alan);^J^JPlease
"3 <?php^Jheader("Content-Type: text/plain; charset=utf-8");^J?>^J.^J
"4 ^J
"5 Business-+InternationalTrade-TelegraphicTransfers-ReceivingInternati
"6 ../^J
"7 diff = auto^J status = auto^J branch = auto^J interacti
"8 ^J[color]^J ui = auto^J diff = auto^J status = auto^J br
"9 ui = true^J
"a escrow
"b 03wdei^R=2012-^R"^M^[0j
"c a
"e dui{<80>kb^[^[
"g ^[gqqJgqqjkV>JgqqJV>^[Gkkkjohttp://tldp.org/LDP/abs/html/^[I[4]: ^[k
"h ^[^Wh:w^Mgg:w^M^L:w^Mjk/src^Mllhh
"j jjjkkkA Goo<80>kb<80>kb<80>kbThis one is good pio<80>kbped through a
"- Note that much of it includes
". OIt<80>kb<80>kb<80>kbIt might looks <80>kb<80>kb something like thi
": register
"% advanced-vim-registers.markdown
"/ Frij
The first column contains the name of the register, and the second its contents. The
contents of any of these registers can be pasted into the buffer with "ap , where
a is the name of any of them. Note that there are considerably more registers than
just the named alphabetical ones mentioned above.
Unnamed register
The unnamed register is special in that it's always written to in operations, no matter
whether you specified another register or not. Thus if you delete a line with dd ,
the line's contents are put into the unnamed register; if you delete it with "add
, the line's contents are put into both the unnamed register and into register
a .
If you need to explicitly reference the contents of this register, you can use
" , meaning you'd reference it by tapping " twice: "" .
One handy application for this is that you can yank text into the unnamed register and execute
it directly as a macro with @" .
Man, and you thought Perl looked like line noise.
Black hole register
Another simple register worth mentioning is the black hole register , referenced with
"_ . This register is special in that everything written to it is discarded. It's
the /dev/null of the Vim world; you can put your all into it, and it'll never give
anything back. A pretty toxic relationship.
This may not seem immediately useful, but it does come in handy when running an operation
that you don't want to clobber the existing contents of the unnamed register. For example, if
you deleted three lines into the unnamed register with 3dd with the intent of
pasting them elsewhere with p , but you wanted to delete another line before doing
so, you could do that with "_dd ; line gone, and no harm done.
Numbered
registers
The read-only registers 0 through 9 are your "historical record"
registers. The register 0 will always contain the most recently yanked text , but
never deleted text; this is handy for performing a yank operation, at least one delete
operation, and then pasting the text originally yanked with "0p .
The registers 1 through 9 are for deleted text , with
"1 referencing the most recently deleted text, "2 the text deleted
before that, and so on up to "9 .
The small delete register
This read-only register, referenced by "- , stores any text that you deleted or
changed that was less than one line in length, unless you specifically did so into some other
named register. So if you just deleted three characters with 3x , you'll find it
in here.
Last inserted text register
The read-only register ". contains the text that you last inserted. Don't make
the mistake of using this to repeat an insert operation, though; just tap . for
that after you leave insert mode, or have the foresight to prepend a number to your insert
operation; for example, 6i .
Filename registers
The read-only register "% contains the name of the current buffer's file.
Similarly, the "# register contains the name of the alternate buffer's
file.
Command registers
The read-only register ": contains the most recently executed :
command, such as :w or :help . This is likely only of interest to you
if you're wanting to paste your most recent command into your Vim buffer. For everything else,
such as repeating or editing previous commands, you will almost certainly want to use the
command
window .
Search registers
The read-only register / contains the most recent search pattern; this can be
handy for inserting the search pattern on the command line, by pressing Ctrl-R and
then / -- very useful for performing substitutions using the last search
pattern.
Expression register
Here's the black sheep of the bunch. The expression register = is used to treat
the results of arbitrary expressions in register context. What that means in actual real words
is that you can use it as a calculator, and the result is returned from the register.
Whenever the expression register is referenced, the cursor is put on the command line to
input an expression, such as 2+2 , which is ended with a carriage return.
This means in normal mode you can type "=2+2<Enter>p , and 4
will be placed after the cursor; in insert or command mode you can use Ctrl-R then
=2+2<Enter> for the same result. If you don't find this syntax as impossibly
awkward as I do, then this may well suit you for quick inline calculations personally, I'd drop
to a shell and bust out bc for this.
Posted on
February 1, 2012 by Tom
Ryder The autocompletion for filenames in Vim in command mode is very useful, but by default
it's a bit confusing for people accustomed to tab completion in Bash because it doesn't quite work
the same way. Pressing Tab will complete the filename to the first match, and subsequent presses
will not elicit any list of possible completions that might otherwise be expected; for that, by default
you need to press Ctrl+D rather than Tab. Tab then tab
Fortunately, this is easily changed by using Vim's wildmenu , in an appropriate mode.
Set the following options in your .vimrc :
set wildmenu
set wildmode=longest,list
You should now find that when you complete filenames after commands like :w and
:e , the paths expand in a similar manner to the way they do in the shell. If you'd
prefer to only press Tab once to get both the longest matching unique string and a list
of possible complete matches,
that's possible
to arrange in both Bash and Vim as well.
Ignoring file types
There are probably certain filetypes in your directories that you'll never want to edit with Vim.
There's hence no point in making them options for the autocompletion, and you can exclude them by
pattern to make searching for the right file a bit quicker. This is done using the wildignore
pattern. I use the following settings:
set wildignore+=*.a,*.o
set wildignore+=*.bmp,*.gif,*.ico,*.jpg,*.png
set wildignore+=.DS_Store,.git,.hg,.svn
set wildignore+=*~,*.swp,*.tmp
Compatibility
For the sake of keeping my .vimrcconsistent
and compatible on both older and newer machines, I like to wrap these options in a conditional
block checking that the wildmenu feature is actually available:
" Wildmenu
if has("wildmenu")
set wildignore+=*.a,*.o
set wildignore+=*.bmp,*.gif,*.ico,*.jpg,*.png
set wildignore+=.DS_Store,.git,.hg,.svn
set wildignore+=*~,*.swp,*.tmp
set wildmenu
set wildmode=longest,list
endif
Insert mode
You can also complete file paths and names in insert mode with Ctrl+X Ctrl+F. It can be handy
to map this to Tab if you don't use it for anything else:
Posted on
February 2, 2012 by Tom
Ryder Certain files on a UNIX-like system, such as /etc/passwd and /etc/sudoers
, are integral for managing login and authentication, and it's thus necessary to be very careful
while editing them using sudo not to accidentally leave them in a corrupted state, or
to allow others to edit them at the same time as you. In the worst case scenario it's possible to
lock yourself out of a system or out of root privileges in doing this, and things can only be fixed
via physical access to the server or someone who knows the actual root password, which you may not
necessarily know as a sudo user.
You should therefore never edit /etc/passwd , /etc/group ,
or /etc/sudoers by simply invoking them in your editor of choice. A set of simple utilities
exist to help you make these edits safely.
vipw and vigr
If you want to safely edit the /etc/passwd file, for which you'll need to have root
privileges, you should use the vipw tool. It doesn't require an argument.
# vipw
This will load a temporary copy of the file into your $EDITOR , and allow you to
make changes. If all is well after you save and quit, you'll see a message like:
You have modified /etc/passwd.
You may need to modify /etc/shadow for consistency.
Please use the command 'vipw -s' to do so.
If you've made changes which might require changing something in the /etc/shadow
file, you should follow these instructions too.
The command to edit groups, vigr , works in much the same way:
# vigr
visudo
The analogous tool for editing the /etc/sudoers file is visudo . This
file not only does the necessary lock and file corruption checking as vipw does, it
also does some basic checking of the syntax of the file after you save it.
# visudo
If the changes you make to this file work correctly, you'll simply be returned to your prompt.
However, if you've made some sort of edit that means sudo won't be able to correctly
parse the file, you'll get warned and prompted for an appropriate action:
visudo: >>> /etc/sudoers: syntax error near line 28 <<<
visudo: >>> /etc/sudoers: syntax error near line 29 <<<
visudo: >>> /etc/sudoers: syntax error near line 29 <<<
What now?
If you press ? here and then Enter, you'll get a list of the actions you can take:
Options are:
(e)dit sudoers file again
e(x)it without saving changes to sudoers file
(Q)uit and save changes to sudoers file (DANGER!)
You'll probably want the first one, to edit your changes again and make them work properly, but
you may want to hose them and start again via the second option. You should only choose the third
if you absolutely know what you're doing.
sudoedit
In general, you can edit root-owned files using sudoedit , or sudo -e
, which will operate on temporary copies of the file and overwrite the original if changes are detected:
$ sudo -e /etc/network/interfaces
This has the added bonus of preserving all of your environment variables for the editing session,
which may not be the case when invoking an editor and file via sudo . This turns out
to be handy for newer versions of sudo which do not preserve the user's $HOME
directory by default, meaning that configuration files for your editor, such as .vimrc
, might not be read.
Entering
search patterns and replacement strings in Vim can sometimes be a pain, particularly if the
search or replacement text is already available in a register or under the cursor. There are a
few ways to make working with search and replace in Vim quicker and less cumbersome for some
common operations, and thereby save a bit of error-prone typing. Insert contents of a
register
As in command mode or insert mode, you can insert the contents of any register by pressing
Ctrl+R and then the register key. For example, to directly insert the contents of
register a , you can type Ctrl+R and then a while typing
a search pattern or replacement string.
Reference contents of a register
Similarly, if you want to use the contents of a register in a pattern or replacement but
don't want to directly insert it, you can instead reference the contents of register
a with \=@a :
:s/search/\=@a/
Both of the above tips work for both the search and replacement patterns, and for special
registers like " (default unnamed register) and / (last searched
text) as well as the alphabetical ones.
Insert word under cursor
If you happen to be hovering over a word that you want to use as as a search or replacement
string, as a special case of the above you can do so by typing Ctrl+R and then
Ctrl+W for a normal word, or Ctrl+R and then Ctrl+A for
a space-delimited word.
Empty search string
You can use the previous search as a search pattern or replacement string by including it
from the special / register, in the same way as any other register above, by
inserting it with Ctrl+R and then / , or representing it with
\=@/ . There's a convenient shorthand for this however in just using an empty
search string:
:s//replacement/
This will replace all occurences of the previous search string with replacement
. It turns out to be a particularly convenient shorthand when searching for words by pressing
* or # .
"... Thanks to user bairui for suggesting a safer alternative for yanking macro lines from buffers, which I've changed. He's written a whole blog post replying to this one. It's a good read if you're interested in going in to even more depth about when to use macros in Vim. ..."
Vim's massive command set in
both normal and command mode makes the concept of a macro especially powerful. Most Vim users,
if they ever use macros at all, will perhaps quickly record an edit to one line, starting with
qq and finishing with q , executing with @q , and
otherwise never give the concept much thought.
For slightly more advanced Vim users, macros may be more frequently useful, but they perhaps
still believe that macros are a niche Vim function unto themselves, and not really open to the
deft manipulation of text that pretty much everything else in Vim is.
As is typical in Vim, the rabbit hole of functionality goes much deeper than most users will
ever plumb.
Vanilla Vim macros
Suppose I had a plaintext table loaded into a Vim buffer containing the name, subject matter
expertise, birth year, and nationality of a few well-known programmers:
Stallman Richard GNU 1953 USA
Wall Larry Perl 1954 USA
Moolenar Bram Vim 1961 Netherlands
Tridgell Andrew Samba 1967 Australia
Matsumoto Yukihiro Ruby 1965 Japan
Ritchie Dennis C 1941 USA
Thompson Ken Unix 1943 USA
Actually, that's kind of untidy. Let's start by formatting it a bit, by running it through
Unix's column tool.
:%!column -t
Stallman Richard GNU 1953 USA
Wall Larry Perl 1954 USA
Moolenar Bram Vim 1961 Netherlands
Tridgell Andrew Samba 1967 Australia
Matsumoto Yukihiro Ruby 1965 Japan
Ritchie Dennis C 1941 USA
Thompson Ken Unix 1943 USA
May as well sort it by surname too:
:%!sort -k1
Matsumoto Yukihiro Ruby 1965 Japan
Moolenar Bram Vim 1961 Netherlands
Ritchie Dennis C 1941 USA
Stallman Richard GNU 1953 USA
Thompson Ken Unix 1943 USA
Tridgell Andrew Samba 1967 Australia
Wall Larry Perl 1954 USA
That's better.
Now, suppose we've got the task of replacing the fourth column of this table with the
approximate age of the person, which we can get naturally enough by sutracting their birth year
from the current year. This is a little awkward to do in pure ex, so we'll record a macro for
doing it on one line.
Experimenting a bit, we find that the following works well:
03wdei^R=2012-^R"^M^[0j
Broken down, this does the following:
0 -- Move to the start of the line
3w -- Skip three words, in this case to the fourth column
de -- Delete to the end of the word
i -- Enter insert mode
^R= -- Insert the contents of the special = register, which
accepts an expression to evaluate
2012-^R"^M -- Enter the expression 2012-(birth year) and press Enter
(literal ^M), which completes the operation, and inserts the result
^[ -- Leave insert mode
0 -- Return to the start of the line
j -- Move down a line
So we record it into a macro a (to stand for "age", no other reason) as we fix
up the first line:
qa03wdei^R=2012-^R"^M^[0jq
Matsumoto Yukihiro Ruby 47 Japan
Moolenar Bram Vim 1961 Netherlands
Ritchie Dennis C 1941 USA
Stallman Richard GNU 1953 USA
Thompson Ken Unix 1943 USA
Tridgell Andrew Samba 1967 Australia
Wall Larry Perl 1954 USA
This now means that for each line, we can run the macro by just tapping @a a
few times:
Matsumoto Yukihiro Ruby 47 Japan
Moolenar Bram Vim 51 Netherlands
Ritchie Dennis C 71 USA
Stallman Richard GNU 59 USA
Thompson Ken Unix 69 USA
Tridgell Andrew Samba 45 Australia
Wall Larry Perl 58 USA
That's all pretty stock-standard macro stuff that you'll likely have learned in other
tutorials. The only thing that's slightly voodoo (and certainly not vi-compatible) is the
arithmetic done with the special = register. You can read about that in
:help @= , if you're curious.
Repeating Vim macros
As a first very simple hint, if you're running a macro several times, don't forget that you
can prepend a count to it; in our case, 6@a would have fixed up all the remaining
lines. To take advantage of this, it's good practice to compose your macros so that they make
sense when run multiple times; in the example above, note that the end of the macro is moving
down onto the next line, ready to run the macro again if appropriate.
Similarly, if you've already run a macro once, you can run the same one again by just
tapping the @ key twice, @@ . This repeats the last run macro. Again,
you can prepend a count to this, @a5@@ .
The true nature of Vim macros
The registers that hold macros are the same registers that you probably use more frequently
for operations like deleting, yanking, and pasting. Running a macro is simply instructing Vim
to take the contents of a register and execute them as keystrokes, as if you were actually
typing them. Thinking about macros this way has a couple of interesting consequences.
First of all, it means you needn't restrict yourself to the single-keystroke vi commands for
Vim when you compose macros. You can include ex commands as well, for example to run a
substitution during a macro:
qb:s/foo/bar/g^Mq
@b
Secondly, and more interestingly, all of the operations that you can apply to registers in
general work with what we normally call macros, with the old standards, delete, yank, and
paste. You can test this with the example macro demonstrated above, by typing "ap
, which will dump the raw text straight into the buffer. Also like other registers, it'll show
up in the output of the :registers command.
All this means is that like everything else in Vim, macros are just text , and all
of Vim's clever tools can be used to work with them.
Editing Vim macros in a buffer
If you've used macros even a little bit you'll be very familiar with how frustrating they
are to record. For some reason, as soon as you press qa to start recording a macro
into register a , your normal fluency with Vim commands goes out the window and
you keep making mistakes that will make the macro unsuitable to apply.
So, don't compose macros on the fly. Just stop doing it. I recommend that if a macro is more
than three keystrokes, you should compose it directly in a scratch Vim buffer so that you can
test it iteratively.
Here's an example using the macro above; suppose I realise partway through writing it that I
made a mistake in typing 2011 instead of 2012. I finish recording the rest of the macro anyway,
and dump the broken keystrokes into a new scratch buffer:
:enew
"ap
This gives me the contents of the macro in plain text in the buffer:
qa03wdei^R=2011-^R"^M^[0jq
So now all I have to do is change that bad year to 2012, and then yank the whole thing back
into register a :
^"ay$
Now I can test it directly with @a on the appropriate file, and if it's still
wrong, I just jump back to my scratch buffer and keep fixing it up until it works.
One potential snag here is that you have to enter keystrokes like Ctrl+R as literal
characters, but once you know you can enter any keystroke in Vim literally in insert or command
mode by prefixing it with Ctrl+V, that isn't really a problem. So to enter a literal Ctrl+R in
insert mode, you type Ctrl+V, then Ctrl+R.
Running a Vim macro on a set of lines
It's occasionally handy to be able to run a macro that you've got ready on a specific subset
of lines of the file, or perhaps just for every line. Fortunately, there's a way to do this,
too.
Using the :normal command, you're able to run macros from the ex command
line:
:normal @a
All it takes is prefixing this with any sort of range definition to allow you to run
a macro on any set of lines that you're able to define.
Run the macro on each line of the whole buffer:
:% normal @a
Between lines 10 and 20:
:10,20 normal @a
On the lines in the current visual selection:
:'<,'> normal @a
On the lines containing the pattern vim:
:g/vim/ normal @a
When you get confident using this, :norm is a nice abbreviation to
use.
Moving a Vim macro into a function
For really useful macros of your own devising, it's occasionally handy to put it into a
function for use in scripts or keystroke mappings. Here again the :normal command
comes in handy.
Suppose I wanted to keep the age calculation macro defined above for later use on
spreadsheets of this kind. I'd start by dumping it into a new buffer:
:enew
"ap
The macro appears as raw text:
03wdei^R=2012-^R"^M^[0j
I prefix it with a :normal call, and wrap a function definition around it:
function! CalculateAge()
normal 03wdei^R=2012-^R"^M^[0j
endfunction
Then all I need to do is include that in a file that gets loaded during Vim's startup,
possibly just .vimrc . I can call it directly from ex:
:call CalculateAge()
But given that I wanted it to be a quick-access macro, maybe it's better to bind it to
\a , or whatever your chosen <leader> character is:
nnoremap <leader>a :call CalculateAge()<CR>
Saving a Vim macro
If you want to have a macro always available to you, that is, always loaded into the
appropriate register at startup, that can be done in your .vimrc file with a call
to let to fill the register with the literal characters required:
let @a='03wdei^R=2012-^R"^M^[0j'
Appending extra keystrokes to a Vim macro
If you just want to tack extra keystrokes onto an existing macro and don't care to edit it
in a Vim buffer, you can do that by recording into it with its capital letter equivalent. So,
if you wanted to add more keystrokes into the register b , start recording with
qB , and finish with the usual q .
Recursive Vim macros
If you're crazy enough to need this, and I never have, there's an excellent Vim Tip for it. But
personally, I think if you need recursion in your text processing then it's time to bust out a
real programming language and not Vimscript
to solve your problem.
If the issue for which you think you need recursion is running a macro on every line of a
buffer with an arbitrary number of lines, then you don't need recursion; just record a one-line
version of the macro and call it with :% normal @a to run it on every
line.
Vim macro gotchas
Here are a few gotchas which will save you some frustration if you know about them ahead of
time:
When you have a hammer, everything starts to look like a nail. Don't try to solve
problems with macros when there are better solutions in the ex command set, or available in
external programs. See the Vim koans page for a couple of
examples.
You need to insert keystrokes like Enter as literal Ctrl+M, so that they look like
^M . The convenience abbreviations in mappings, like <CR> ,
simply don't work. You're likely to find yourself chording Ctrl+V a lot.
Macros tend to stop, sometimes for apparently no reason and with no warning messages, as
soon as they hit some sort of error. One particularly annoying instance of this is when
you're performing several substitutions in a macro, because if it doesn't find any instances
of a pattern it will throw an error and stop executing. You can prevent this by adding the
e flag to the substitution call:
:s/foo/bar/e
Thanks to user bairui for suggesting a safer alternative for yanking macro lines from
buffers, which I've changed. He's written a whole
blog post replying to this one. It's a good read if you're interested in going in to even
more depth about when to use macros in Vim. Posted in Vim Tagged advanced , copy , functions , keep , macros , normal , paste , preserve , registers , vimrc , yank
If you can, it's a good idea to set up your .vimrc file using
conditionals so that it's compatible on all of the systems with which you need to work.
Using one .vimrc file enables you to include it as part of a centralized set of
dotfiles that you can keep under version control
.
However, if on a particular machine there's a special case which means you need to load some
Vim directives for that machine, you can achieve this by way of a local Vim file kept in
.vimrc.local , only on one particular machine, and detecting its existence before
attempting to load it in your master .vimrc file with the following stanza:
if filereadable(glob("~/.vimrc.local"))
source ~/.vimrc.local
endif
As an example, on one of the nameservers that I manage, I wanted to make sure that the
correct filetype was loaded when editing zone files ending in .nz or
.au for New Zealand and Australian domains. The following line in
.vimrc.local did the trick:
autocmd BufNewFile,BufRead *.au,*.nz set filetype=bindzone
If the .vimrc.local file doesn't exist on any particular machine, Vim will
simply not attempt to load it on startup.
Besides machine-specific code, this kind of setup may be advisable if you keep secret or
potentially sensitive information in your .vimrc file that you wouldn't want
published to a public version control tracker like GitHub, such as API keys, usernames, machine
hostnames, or network paths.
Using your .vimrc file on many machines with different versions and
feature sets for Vim is generally not too much of a problem if you apply a little care in
making a gracefully degrading
.vimrc . In most cases, using the output of vim --version and
checking the help files will tell you what features to check in order to determine which parts
of your .vimrc configuration to load, and which to ignore.
There's one particular feature that's less obvious, though, and that's eval .
Vim's help describes it like this in :help +eval :
N *+eval* expression evaluation |eval.txt|
The eval.txt document, in turn, describes the syntax for various features
fundamental to Vimscript, including variables, functions, lists, and dictionaries.
All this makes eval perhaps the most central feature of Vim. Without it, Vim
doesn't have much of its programmable nature, and remains not much more than classic
vi . If your particular build of Vim doesn't include it, then Vimscript
essentially does not work as a programming language, and elementary calls like
function and let will throw errors:
E319: Sorry, the command is not available in this version: function
E319: Sorry, the command is not available in this version: let
If you're getting this kind of error, you're probably using a very stripped-down version of
Vim that doesn't include eval . If you just want to prevent the error by ignoring
a block of code if the feature is unavailable, you can do this with has() :
if has("eval")
...
endif
Vim will still be perfectly functional as a vi -style editor without
+eval , but if you're going to need any Vimscript at all, you should recompile Vim
with a --with-features value for the ./configure line that does
include it, such as normal , big , or huge , or install
a more fully-featured packaged version. For example, on Debian-like systems, the
vim-tiny package that is included in the netinst system does not
include eval , but the vim and vim-runtime packages
do.
Inspecting Vim's source, in particular the ex_docmd.c file, gives some
indication of how fundamental this feature is, applying the C function ex_ni which
simply prints the "not available" error shown above to a large number of control structures and
statements if the FEAT_EVAL constant is not defined:
Vim isn't the best tool for
every task, and there's no reason you shouldn't stick to your GUI IDE if you know it like the
back of your hand and are highly productive in it. The very basic best practices for text
editing in general apply just as well to more familiar editing interfaces as they do to Vim, so
nobody should be telling you that Vim is right for everyone and everything and that you're
wrong not to use it.
However, because Vim and vi -like editors in general have a lot of trouble
shaking off the connotations of their serverside, terminal-only, mouseless past, there are a
few persistent objections to even trying Vim that seem to keep cropping up. If you're
someone curious about Vim but you heard it was useless for any of the following reasons, or if
you're an experienced user looking to convince a hesitant neophyte to try Vim, the following
list might clear a few things up.
Vim takes too long to learn
If you want analogues to all of the features in your IDE, that would likely take some time,
just as it would in any other new editor. However, if all you need to start is to be able to
enter text, move around, and load and save files, you just need to know:
i to enter insert mode, Esc to leave it
Arrow keys to move around in both modes
:e <filename> to load a document
:w <filename> to save a document
:q to quit, :q! to ignore unsaved changes
To do pretty much everything Windows Notepad would let you do, on top of that you'd only
need to learn:
dd to cut a line
yy to copy a line
p to paste a line
/<pattern> to search for text
n to go to the next result
:s/pattern/replacement to replace text
From that point, you only get faster as you learn how to do new things. So saying that Vim
takes weeks to learn is a bit disingenuous when the essentials can easily be mastered with a
few minutes' practice.
Granted, the arrow keys are a bit of an anti-pattern , but you can worry
about that later.
Vim has no GUI
Vim has a GUI
version called Gvim for both Windows and Unix. For Mac OS X, the MacVim port is preferred. For experienced users the
GUI's only real advantage over the terminal version is a wider color palette, but it has a
toolbar and other GUI elements which some new users may find useful.
Vim doesn't have
spell checking
Vim allows spell
checking with system dictionaries, using :set spell and :set
spelllang . Misspelt and unknown words are highlighted appropriately.
Vim doesn't
have syntax highlighting
Vim has support for syntax highlighting that can be turned
on with :syntax enable , for a very wide variety of programming languages, markup
languages, and configuration file syntaxes.
Vim only allows eight colours
This is a limitation of terminal emulators rather than of Vim itself, but most modern GUI
terminal emulators allow 256 colours anyway with a little
extra setup. The GUI version, Gvim, has full color support with the familiar
rrggbb color definitions.
Vim doesn't have class/function folding
Vim does in fact have support
for folding , based on both code structure and manually defined boundaries. See :help
folding for details.
Vim doesn't have autocompletion
Vim allows basic completion using words already in the current buffer, and also more
advanced omnicompletion
using language dictionaries for constants, variables, classes, and functions.
Vim doesn't
have a file browser
Vim has had the Netrw plugin bundled for some time,
which provides a pretty capable filesystem browser.
Vim can't do network editing
Again, the bundled Netrw plugin handles this. Editing files over FTP and SCP links is pretty
transparent. You can open a file on a remote server by entering the following, which will
prompt for your username and password:
:e ftp://ftp.example.com/index.html
When you're done editing, you just enter :w to save the file, and it's
automatically uploaded for you. You can record your FTP credentials in a .netrc
file to save having to type in usernames and passwords all the time. URIs with
scp:// work the same way; with a good public key infrastructure
set up, you can use Vim quite freely as a network-transparent editor.
Vim doesn't have
tabs or windows
The model Vim uses for tabs and windows is rather
different from most GUI editors, but both are supported and have been for some time.
Vim
has too many modes
It has three major modes: normal mode, insert mode, and command mode. There's a fourth
that's Vim-specific, called visual mode, for selecting text.
Most editors are modal in at least some respect; when you bring up a dialog box, or enter a
prefix key to another command, you're effectively changing modes. The only real difference is
that context shifts in Vim are at first less obvious; the screen doesn't look too different
between normal, insert, and command mode.
The showmode option helps to distinguish between insert and normal mode, a
common frustration for beginners. This gets easier when you get into the habit of staying out
of insert mode when not actually entering text.
Vim doesn't work with the mouse
Vim works fine with the mouse ,
in both Gvim and xterm -like terminal emulators, if you really want it. You can
change the position of the cursor, scroll through the document, and select text as normal.
Setting the below generally does the trick:
:set mouse=a
However, even a little experience in Vim may show you that you don't need the mouse as much
as you think. Careful use of the keyboard allows much more speed and precision, and it's quite
easy to run a complex editing session without even moving from the keyboard's "home row", let
alone all the way over to the mouse.
Vim doesn't do Unicode
Vim supports Unicode encodings with the encoding option. It's likely you'll
only need to put the below in your .vimrc file and then never really think about encoding in your editor
again:
:set encoding=utf-8
Vim isn't being developed or maintained
The original author of Vim, and its current maintainer and release manager, is Bram Moolenaar . At the time of
writing, he is working for Google, and is paid to spend some of his time developing Vim. The
development mailing list for Vim is very active, and patches are submitted and applied to the
publically accessible Mercurial repository on a regular basis. Vim is not a dead
project.
Vim is closed source
Vim isn't proprietary or closed source, and never has been. It uses its own GPL-compatible
license called the Vim license .
The original vi used to be proprietary because Bill Joy based the code on the
classic UNIX
text editor ed , but its source code has now been released under a BSD-style license.
Like any highly interactive application, Vim has a few annoyances even for
experienced users. Most of these consist of the editor doing something unexpected, particularly
with motions or the behavior of regular expressions and registers. This is often due to
vi and Vim being such venerable editors; their defaults sometimes make less sense
decades after their creation.
Fortunately, Vim being the configurable editor that it is, many of the more common
annoyances can be easily worked around. Bear in mind that not all of these are necessarily
problems; if you actually prefer the way something behaves, you should stick with
it.
Cursor jumps around while joining lines
If you want to keep the cursor in place when you join lines with J , you can do
this, dropping a mark before the operation to which you return afterwards:
nnoremap J mzJ`z
Jumping lands on top or bottom of screen
If you'd like to center the window automatically around the cursor after jumping to a
location with motions like n (next search pattern occurrence) or }
(end of next paragraph), you can arrange that by remapping to add a zz after the
motion:
nnoremap n nzz
nnoremap } }zz
If you don't need the jump to land you in the exact middle of the screen, but just don't
want it to land right at the edge, you could also use scrolloff :
set scrolloff=10
Note that this also starts scrolling the window with single-line movements like
j and k at this boundary, too, which you may not want.
Skipping
lines when wrap is set
By default, the j and k keys don't move by row ; they
move by line . This means that if you have the wrap option set, you might
skip across several rows to reach the same point in an adjacent line.
This can be frustrating if you prefer the more intuitive behavior of moving up to the
character immediately above the current one. If you don't like this behavior, you can fix it by
mapping j to gj , and k to gk , which moves
by rows rather than lines:
nnoremap j gj
nnoremap k gk
If you think you might need the default behavior at some point, you might want to include
reverse mappings so you can move linewise with gj and gk :
nnoremap gj j
nnoremap gk k
Wrapping breaks words
By default, setting wrap displays lines by breaking words if necessary. You can
force it to preserve words instead by only breaking at certain characters:
set linebreak
You can define the characters at which Vim should be allowed to break lines with the
breakat option. By default this includes spaces and tabs.
Backup files are a
nuisance
If you're developing with a version control system, you might find the in-place backups Vim
keeps for saved files with the ~ suffix more annoying than useful. You can turn
them off completely with nobackup :
set nobackup
Alternatively, you can set a single directory for them to keep them out of the way with
backupdir :
set backupdir=~/.vim/backup
Swap files are a nuisance
Swap files can be similarly annoying, and unnecessary on systems with a lot of memory. If
you don't need them, you can turn them off completely:
set noswapfile
If you do find the swap files useful but want to prevent them cluttering your current
directory, you can set a directory for them with directory :
set directory=~/.vim/swap
Accidentally hitting unwanted keys in normal mode
Some of the keys in normal mode bring up functions that aren't terribly useful to a lot of
people, and tend to accidentally get hit when Caps Lock is on, or when aiming for another key.
Common nuisance keys are:
F1 for help; :help is generally more useful for the experienced
user
Q to start ex mode; annoying when you intended to start
recording a macro with q
K to bring up a man page for the word under the cursor;
annoying when you're not writing in C or shell script, and there isn't a sensible choice of
keywordprg for your chosen language
The simplest way to deal with these is to remap them to <nop> so that
they don't do anything:
nnoremap <F1> <nop>
nnoremap Q <nop>
nnoremap K <nop>
Startup message is irritating
If you don't like the startup message that appears when you open Vim without a filename, you
can remove it by adding the I flag to shortmess :
set shortmess+=I
Can't backspace past start of operation
If you're in insert mode, by default you can't use backspace to delete text past the start
of the insert operation; that is, you can't backspace over where you first pressed insert. This
is old vi behavior, and if you don't like it, you can make backspace work
everywhere instead:
set backspace=indent,eol,start
Flashing screen is annoying
If you don't require the error feedback, you can turn off the flashing screen for the
"visual bell":
set visualbell t_vb=
Don't know what mode I'm in
If you lose track of the current mode, you can get a convenient --INSERT--
indicator at the bottom of the screen with:
set showmode
If you're having this problem a lot, however, you might want to take stock of how much time
you're spending in insert mode when you're not actively typing; it's good Vim practice to stay
out of it otherwise, even when you stop to think.
Keep making typos of common
commands
If you're fat-fingering :wq and similar commands a lot due to a sticky shift
key, take a look at the Vim command typos fix. Also, don't
forget about ZZ and ZQ as quicker alternatives to :wq
and :q! .
Don't want case sensitive patterns
If you don't care for case-sensitive searches and substitutions, you can turn it off
completely:
set ignorecase
You might find the slightly cleverer behavior of smartcase is better, though.
This option only applies case sensitivity if at least one of the letters in the pattern is
uppercase; otherwise, case is ignored.
set smartcase
Doesn't replace all occurrences
The default behavior for the substitute operation,
:s/pattern/replacement/ , is to replace only the first occurrence of the pattern.
To make it replace all occurrences on the appropriate lines, you add the
g suffix. If you find that you never need to substitute for only the first
occurrence of a pattern in a line, you can add that flag to the patterns by default:
set gdefault
If you do happen to need to replace only the first occurrence one day, you can get the
default behavior back by adding the g suffix to your pattern; its meaning
is reversed by this option.
Can't move into blank space in visual block mode
If you need to define a block in visual block mode with bounds outside the actual text (that
is, past the end of lines), you can allow this with:
set virtualedit=block
This will let you move around the screen freely while in visual block mode to define your
selections. As an example, this can make selecting the contents of the last column in a
formatted table much easier.
Filename completion on command line is confusing
If you're used to the behavior of shell autocomplete functions for completing filenames, you
can emulate it in Vim's command mode:
set wildmode=longest,list
With this set, the first Tab press (or whatever your wildchar is set to) will
expand a filename or command in command mode to the longest common string it can, and a second
press will display a list of all possible completions above the command line.
Yanking
lines is inconsistent
D deletes from the cursor to the end of the line; C changes from
the cursor to the end of the line. For some reason, however, Y yanks the entire
line, both before and after the cursor. If this inconsistency bothers you, you can fix it with
a remapping:
nnoremap Y y$
New splits appear in unintuitive places
If your language of choice is read from left to right, you may find it annoying that by
default Vim places new vertical splits to the left of the current pane, and horizontal
splits above the current pane. You can fix both:
set splitbelow
set splitright
Caps Lock sends Vim crazy
Caps Lock in normal mode makes Vim go haywire. This isn't really Vim's fault; Caps Lock is
generally a pretty useless key. It's often useful for Vim users to remap it , so that it sends the same signal as a
more useful key; Control and Escape are common choices. You might even find this reduces strain
on your hands.
Several of these fixes were inspired by Steve Losh's .vimrc file . Thanks also
to commenters Alpha Chen and Rob Hoelz for suggestions.
A good sign of a
philosophically sound interactive Unix tool is the facilities it offers for interacting with
the filesystem and the shell: specifically, how easily can you run file operations and/or shell
commands with reference to data within the tool? The more straightforward this is, the more
likely the tool will fit neatly into a terminal-driven Unix workflow.
If all else fails, you could always suspend the task with Ctrl+Z to drop to a shell, but
it's helpful if the tool shows more deference to the shell than that; it means you can use and
(even more importantly) write tools to manipulate the data in the program in whatever
languages you choose, rather than being forced to use any kind of heretical internal scripting
language, or worse, an over-engineered API.
vi is a good example of a tool that interacts openly and easily with the Unix
shell, allowing you to pass open buffers as streams of text transparently to classic filter and
text processing tools. In the case of Vim, it's particularly useful to get to know these,
because in many cases they allow you to avoid painful Vimscript, and to do things your way,
without having to learn an ad-hoc language or to rely on plugins. This was touched on briefly
in the "Editing" article of the
Unix as IDE
series.
Choosing your shell
By default, vi will use the value of your SHELL environment
variable as the shell in which your commands will be run. In most cases, this is probably what
you want, but it might pay to check before you start:
:set shell?
If you're using Bash, and this prints /bin/bash , you're good to go, and you'll
be able to use Bash-specific features or builtins such as [[ comfortably in your
command lines if you wish.
Running commands
You can run a shell command from vi with the !ex
command. This is inherited from the same behaviour in ed . A good example would be
to read a manual page in the same terminal window without exiting or suspending vi
:
:!man grep
Or to build your project:
:!make
You'll find that exclamation point prefix ! shows up in the context of running
external commands pretty consistently in vi .
You will probably need to press Enter afterwards to return to vi . This is to
allow you to read any output remaining on your screen.
Of course, that's not the only way to do it; you may prefer to drop to a forked shell with
:sh , or suspend vi with ^Z to get back to the original
shell, resuming it later with fg .
You can refer to the current buffer's filename in the command with % , but be
aware that this may cause escaping problems for files with special characters in their
names:
:!gcc % -o foo
If you want a literal % , you will need to escape it with a backslash:
:!grep \% .vimrc
The same applies for the # character, for the alternate buffer .
:!gcc # -o bar
:!grep \# .vimrc
And for the ! character, which expands to the previous command:
:!echo !
:!echo \!
You can try to work around special characters for these expansions by single-quoting
them:
:!gcc '%' -o foo
:!gcc '#' -o bar
But that's still imperfect for files with apostrophes in their names. In Vim (but not
vi ) you can do this:
Also inherited from ed is reading the output of commands into a buffer, which
is done by giving a command starting with ! as the argument to :r
:
:r !grep vim .vimrc
This will insert the output of the command after the current line position in the
buffer; it works in the same way as reading in a file directly.
You can add a line number prefix to :r to place the output after that line
number:
:5r !grep vim .vimrc
To put the output at the very start of the file, a line number of 0 works:
:0r !grep vim .vimrc
And for the very end of the file, you'd use $ :
:$r !grep vim .vimrc
Note that redirections work fine, too, if you want to prevent stderr from being
written to your buffer in the case of errors:
:$r !grep vim .vimrc 2>>vim_errorlog
Writing buffer text into a command
To run a command with standard input coming from text in your buffer, but without
deleting it or writing the output back into your buffer, you can provide a !
command as an argument to :w . Again, this behaviour is inherited from
ed .
By default, the whole buffer is written to the command; you might initially expect that only
the current line would be written, but this makes sense if you consider the usual behaviour of
w when writing directly to a file.
Given a file with a first column full of numbers:
304 Donald Trump
227 Hillary Clinton
3 Colin Powell
1 Spotted Eagle
1 Ron Paul
1 John Kasich
1 Bernie Sanders
We could calculate and view (but not save) the sum of the first column with
awk(1) , to see the expected value of 538 printed to the terminal:
:w !awk '{sum+=$1}END{print sum}'
We could limit the operation to the faithless electoral votes by specifying a line
range:
:3,$w !awk '{sum+=$1}END{print sum}'
You can also give a range of just . , if you only want to write out the current
line.
In Vim, if you're using visual mode, pressing : while you have some text
selected will automatically add the '<,'> range marks for you, and you can
write out the rest of the command:
:'<,'>w !grep Bernie
Note that this writes every line of your selection to the command, not merely the
characters you have selected. It's more intuitive to use visual line mode (Shift+V) if you take
this approach.
Filtering text
If you want to replace text in your buffer by filtering it through a command, you
can do this by providing a range to the ! command:
:1,2!tr '[:lower:]' '[:upper:]'
This example would capitalise the letters in the first two lines of the buffer, passing them
as input to the command and replacing them with the command's output.
304 DONALD TRUMP
227 HILLARY CLINTON
3 Colin Powell
1 Spotted Eagle
1 Ron Paul
1 John Kasich
1 Bernie Sanders
Note that the number of lines passed as input need not match the number of lines of output.
The length of the buffer can change. Note also that by default any stderr is
included; you may want to redirect that away.
You can specify the entire file for such a filter with % :
:%!tr '[:lower:]' '[:upper:]'
As before, the current line must be explicitly specified with . if you want to
use only that as input, otherwise you'll just be running the command with no buffer interaction
at all, per the first heading of this article:
:.!tr '[:lower:]' '[:upper:]'
You can also use ! as a motion rather than an ex command
on a range of lines, by pressing ! in normal mode and then a motion (
w , 3w , } , etc) to select all the lines you want to
pass through the filter. Doubling it ( !! ) filters the current line, in a similar
way to the yy and dd shortcuts, and you can provide a numeric prefix
(e.g. 3!! ) to specify a number of lines from the current line.
This is an example of a general approach that will work with any POSIX-compliant version of
vi . In Vim, you have the gU command available to coerce text to
uppercase, but this is not available in vanilla vi ; the best you have is the
tilde command ~ to toggle the case of the character under the cursor.
tr(1) , however, is specified by POSIX–including the locale-aware
transformation–so you are much more likely to find it works on any modern Unix
system.
If you end up needing such a command during editing a lot, you could make a generic command
for your private
bindir , say named upp for uppercase, that forces all of its standard input to
uppercase:
#!/bin/sh
tr '[:lower:]' '[:upper:]'
Once saved somewhere in $PATH and made executable, this would allow you simply
to write the following to apply the filter to the entire buffer:
:%!upp
The main takeaway from this is that the scripts you use with your editor don't have to be in
shell. You might prefer Awk :
Incidentally, this "filtering" feature is where vi 's heritage from
ed ends as far as external commands are concerned. In POSIX ed ,
there isn't a way to filter buffer text through a command in one hit. It's not too hard to
emulate it with a temporary file, though, using all the syntax learned above:
Being able to
search by regular expression is a pretty fundamental thing in a text editor. Vim takes it to
the next level by making entering a search into a motion all on its own, and even a
few weeks' Vim experience and you'll probably catch yourself using the search to navigate your
buffers.
One of the things I most commonly see recommended in threads and discussions about
useful
Vim features includes turning on two kinds of search highlighting: first, highlighting the
search result on which you'll land as you type it, and secondly, once you've pressed
Enter to run your search, highlighting all of the matches. You turn these
on like this:
:set incsearch
:set hlsearch
This ends up being great for editing code in particular, because if you search for variable
or function names, you can see at a glance where they're declared, defined, or used in your
code. Couple that with the quick forward and backward search that you can do with the
* and # keys, and you have a very convenient way to flick through
successive uses of an identifier.
The only snag, really, is that it doesn't turn itself off, and it gets visually distracting
when you've moved on from whatever task prompted the search, and because you might search to
move around, you don't always actually want the highlighting to stay there. Text editors
following a Windows model would probably clear away the highlighting as soon as you close the
search box, or insert some text. This isn't the case with Vim, which can be good or bad, but
most people I've spoken to about this feature seem to find it annoying.
Bram Moolenar, the author of Vim, addressed this very topic in a Google Tech Talk he gave
about effective text
editing . You can turn off the highlighting temporarily by typing:
:nohlsearch
This is different from :set nohlsearch in that it doesn't permanently
disable the highlighting. It'll turn it on next time you search. I find this is kind of a pain
to type, so I alias it to Ctrl+L in my .vimrc file, so that in addition to its
default behaviour of clearing the screen it clears the search highlighting as well:
nnoremap <C-l> :nohlsearch<CR><C-l>
Additionally, I like to set leader keys to quickly turn the highlighting option on and off
completely if for some particular project it's just thoroughly unhelpful. In this example,
typing \i and \h will toggle the incsearch and
hlsearch settings on and off, respectively. I'm assuming you're using the
backslash key as your <leader> here.
Finally, I find that while I'm in insert mode, I usually don't want to see the highlighting,
so I define events to turn the highlighting off temporarily in the current buffer while I'm
inserting text:
I find these shortcuts make the search highlighting behaviour much less annoying.
Interestingly, according to Vim's help, you can't simply add an event hook to run
:nohlsearch when you enter Insert mode (from :help nohlsearch ):
This command doesn't work in an autocommand, because the highlighting state is saved and
restored when executing autocommands. Same thing for when invoking a user function.
You can work around this by setting the search pattern to empty instead, as suggested by
this Stack Overflow answer ,
but I don't really like doing that because I often like to recurse through more search results
with n and N after leaving insert mode.
Posted on If you've moved to
Vim from an editor like Notepad++ or TextMate, you'll be used to working with the idea of tabs
in a text editor in a certain way. Specifically, a tab represents an open file; while the tab's
there, you've got an open file, as soon as you close it, it goes away. This one-to-one
correspondence is pretty straightforward and is analogous to using tabs in a web browser; while
the page is open, there's a tab there, and you have one page per tab, and one tab per page.
Vim has a system for tabs as well, but it works in a completely different way from how text
editors and browsers do. Beginners with Vim are often frustrated by this because the model for
tabs is used so consistently in pretty much every other program they're accustomed to, and they
might end up spending a lot of fruitless time trying to force Vim to follow the same model
through its configuration.
I think a good way to understand the differences in concept and usage between Vim's three
levels of view abstraction -- buffers windows , and tabs -- is to learn how to use each from
the ground up. So let's start with buffers.
Buffers
A buffer in Vim is probably best thought of for most users as an open instance of a
file , that may not necessarily be visible on the current screen. There's probably a more
accurate technical definition as a buffer need not actually correspond to a file on your disk,
but it'll work for our purposes.
When you open a single file in Vim, that file gets put into a buffer, and it's the only
buffer there on startup. If this buffer is unmodified (or if you're using hidden
), and you open another file with :edit , that buffer goes into the background and
you start working with the new file. The previous buffer only goes away when you explicitly
delete it with a call to :quit or :bdelete , and even then it's still
recoverable unless you do :bwipe .
By default, a buffer can only be in the background like this if it's unmodified. You can
remove this restriction if you like with the :set hidden option.
You can get a quick list of the buffers open in a Vim session with :ls . This
all means that when most people think of tabs in more familiar text editors, the idea of a
buffer in Vim is actually closest to what they're thinking.
Windows
A window in Vim is a viewport onto a single buffer . When you open a new window
with :split or :vsplit , you can include a filename in the call. This
opens the file in a new buffer, and then opens a new window as a view onto it. A buffer can be
viewed in multiple windows within a single Vim session; you could have a hundred windows
editing the same buffer if you wanted to.
Vim Session with multiple windows open, both horizontally and vertically. Tabs
Finally, a tab in Vim is a collection of one or more windows . The best way to
think of tabs, therefore, is as enabling you to group windows usefully. For example, if you
were working on code for both a client program and a server program, you could have the files
for the client program open in the first tab, perhaps in three or four windows, and the files
for the server program open in another, which could be, say, seven windows. You can then flick
back and forth between the tabs using :tabn and :tabp .
Two tabs open in Vim, each with multiple windows. Move between two tabs with :tabn and
:tabp.
This model of buffers, windows, and tabs is quite a bit more intricate than in other
editors, and the terms are sometimes confusing. However, if you know a bit about how they're
supposed to work, you get a great deal more control over the layout of your editing sessions as
a result. Personally, I find I rarely need tabs as with a monitor of sufficient size it
suffices to keep two or three windows open at a time when working on sets of files, but on the
odd occasion I do need tabs, I do find them tremendously useful.
Thanks to Hacker News users anonymous and m0shen for pointing out potential confusion
with the :set hidden option and the :bdelete command.
The command line in
Vim for ex commands can be edited with a few of the GNU Readline key combinations that may be
familiar to Bash or Emacs users, so it's reasonably easy to edit it, for example to type in
complex search patterns and replacements.
However, if you want the full facility of Vim editing for your commands, it can be helpful
to use Vim's command line window, which will allow you to enter commands and edit previous ones
with the usual normal and insert mode.
You can open the command line window from normal mode in one of four ways:
q: -- Open with a command history from normal mode
q/ -- Open with a search history from normal mode (to search forward)
q? -- Open with a search history from normal mode (to search backward)
Ctrl+F -- Open with a command history from command mode
Note that this doesn't work while you're recording macros, since pressing q stops the
recording.
The window is always immediately above the status bar, and its height can be set via the
cmdwinheight option.
Command line window
Once the command line window is opened with q: , you can browse through it and
press Enter on any line to issue the same command again. You can also edit it beforehand,
perhaps to fix a mistyped command. The window will close when this is done, but you can close
it with Ctrl+W, C the same as any other window if you change your
mind.
Vim command line window
Note that you can't move to another window while this one is open, nor can you load another
buffer into it.
Search window
Similar to the above, if you open the command window with q/ or q?
, it shows a history of your searches, and pressing enter on any line will issue the same
again, in the appropriate direction.
Vim search window
For more information on how the command window works, check out :help
command-line-window .
The benefits of
getting to grips with Vim are immense in terms of editing speed and maintaining your "flow"
when you're on a roll, whether writing code, poetry, or prose, but because the learning curve
is so steep for a text editor, it's very easy to retain habits from your time learning the
editor that stick with you well into mastery. Because Vim makes you so fast and fluent, it's
especially hard to root these out because you might not even notice them, but it's worth it.
Here I'll list some of the more common ones. Moving one line at a time
If you have to move more than a couple of lines, moving one line at a time by holding down
j or k is inefficient. There are many more ways to move vertically in
Vim. I find that the two most useful are moving by paragraph and by screenful, but this depends
on how far and how precisely you have to move.
{ -- Move to start of previous paragraph or code block.
} -- Move to end of next paragraph or code block.
Ctrl+F -- Move forward one screenful.
Ctrl+B -- Move backward one screenful.
If you happen to know precisely where you want to go, navigating by searching is the way to
go, searching forward with / and backward with ? .
It's always useful to jump back to where you were, as well, which is easily enough
done with two backticks, or gi to go to the last place you inserted text. If you
like, you can even go back and forth through your entire change list of positions with
g; and g, .
Moving one character at a time
Similarly, moving one character at a time with h and l is often a
waste when you have t and f :
t<char> -- Move forward until the next occurrence of the
character.
f<char> -- Move forward over the next occurrence of the
character.
T<char> -- Move backward until the previous occurrence of the
character.
F<char> -- Move backward over the previous occurrence of the
character.
Moving wordwise with w , W , b , B ,
e , and E is better, too. Again, searching to navigate is good here,
and don't forget you can yank , delete or change forward or backward
to a search result:
Don't bother typing it, or yanking/pasting it; just use * or # .
It's dizzying how much faster this feels when you use it enough for it to become
automatic.
Deleting, then inserting
Deleting text with intent to replace it by entering insert mode immediately afterward isn't
necessary:
d2wi
It's quicker and tidier to use c for change:
c2w
This has the added benefit of making the entire operation repeatable with the .
command.
Using the arrow keys
Vim lets you use the arrow keys to move around in both insert and normal mode, but once
you're used to using hjkl to navigate, moving to the arrow keys to move around in
text feels clumsy; you should be able to spend the vast majority of a Vim session with your
hands firmly centered around home row . Similarly, while the Home and End
keys work the same way they do in most editors, there's no particular reason to use them when
functional equivalents are closer to home in ^ and $ .
So wean yourself off the arrow keys, by the simple expedient of disabling them entirely, at
least temporarily:
The benefits of sticking to home row aren't simply in speed; it feels nicer to be
able to rest your wrists in front of the keyboard and not have to move them too far, and for
some people it has even helped prevent
repetitive strain injury .
Moving in insert mode
There's an additional benefit to the above in that it will ease you into thinking less about
insert mode as a mode in which you move around; that's what normal mode is for. You should, in
general, spend as little time in insert mode as possible. When you want to move, you'll get in
the habit of leaving insert mode, and moving around far more efficiently in normal mode
instead. This distinction also helps to keep your insert operations more atomic , and
hence more useful to repeat.
Moving to Escape
The Escape key on modern keyboards is a lot further from home row than it was on Bill Joy's
keyboard back when he designed vi. Hitting Escape is usually unnecessary; Ctrl+[ is a lot
closer, and more comfortable. It doesn't take long using this combination instead to make
reaching for Escape as you did when you were a newbie feel very awkward. You might also
consider mapping the otherwise pretty useless Caps Lock key to be another Escape key in your
operating system, or even mapping uncommon key combinations like jj to Escape. I
feel this is a bit drastic, but it works well for a lot of people:
inoremap jj <Esc>
Moving to the start or end of the line, then inserting
Just use I and A . Again, these make the action repeatable for
other lines which might need the same operation.
Entering insert mode, then opening a new
line
Just use o and O to open a new line below and above respectively,
and enter insert mode on it at the same time.
Entering insert mode to delete text
This is a pretty obvious contradiction. Instead, delete the text by moving to it and using
d with an appropriate motion or text object. Again, this is repeatable, and means
you're not holding down Backspace. In general, if you're holding down a key in Vim, there's
probably a faster way.
Repeating commands or searches
Just type @: for commands or n / N for searches; Vim
doesn't forget what your last search was as soon as you stop flicking through results. If it
wasn't your most recent command or search but it's definitely in your history, just type
q: or q/ , find it in the list , and hit
Enter.
Repeating substitutions
Just type & to repeat the last substitution on the current line. You can
repeat it on all lines by typing g& .
Repeating macro calls
Just type @@ .
These are really only just a few of the common traps to avoid to increase your speed and
general efficiency with the editor without requiring plugins or substantial remappings. Check
out the Vim Tips wiki for
some other really helpful examples.
While Vim's core is
very stable, problems can come about when extending the editor with plugins, particularly if
there are a high number of them or if they're buggy or not very well written. While Vim offers
a number of ways to keep scripts' behaviours isolated from one another, it may happen that you
find Vim behaving in an unexpected way that you can't quite pin down. There are a few very good
approaches to figuring this out. List your scripts
First of all, it helps to get a handle on what exactly you've got loaded during your Vim
sessions. You can do this with the :scriptnames command:
This list appears in the order in which the files were loaded, which might give you a
starting point for figuring out where the problem lies.
Update your plugins
Check the documentation, release logs, known problems, and in particular the website of your
chosen plugins to see if there are any recent updates to them. If they're hosted on GitHub,
pull down the most recent versions.
Start with no plugins
You can start Vim with no plugins, in a pristine state that doesn't source any
vimrc files from your system or home directories, to figure out if the behaviour
you're observing still occurs with no plugins at all installed. This is done by calling Vim
with the -u and -U options, which normally specify the path to a
custom location for vimrc and gvimrc files respectively, with the
special parameter of NONE :
$ vim -u NONE -U NONE
Vim will open and you'll see the usual blue tildes for opening a line and Vim's opening
splash screen, having completely ignored your laborious setup.
This done, you can source plugins individually until you notice the problem starts
happening, by a process of elimination:
If Vim was compiled with the +startuptime feature, you can also pass the
--startuptime flag to it with a filename argument, and it will save a verbose log
of its startup procedure to that file for you to inspect:
$ vim +q --startuptime startuptime.txt
$ vim startuptime.txt
There's way more information in here than you're ever likely to need, but in the case of a
buggy setup or unacceptably slow startup time, it's very useful for diagnosing the bottleneck
in your setup.
"... Brief: Looking for best programming editors in Linux? Here's a list of best code editors for Linux. The best part is that all of them are open source code editors. ..."
Brief: Looking for best programming editors in Linux? Here's a list of
best code editors for Linux. The best part is that all of them are open source code
editors.
If you ask the old school Linux users, their answer
would be Vi, Vim, Emacs, Nano etc. But I am not talking about them. I am going to
talk about new age, cutting edge, great looking, sleek and yet powerful, feature-rich
best open source code editors for Linux
that would enhance your
programming experience.
Best modern Open Source editors for Linux
I use Ubuntu as my main desktop and hence I have
provided installation instructions for Ubuntu based distributions. But this doesn't
make this list as
best code editors for Ubuntu
because the list is
apt for any Linux distribution. Just to add, the list is not in any particular
priority order.
1. Brackets
Brackets
is an open source code editor from
Adobe
. Brackets focuses exclusively on the needs of web designers with built-in
support for HTML, CSS and JavaScript. It is lightweight and yet powerful. It provides
you with inline editing and live preview. There are plenty of plugins available to
further enhance your experience with Brackets.
Some of the main features of Brackets code editor are:
Inline editing
Live preview
Preprocessor Support
Built-in extension manager
Cross-platform
You can get the source code as well as binaries for
Linux, OS X and Windows on its website.
Atom
is another modern and sleek looking open source editor for programmers. Atom
is developed by Github and promoted as a "hackable text editor for the 21st century".
The looks of Atom resembles a lot like Sublime Text editor, a hugely popular but
closed source text editors among programmers.
Some of the main features of Atom code editor are:
Easily extendible
Built-in package manager with a huge number of plugins available
Smart autocompletion
Split windows
Cross-platform
Embedded Git control
Command palette support
Looks customization
Atom has recently released .deb and .rpm packages so
that one can easily install Atom in Debian and Fedora based Linux distributions. Of
course, its source code is available as well.
Flaunted as "the next generation code editor",
Light Table
is another modern looking, underrated yet feature-rich open source
code editor which is more of an IDE than a mere text editor.
There are numerous extensions available to enhance its
capabilities. Inline evaluation is what you would love in it. You have to use it to
believe how useful Light Table actually is.
Some of the main features of Light Table are:
Built-in extension manager
Inline evaluation obviates the need for printing to screen as you can evaluate
the code in the editor live
'Watches' feature lets you see your code running live
Cross-platform
If you are using Ubuntu-based Linux distribution, then
installing Light Table is easier
for you. However, officially, Light Table
doesn't provide any packages. You have to build it yourself.
Visual Studio Code is a popular code editor from Microsoft. Now don't push the
panic button just yet. Visual Studio Code is completely open source.
In fact, Visual Studio Code was among the first few 'peace offering' from
Microsoft to Linux and Open Source world. Microsoft has open sourced a number of its
tools after that. Of course, that doesn't include Microsoft Office.
Visual Studio Code is an excellent code editor, especially for web development. It
is lightweight as well. Some of the other main features are:
Intellisense provides useful hints and auto-completion features
Built-in Git support
Built-in extension manager with plenty of extensions available to download
Integrated terminal
Custom snippet support
Debugging tools
Support for a huge number of programming languages
Cross-platform
You can download packages for Ubuntu and Fedora from its website:
No, we are not limited to just four code editors in
Linux. The list was about modern editors for programmers. Of course, you have plenty
of other options such as
Notepad++ alternative Notepadqq
or
SciTE
and many more. So, among these four, which one is your favorite code editor
for Linux?
47
comments
9:26 pm
March 20, 2017
Ced
I'm going to try the Lime Text
6:41 am
March 8, 2017
Casper
How to install Lime Text?
6:43 am
March 7, 2017
Himanshu Shekhar
Spacemacs
12:00 pm
July 17, 2016
Marco Czen
Do look at Visual Studio Code a well
11:08 pm
May 23, 2016
Jesse Boyd
How could you not mention Eclipse or Spring Tool Suite for code
editing? These are software developer industry standard and have
linux versions.
7:22 pm
May 10, 2017
Koszko
He didn't mention them because they're IDEs and this
article is about code editors only.
12:31 pm
October 6, 2017
Thor
That's a bit of a stretch. VS Code can initiate
compilation and solve references just as Atom can.
There's no differencw othwr than the language used
to write the applications. The only reason is these
are mosly scripted languages used to write the
editors/IDEs, while better IDEs are written in C++
or Java.
He still should have included both Eclipse anf
the community editions of the JetBrains tools.
9:52 am
February 24, 2016
Anonymous
Any article on modern open source editors for linux that doesn't
mention Kate is not worth reading.
3:05 am
April 4, 2016
Mauricio Martínez Garcia
emacs for ever
3:43 pm
February 17, 2016
saprative
vim
9:24 am
February 17, 2016
sanjay tharagesh
I am new to linux and using ubuntu right now. Its very annoying
to write a c++ program in an text editor and then run it on
terminal and also It is difficult to edit my program by this
way.In windows i used to do the program with turbo c++, its easy
to handle and to compile and run the program. Can you suggest me
a c++ editor for ubuntu, which will be easy to compile and run
the programs easily.I also tried komodo edit but i dont know how
to compile and run the program.
sanjay tharagesh.
4:01 pm
August 9, 2016
David Dreggors
OOPS! I also forgot to mention Code::Blocks... also a very
nice open source Linux compatible IDE.
"... Predefined code snippets are files that contain already written code meant for a specific purpose. To add code snippets, type \nr and \nw to read/write predefined code snippets. Issue the command that follows to list default code snippets: ..."
bash-support is a highly-customizable vim plug-in, which allows you to insert: file headers, complete
statements, comments, functions, and code snippets. It also enables you to perform syntax checking,
make a script executable, start a debugger simply with a keystroke; do all this without closing the
editor.
After writing script, save it and type \re to make it executable by pressing [Enter].
Make Script Executable
Make Script Executable
How To Use Predefined Code Snippets To a Bash Script
Predefined code snippets are files that contain already written code meant for a specific
purpose. To add code snippets, type \nr and \nw to read/write predefined code snippets. Issue the
command that follows to list default code snippets:
$ .vim/bash-support/codesnippets/
List of Code Snippets
To use a code snippet such as free-software-comment, type \nr and use auto-completion feature
to select its name, and press [Enter]:
Add Code Snippet to Script
Add Code Snippet to Script
Create Custom Predefined Code Snippets
It is possible to write your own code snippets under ~/.vim/bash-support/codesnippets/. Importantly,
you can also create your own code snippets from normal script code:
choose the section of code that you want to use as a code snippet, then press \nw, and closely give
it a filename.
to read it, type \nr and use the filename to add your custom code snippet.
View Help For the Built-in and Command Under the Cursor
To display help, in normal mode, type:
\hh – for built-in help
\hm – for a command help
View Built-in Command Help
View Built-in Command Help
For more reference, read through the file :
~/.vim/doc/bashsupport.txt #copy of online documentation
~/.vim/doc/tags
Visit the Bash-support plug-in Github repository: https://github.com/WolfgangMehner/bash-support
Visit Bash-support plug-in on the Vim Website: http://www.vim.org/scripts/script.php?script_id=365
That's all for now, in this article, we described the steps of installing and configuring Vim
as a Bash-IDE in Linux using bash-support plug-in. Check out the other exciting features of this
plug-in, and do share them with us in the comments.
jrepin writes: Mayank Sharma of Linux Voices
tests and compares five text editors for Linux,
none of which are named Emacs or Vim. The contenders are
Gedit, Kate,
Sublime Text,
UltraEdit, and jEdit. Why use a fancy text editor?
Sharma says, "They can highlight syntax and auto-indent code just as effortlessly as they can
spellcheck documents. You can use them to record macros and manage code snippets just as easily
as you can copy/paste plain text. Some simple text editors even exceed their design goals thanks
to plugins that infuse them with capabilities to rival text-centric apps from other genres. They
can take on the duties of a source code editor and even an Integrated Development Environment."
I used Xedit as well, as well as EDIT and EDGAR before it. Having learned programming on the IBM
Mainframes, what else would I have used? I later picked up an editor with no name for DOS, just
E.EXE. It was one of IBM's internal company programming editors never released to the public.
In 1993 I lost my copy of E, and I was unable to obtain a new copy. It was better than Xedit, and
still used REXX as a scripting language.
In 1995, I picked up a copy of UltraEdit for Windows 95. It didn't do everything that my old E.EXE
did, but I was pretty pleased with it, once I learned how to use it properly. The new versions of
UltraEdit make E and Xedit pale by comparison. Yes, it is a whole new way of working. I hated getting
away from the command line. I used to think that if you weren't doing it from the command line,
you weren't a real programmer. However, I have learned that I can be much more efficient than I
used to be by learning new ways of doing things.
UltraEdit has scripting language support that is very, very powerful. REXX is good, but UltraEdit
uses JavaScript. It seems JavaScript is an important language to learn these days anyway. It can
only help your resume to have it listed as a language that you are proficient in.
How painful was it for me to make the switch? Hey, I jumped from using DOS/DESQview, a Unix (not
Linux) Server with XWindows, to Windows 95 and a Novell Server (because of the company I was working
for), I was already complaining a lot.
It may be painful at first to have to get used to a new way of doing things, but rest assured, after
you've had a few months under your belt learning all there is to UE and its powerful scripting language,
the features, the ability to run your scripts on files from the command prompt, the ability to run
command line utilities and pipe them through to be filtered into your editor and worked with...
I could go on and on about the features that you will discover only after digging into it extensively,
but let me tell you it will all be well worth it.
Yeah, I probably told a bit about my age telling you what I started out working with as editors,
but I don't care. If someone like me can make the switch and learn to love it, you can too.
When it comes to editors that can handle the unicode properly, there is no better editor on the
market. It is hands down the most powerful text editor available today, and it's on the Windows
platform.
Personally, I've moved up to using UEStudio. It has all the features of UltraEdit, but adds quite
a few extras to make it a full-fledged IDE instead of just the most powerful editor on the planet.
Imagine an Integrated Development Environment that has an editor like that built in!
I often knock off a 20 line KEXX macro to handle some special case (like editting Wireshark
telegrams that meet certain weird column-based criteria); how easy is it to do something comparative
in UE?
It will be just as easy, once you learn JavaScript as well as you know KEXX. If it is simple enough
to create a Macro instead of a script, you can "record" the macro, then play it back to finish your
editing. I probably record and replay macros 10X as much as writing scripts, but scripts have their
place for the real power.
rhapdog wrote:I used Xedit as well, as well as EDIT and EDGAR before it. Having
learned programming on the IBM Mainframes, what else would I have used? I later picked up an
editor with no name for DOS, just E.EXE. It was one of IBM's internal company programming editors
never released to the public.
Ah, yes. E, EOS2, EPM....
I contracted at IBM from 1990-1992. The funny thing was, I used Kedit before going to IBM, and by
the time I was at IBM, I was using MultiEdit . I original started with Jim Wylie's Personal Editor
(remember EWS?), but it was DOS 1.x, so it didn't support subdirectories; plus, putting PE.PRO in
every damn subdirectory was a pain. I started with Kedit to basically be a PE that knew about subdirectories.
From there, I went to IBM, but since IBM at the time was OS/2 1.x, with a single penalty box, I
switched back to Kedit for OS/2 so I could run native, and haven't looked back.
I'm considering MultiEdit again (a friend loves it), but I'm scoping out UE first. Reviews seem
kinder to UE than ME. Most of what I do these days is C++, XML, Perl, and Ruby. I've downloaded
the UE demo, and have played with it a bit. It's... different. I've been reading some hyper critical
reviews of UE (http://fileforum.betanews.com/detail/UltraEdit/976352095/1?all_reviews),
but I've read several other glowing reviews, so I'm trying to do a fair Kedit/UE comparison.
I expect that whichever way I go, it will be painful enough that I want to select an editor that
I can stick with for another 15 years before going through this again.
rhapdog wrote:I hated getting away from the command line. I used to think that
if you weren't doing it from the command line, you weren't a real programmer. However, I have
learned that I can be much more efficient than I used to be by learning new ways of doing things.
I definitely miss the command line. The F10 in UE brings up a command window, but it's not the same.
rhapdog wrote:UltraEdit has scripting language support that is very, very powerful.
REXX is good, but UltraEdit uses JavaScript. It seems JavaScript is an important language to
learn these days anyway. It can only help your resume to have it listed as a language that you
are proficient in.
rhapdog wrote:How painful was it for me to make the switch? Hey, I jumped from
using DOS/DESQview, a Unix (not Linux) Server with XWindows, to Windows 95 and a Novell Server
(because of the company I was working for), I was already complaining a lot.
I remember using Desq (pre-DesqView) with X. Thankfully, I skipped Win9x and went straight to OS/2.
One of the reasons I stuck with Kedit was that whether I was using DOS, OS/2, or eventually Windows
NT, there was always a Kedit version. These days, DOS is pretty much a memory, as is OS/2, so compatibility
with those platforms is no longer important.
I do see that UE has build in support for FTP, which is nice. Also telnet.
rhapdog wrote:It may be painful at first to have to get used to a new way of doing
things, but rest assured, after you've had a few months under your belt learning all there is
to UE and its powerful scripting language, the features, the ability to run your scripts on
files from the command prompt, the ability to run command line utilities and pipe them through
to be filtered into your editor and worked with.... I could go on and on about the features
that you will discover only after digging into it extensively, but let me tell you it will all
be well worth it.
Thanks. I already do a lot of that by having Kedit macros that call DOSQ and run Take Command scripts
which pipe stuff back to Kedit. I work on a lot of apps that generate tons of log data (300MB is
not uncommon, spread over ~100 files), so what I typically do is flag certain log conditions, tag
them with a unique id (say bdh, my initials), and then have Kedit grab the 300MB file, and using
ALL to see the filtered lines, expanding as required to see the state. That sort of thing is beyond
most of the other editors I've looked at.
rhapdog wrote:Yeah, I probably told a bit about my age telling you what I started
out working with as editors, but I don't care. If someone like me can make the switch and learn
to love it, you can too.
I think any of us with Kedit 3 digit serial numbers are probably of an age.
rhapdog wrote:When it comes to editors that can handle the unicode properly, there
is no better editor on the market. It is hands down the most powerful text editor available
today, and it's on the Windows platform.
Not to be contrary, but have you looked at MultiEdit? It also claims to be the most powerful. I've
got no dog in the race yet, I'm planning on kicking the tires of both (and maybe a dark horse called
Zeus someone's mentioned: http://www.zeusedit.com/features.html).
Zeus appears to be a next gen version of Brief, from back in the day. The only reason I even found
it is that looking for a ME to UE comparison, the only thing close was this forum entry:
http://www.zeusedit.com/zforum/viewtopic.php?t=200,
which of course claims Zeus is better than either, but at least points out things about ME and UE
I'll want to check).
rhapdog wrote:Personally, I've moved up to using UEStudio. It has all the features
of UltraEdit, but adds quite a few extras to make it a full-fledged IDE instead of just the
most powerful editor on the planet. Imagine an Integrated Development Environment that has an
editor like that built in!
I've read the reviews. Someone mentioned that you're better off starting with UE than UES, since
features are added to UE long before UES gets them. Also, you can move up from UE to UES, but it's
more difficult to go back. I'm going to play with UE for 30 days and see how it goes.
rhapdog wrote:It will be just as easy, once you learn JavaScript as well as you
know KEXX. If it is simple enough to create a Macro instead of a script, you can "record" the
macro, then play it back to finish your editing. I probably record and replay macros 10X as
much as writing scripts, but scripts have their place for the real power.
Thanks for the help. My problem is that almost all of my peers are of the Visual Studio generation.
The idea of a standalone editor is foreign to most of them. Although some do use Notepad++ or VIM,
there's no one other than me using anything else. The idea of a commercial editor is foreign to
them, and anything derived from an IBM mainframe is before most of them were born. Suffice to say,
talking about XEdit features really shows the generational divide. I wasn't sure if anyone had taken
the plunge from Kedit to UE, but the fact that you've done it, and recommend it, is probably the
best recommendation I can think of for me to invest in UE and give it a fair shake.
billdehaan wrote:I expect that whichever way I go, it will be painful enough that
I want to select an editor that I can stick with for another 15 years before going through this
again.
If you want to do this long term, consider a lifetime license. That's the best way to go. Stay current.
IDM is a strong company and isn't going anywhere. With the number of users they have world-wide,
you will have support for your product for life.
These "bad" reviews are obviously from people who did not properly study or learn to use their editor.
I will guarantee those complaining about slow startup didn't check to see that it was because of
a slow network share, an antivirus monitoring program that was a bit haywire, or some other issue
on their system. Those complaining about too many toolbars and getting lost in the options never
studied about UE's Environments, where you can choose what to see and what not to see. I could debunk
every criticism, but won't take time to do it here.
billdehaan wrote:Not to be contrary, but have you looked at MultiEdit? It also
claims to be the most powerful.
Yes. I have. It just can't do everything that UltraEdit does. It is also considerably more expensive.
For my money, UE is the best deal. They may "claim" to be the most powerful, but when I state that
UE is the most powerful, it isn't just a claim from IDM, it is a claim by the People's Choice Awards,
Shareware Industry, numerous magazine publications, and numerous 3rd party reviews.
If you Google for "Most powerful text editor for Windows", you will find many reviews that have
a "list" of most powerful editors. I have seen "10 most powerful", "15 most powerful", "5 most powerful",
etc., but have not once seen MultiEdit in a most powerful list. UE, in each of those, was stated
to be the most powerful (at least the ones I looked at when I Googled this morning.)
billdehaan wrote:the only thing close was this forum entry:
http://www.zeusedit.com/zforum/viewtopic.php?t=200,
which of course claims Zeus is better than either, but at least points out things about ME and
UE I'll want to check).
I read that just now. Zeus is laughable compared to UE. This is also an old post, and some of the
things stated about UE were either in ignorance, or have been fixed since then. Not one negative
he listed is currently true of UE.
billdehaan wrote:I've read the reviews. Someone mentioned that you're better off
starting with UE than UES, since features are added to UE long before UES gets them. Also, you
can move up from UE to UES, but it's more difficult to go back. I'm going to play with UE for
30 days and see how it goes.
This is not true. When it comes to new releases, there can be advantages to each direction. Yes,
UE gets the features added first. Then with that widespread release, bugs are invariably reported
(as any program as complicated as UE will have) and subsequently fixed. When these bugs are squashed,
and the product is refined even further, then a few new features are usually added to UES that never
made it into UE, because UES is supposed to have more features.
The time frame can be a couple of weeks, or a month, sometimes as long as 2 months. This is not
a make or break time period to wait on the features to migrate over to UES, especially considering
that once you get those features, they will be stable and you won't have to patch it later after
being frustrated by the bug you found.
The real way you need to evaluate it is do you need to "compile" your programs from projects. If
you're coworkers are using Visual Studio, and you're working from the same compiler that they are,
then you'll find that once you get UES up and running, it will offer you features to handle multiple
project files to allow them to interact in ways you can't do with UE.
If you are going to make an investment, and take time to learn a product after you do, then you
should seriously consider UES. If I were doing stuff that others were designing in Visual Studio,
then I would be using UES. I'm actually using UES for Delphi 2010 replacement, and also for a number
of PHP site projects. It works with the frameworks flawlessly.
Also, as far as "going back", I read recently that someone requested their lifetime license for
UES be "downgraded" to UE, because they no longer needed the UES features. They were able to do
so. To get the lifetime license for UES, after you have UE, you still have to pay again, although
you get a loyalty discount. Something to consider. I can't imagine you doing that kind of programming
and not being able to use the full power of UES, but I can see you regretting not going that route
should you settle for the smaller package.
billdehaan wrote:The idea of a commercial editor is foreign to them, and anything
derived from an IBM mainframe is before most of them were born. Suffice to say, talking about
XEdit features really shows the generational divide. I wasn't sure if anyone had taken the plunge
from Kedit to UE, but the fact that you've done it, and recommend it, is probably the best recommendation
I can think of for me to invest in UE and give it a fair shake.
I would like to stress that an editor is probably the most important tool for programmers, therefore
one needs to choose it wisely. A popular consideration that easy to learn editor (for example
Pico or Notepad) is the best does not withstand any critique. An editor is too important tool
for programmers to settle for the basic capabilities and it's a big disadvantage to select a
mediocre or even primitive solution just because it's simple to learn. Any professional programmer
needs a professional editor.
The main problem that I see is that people tent to stick to whatever editor they got used to
first and even became emotionally attached to the "first choice".
The author argues that programmable editors are worth studying like programming languages and
a powerful editor is huge advantage from the point of view of reaching high productively (and
avoiding many typical frustrations).
...Well, just one day of testing showed me that at least the speed complaint didn't apply to
me. I've not seen the "crashes every day" problem either, of course. I already know from Sturgeon's
Law that 90% of the complaints are just bellyaching, that's why we have tryout periods.
I can already see how people could be overwhelmed by UE. It took me a bit of time to find how to
set the environment to "Programmer". As always, it's obvious to those familiar with the product,
but there are staggering number of pulldowns, menu options, and etc. in UE.
rhapdog wrote:Yes. I have. It just can't do everything that UltraEdit does. It
is also considerably more expensive. For my money, UE is the best deal. They may "claim" to
be the most powerful, but when I state that UE is the most powerful, it isn't just a claim from
IDM, it is a claim by the People's Choice Awards, Shareware Industry, numerous magazine publications,
and numerous 3rd party reviews.
As I said, I used ME back in the late 1980s, with the DOS version. Back then, it was quite competitive,
which means absolutely nothing today. I noted that their price is higher (ME: $199, Zeus: $99, UE:
$59-$89+). Obviously, I'd prefer cheaper, but I'm not going to disqualify based on price. Adjusting
for inflation, ME today at $199 is cheaper than Kedit was at $125 in 1985. The time investment I'm
going to put into whichever editor I end up choosing will certainly exceed $100 over the years.
rhapdog wrote:If you Google for "Most powerful text editor for Windows", you will
find many reviews that have a "list" of most powerful editors. I have seen "10 most powerful",
"15 most powerful", "5 most powerful", etc., but have not once seen MultiEdit in a most powerful
list. UE, in each of those, was stated to be the most powerful (at least the ones I looked at
when I Googled this morning.)
Of course, power is in the eye of the beholder. What's keenly important to web developers may not
matter a bit to someone doing embedded assembler, and vice versa. A co-worker told me he considers
EditPlus to be the most powerful editor. When I asked him what scripting features he said, he answer
"I'm not sure if it has any. If it does, I might have just removed the menu item for it, since I
don't use macros". Lots of people claim Eclipse is the best of breed, but when I played with it,
I found I couldn't even remap the keyboard. I was asked "Why would you want to do that?".
rhapdog wrote:I read that just now. Zeus is laughable compared to UE. This is also
an old post, and some of the things stated about UE were either in ignorance, or have been fixed
since then. Not one negative he listed is currently true of UE.
Certainly the comparison is out of date. Looking at Zeus, I'm not about to rule it out without further
checking. Especially since both Zeus and UE use javascript for a (of one of the) scripting language,
it should be an easy comparison.
rhapdog wrote:The time frame can be a couple of weeks, or a month, sometimes as
long as 2 months. This is not a make or break time period to wait on the features to migrate
over to UES, especially considering that once you get those features, they will be stable and
you won't have to patch it later after being frustrated by the bug you found.
I wasn't sure what the time frame was.
... ... ...
rhapdog wrote:The author argues that programmable editors are worth studying like
programming languages and a powerful editor is huge advantage from the point of view of reaching
high productively (and avoiding many typical frustrations).
That is good advice for anyone.
Oh, I agree fully. I still remember when I got my August 1985 issue of "Computer Language" magazine
(they of the Jolt awards), where they devoted the cover story to comparing all of the editors on
DOS at the time (Brief, Qedit, Kedit, all the various Unix and big-iron ports, etc). Just checking
my Kedit macros directory, I see I've written 40,383 lines of macros over the years. The idea of
just using any editor "as-is" just off the rack is anathema to me, although fairly common.
I think that's why so many people love Notepad++. Not to take anything from it, it's a terrific
out of the box editor. But even with the plugins, the extensibility is pretty limited. If it does
what you need already, it's great. If it doesn't, you're stuck.
To me, when it doesn't do what I want out of the box, that's where the real issue is. That's when
I can judge how long it takes me to be able to get it to do what I need. A non-scriptable editor
may be very powerful, but I notice most people who use them end up adjusting their work habits to
confirm to the editor, rather than the other way around.
Usually, when someone shows me a cool feature from their editor and asks if my "20th century" Kedit
can do that, the usual answer is "not yet, but give me an hour". But with unicode, and things like
Kedit's line-only orientation (as opposed to keyword), that's increasingly become "no". That's why
I'm seeing if UE is extensible enough to make it back into the "not yet, let me write a script"
column.
billdehaan wrote:As you can imagine, I've got a number of KEXX macros that parse
the output of the build process and feed it back in so Kedit can deal with it directly.
I was thinking about that. With a little modification, you may be able to convert your KEXX macros
into REXX, then run them from a REXX Interpreter like Regina as a Tool from within UltraEdit. Certainly
not all macros will be able to be converted, but most should, I would think. Some may not require
converting at all, if it doesn't use the KEXX specific subset.
Something to think about.
I actually use a number of PHP scripts and run them against my current document at times, because
that is something I code in often. You could implement any number of scripting languages in this
way, but you'll miss out on the UltraEdit application object that has been included in UltraEdit's
version of JavaScript. It allows you to perform some of UltraEdit's functionality without having
to reinvent the wheel, which is nice.
billdehaan wrote:Just checking my Kedit macros directory, I see I've written 40,383
lines of macros over the years.
Yeah, I'd definitely see if some of that can be converted to REXX and run through Regina. No sense
in wasting it. If you could do that, you'd probably have something serious to share with the community.
Great light-weight Windows style editor from Alexander Lukyanov.
LE has many block operations with stream and rectangular blocks, can edit both unix and dos style
files (LF/CRLF), is binary clean, has hex mode, can edit text with multi-byte character encoding,
has full undo/redo, can edit files and mmap-able devices in mmap shared mode (only replace), has
tunable syntax highlighting, tunable color scheme (can use default colors), tunable key map. It
is slightly similar to Norton Editor, but has more features.
AEditor is a programmer's editor for Windows, Unix, and Mac OS X that relies on the fox toolkit.
It can do syntax coloring of Ruby and C++ files. It's easy to change the color theme. Most things
are customizable. It is written in Ruby and is carefully unit-tested (it has 421 tests). It is written
in only ~5500 lines of code, so it should be easy to grasp and extend.
I'm an editor junkie. I've used dozens of them. I'm currently using with EditPlus for Windows,
but it's still not my perfect editor. These days, it should be easy enough to have a more componetized
editor: a simple visual display component, plus ways of shooting text to Perl or Python (or
your favorite language) to do fancy grunt work. Instead, text editor authors tend to take a
GUI-heavy approach, building everything into one, monolithic application. I have seen two alternatives.
One is Emacs. I don't want to get into a flame way about Emacs. I've used it. But it's more
a lifestyle than a text editor. And then there's Wily, which is a clone of an editor for Plan9
called ACME. Wily looks interesting, but it is a UNIX-only program--no Windows version. And,
okay, someone is going to mention vi. Yes, I've used vi. I've written tens of thousands of lines
of code with vi. But in the end both vi and Emacs strike me as editors from another era. The
cleanliness that comes from an editor like EditPlus or BBEdit (a Mac editor), is something I
don't want to lose.
Junkster
Extreme programmability is important for several reasons. The first is that it offers up
a lot of options, letting you do things that the author hadn't thought of. For example, I often
use non-mainstream programming languages that would benefit from being syntax colored in non-standard
ways (certain types of lines colors a specific way, rather than just keywords). I'd also like
to be able to extend an editor to context-sensitive tab completion; build custom, interactive
project management systems, etc. All of this stuff is business as usual in Emacs. But Emacs
is a relic of the past otherwise.
Text munging is easy. We have entire programming languages devoted
to it. An editor just needs to be a thin interface with hooks to routines written in such a
language. It shouldn't be a monlithic application. I'm surprised that no one
has followed this road, other than Stallman's Emacs.
Mac
Visual slickedit is a good alternative. But slick-c is a crappy hacked scripting language.
I have written dozen of functions to do things that I want similiar in emacs and vim, but slick-c
just can't live up with any other scripting languages that I have used (lisp, perl, python,
js).
And the source code that came with vslick are not horrible mess. Good luck trying to learn
and understand those source code - it's like I haven't had enough reading my peer's code...
Just my $0.02
And the source code that came with vslick are JUST horrible mess.
BTW, the API provided by slick-c is very inconsistent (I'm not saying elisp is WAY better,
but at least it's still managable...)
christopher baus (www.baus.net) Wednesday,
I used to be a emacs bigot, but I'm over it. I still write code nearly every day in Emacs
on Unix, and VC++ on Windows, but having seen a demonstration of XCode, I've decided to move
my Unix development over to the Mac.
What I think is interesting is that emacs it is completely unique approach to application
development, and it worth learning just for the alternative look at software applications. I
has certainly influenced Gosling's (who used to work on emacs), NeWS and Java -- not to mention
autocad which orginally had a lisp based scripting language. Lisp had a VM and garbage collection
a million years ago.
Emacs is powerful enough that it is still useful 25+ years after it was orginally written.
But I'm not a student anymore, and I don't have time to endlessly tune my .emacs and custom
makefiles. Plus I've grown so used to modern IDEs that emacs + gud is painful.
What I think might be interesting is a editor or platform built with emacs as the model,
but assuming a modern windowing environment. Maybe we have it in .NET, but it doesn't seem quite
the same.
Junkster
Yes, I've used UltraEdit. It's essentially the same as EditPad Pro and EditPlus. But they're
all very closed systems (in the extensibility sense, not the open source sense). An editor can
just be shell and use Perl, for example, to do the real grunt work.
I have also tried vim, which I consider to vi plus some much needed extensions. It still
comes across as dated and clunky under Windows. The interface in a typical Windows editor is
so invisible compared to vim and Emacs.
Phillip J. Eby
jEdit. It's scriptable with Jython and BeanShell. It has syntax highlighting for a bazillion
languages, and it has a flurry of plugins available for every imaginable want or need. I use
the XML plugin, the LaTeX plugin, the project management plugin, and there are many many many
more available out there. It's hugely configurable, lots of GUI options. Extremely extensible,
cross platform, and of course it's FLOSS.
It's written in Java, and startup takes a while on older machnes; 20-30 seconds on an old
400Mhz machine. My newer machines start it in 10 or 15. But I've never had any performance issues
once it's loaded, even on slower machines.
Oh yeah, the syntax highlighting also configures lots of nifty features like autoindenting,
block comment, bracket matching (tag matching in XML mode), code folding, and suchlike features.
It's a *very* complete programmer's editor, and should not be confused with Eclipse (which is
a generic IDE/tool platform with some editing capabilities, and whose plugins are heavily slanted
towards Java development).
Oops, forgot to include the URL: http://www.jedit.org/
Slartibartfast
Interesting that nobody mentioned Multi-Edit. http://www.multiedit.com/
Their kernel is Delphi, then everything else is built using CMAC, their scripting language.
Their community is very active, and a new version was just released.
- Hector
Nils
I just played a bit with jEdit on my WinXP notebook. Can someone please explain to me why
the font rendering sucks like a typical Java application? No AA. My XEmacs looks nice on Win
XP. It's also a bit embarrassing that you have to reload the entire app to change the text font.
(XEmacs is a fork of Emacs, not the X11 version)
There seems to be no viable alternative to Emacs or Vim...
C Rose
jEdit does offer anti-aliasing of text, and you enable it via Utilities -> Global options...
-> Text Area. Choose Smooth text and Fractional font metrics (depending upon system spec.).
jEdit is an excellent modern editor. Emacs suffers from massive complexity -- there's so
much to remember. The modal design of vi/m is just weird.
Pakter
I have JEdit installed, and it's not bad at all. JEdit had the same plugins as Eclipse, and
more. But I don't feel "at home" with it. Like Junkster, I use mostly EditPlus. As Junkster
probably knows, you can do a lot with EditPlus, though it's not extensible in the usual sense.
At home, I also use ConText, which is similar to EditPlus, just a little less powerful.
Bored Bystander
I also use Multi-Edit and have ever since its DOS days. ME is a great value ($80-$120 or
so depending on upgrade or new purchase) since it includes features like file differencing and
a generalized compiler interface to act as a sort of self contained IDE to host command line
tools.
The only drawback I've ever seen to ME is that you have to customize its key command mappings
quite a bit in order to get reasonable behavior (ctrl-F for search, F3 for search again, Ctrl-F4
for close window, etc). ME has very strange notions about common shortcuts. And I have not found
a way to make these definitions portable to a new system. (Or, I just don't know the MultiEdit
configuration system as well as I "should".) So every time I move ME to a new PC I have to spend
about 1/2 hour re-customizing it.
Newsgroups: comp.editors From: DMcCunney <pl...@xyzzy.com> Date: Mon, 27 Apr 2009 13:15:51
-0400 Local: Mon, Apr 27 2009 12:15 pm Subject: Re: How many other editors in use Print | Individual
message | Show original | Report this message | Find messages by this author
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:
> http://www.zeusedit.com/
> Zeus is a scriptable programmer's editor.
With configurable keymaps for WordStar, Brief, Emacs, and Epsilon, and scripting in Lua,
Python, Tcl, VB, or JavaScript. ______ Dennis
Mark: 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.
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.
Carl: Sun, Apr 5 2009 9:05 pm
Subject: Re: How many other editors in use
Editors are like OS's, personal preferences
to some extent. I agree 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!
>>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 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).
Newsgroups: comp.editors From: DMcCunney <dennis.mccun...@gmail.com> Date: Sat, 18 Apr 2009
09:58:39 -0700 (PDT) Local: Sat, Apr 18 2009 11:58 am Subject: Re: How many other editors in
use Print | Individual message | Show original | Report this message | Find messages by this
author Coming late to this party...
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 base, 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.
I wish the new Lisp version John Graham et al are working on would move beyond the experimental
and "in flux" stage already, and continue to make an interpreter that can somehow make use
of all the useful Python libraries
Like he points out himself; Lisp isn't much in use, cause except for command shell
scripts, its tough to use for real world stuff, cause there's not much in the way of libraries...
I don't know about the interpreter / compiler situation
I liked Dr. Nikolai Bezroukov's commentary in his commentary on editors on his
Softpanorama website. He talked about macro languages for text editors, and was less than
thrilled with Emacs using a dialect of Lisp, because he felt the language ought to have some
use ouside of the editor, and what other use of Lisp did the majority of Emacs
users make? Eric S. Raymond was going on a while back about what Emacs got wrong, and how much
better Python would be for the purpose. When I said "So rewrite Gnu Emacs to use Python instead
of Lisp." the response was "Don't tempt me..."
I have to agree. I have Gnu Emacs here, but the only use I made of elisp was years back, learning
enough to hack my .emacsrc to properly support the various special keys on the machine I was
running it on. I've had no cause to touch it since.
Most folding capabilities in editors such as
GNU Emacs and most folding
editors such as Origami and fe, are inspired by the Inmos Transputer Development System. After several
years, folding/outlining capabilities in text editors are not as exotic as they used to be, but
they are still far from being well known. This document explains what "folding" is all about.
A folding editor extends the principle of tree structured directories to editing text files.
This allows the simultaneous display of large amounts of text by folding sections of text away behind
a descriptive heading. This results in a tree structure very similar to a subdirectory structure
of, for example, UNIX. By suitable structuring of a text it should be possible, in most circumstances,
to ensure that no display exceeds a single screen at any time. To access text that is folded away,
you open the fold, in which case the contents are displayed in context of the surrounding text.
The advantage of this system is that it eliminates the need for seemingly endless paging through
long files to find the section of interest, allowing you to move down the tree structure, following
the (hopefully) descriptive headers to locate the text you require.
Code Browser supports only the marker-based folding. See
Introduction to Folding
page for the explanation.
Code Browser is a folding text editor for Linux and Windows, designed to hierarchically structure
any kind of text file and especially source code. It makes navigation through source code faster
and easier.
Code Browser is especially designed to keep a good overview of the code of large projects, but
is also useful for a simple css file. Ideal if you are fed up of having to scroll through thousands
of lines of code.
See the Introduction
to Folding page if you want more information on text folding and the way it is implemented in
Code Browser.
It supports syntax highlighting for all major languages and custom syntax highlighting can also
be added.
Although Code Browser was initially designed to edit programs, it can also be used for different
tasks such as plain text outlining or understanding existing source code. I've added a page with
tips on alternative uses.
Cooledit is a text editor for the X Window System. It contains a
built-in Python interpreter for macro programming, and it includes a rich set of utilities and features.
It has multiple edit windows and a beautiful, intuitive user interface that requires no tutoring
to learn to use. It can be used as a programmer's IDE and has syntax highlighting for a large number
of programming languages. It contains an interactive graphical debugger for C/C++ programs.
Code Browser is a folding and outlining editor for Linux and Windows.
The editor is between a traditional text editor, a smalltalk class browser and a web browser
like mozilla. It displays a structured text file (marker-based folding) hierarchically using multiple
panes.
It is especially designed to keep a good overview of the code of large projects. Ideal if you
are fed up of having to scroll through thousands of lines of code.
See the Introduction to Folding
page if you want more information on text folding and the way it is implemented in Code Browser.
It supports syntax highlighting for all major languages and custom highlighting can also be added.
For other editor's features, see Features.
Although Code Browser was designed to write and maintain programs, it can be used for different
tasks such as plain text outlining or understanding existing source code. I've added a page with
tips on alternative uses.
A very interesting Windows editor. Flexible customizable syntax highlighting. Well organized features
This syntax highlighting editor supports numerous programming languages including C/C++, Delphi,
Pascal, Java, JavaScript, Visual Basic, Perl, HTML, SQL, FoxPro, 80x86 assembler, Python, PHP, Tcl/Tk,
etc (you can customize the syntax highlighting). Other features include code templates, customizable
help files for each file type, export to HTML/RTF, file conversion (DOS, Unix, MAC), bookmarks,
commenting, uncommenting code, capturing the output from console applications, etc. It's a Windows
editor.
CUTE is a text editor that is extensible using Python. It supports projects, syntax highlighting
of various programming languages (C, C++, C#, Java, Python, JavaScript) as well as HTML (etc), multiple
documents (tabbed or child frame), ctags, auto-completion, search and replace with regular expressions,
bookmarks, undo/redo, has an integrated file browser, themes, key macros, etc. Binaries (executables)
are available for Linux. The source code is released under the GPL and can be compiled for Windows
13K in size for the editor that's something from DOS era :-). It is written in NASM
assemblerThat's a great achivement and it refreshing to see that not all useful software is bloatware
!!!
The e3 console text editor takes minimalism to the max - the binary is a minuscule 13KB in size!
So why use this instead of [insert the name of your favorite editor here]? If you're anything like
me, you'll find a lot of your editing tasks are very short -- little more than tweaks. e3 starts
instantly and has all the basic features you could want, including find/replace, block cut/copy/paste,
and undo. For complex tasks I use a more feature-packed program, but for a quick change to /etc/fstab
or something similar, this little editor wins every time.
e3 also does its best to be ubiquitous. It works on a whole host of operating systems,
and perhaps best of all, it supports keyboard mappings that emulate WordStar, Pico, emacs, vi, and
Nedit. You can hardly fail to feel at home with it.
Eric Raymonds view on the subject. IMHO he did not understand the real tradeoffs that make vi a
great editor for so many years, but he at least is able to site right people ;-). With all due respect
to RMS, Emacs is definitely anti-Unix type of editor :-).
The traditional Unix view of the world, however, is so attached to minimalism that it isn't very
good at distinguishing between the adhocity-trap problems of vi and the optional complexity of Emacs.
The reason that vi and emacs never caught on among old-school
Unix programmers is that they are ugly. This complaint may be "old Unix" speaking,
but had it not been for the singular taste of old Unix, "new Unix" would not exist.
--
Doug McIlroy
Attacks on Emacs by vi users - along with attacks on vi by the hard-core old-school types still
attached to ed - are episodes in a larger argument, a contest between the exuberance of wealth and
the virtues of austerity. This argument correlates with the tension between the old-school and new-school
styles of Unix.
The "singular taste of old Unix" was partly a consequence of poverty in exactly the same way
that Japanese minimalism was - one learns to do more with less most effectively when having more
is not an option. But Emacs (and new-school Unix, reinvented on powerful PCs and fast networks)
is a child of wealth.
As, in a different way, was old-school Unix. Bell Labs had
enough resources so that Ken was not confined by demands to have a product yesterday. Recall
Pascal's apology for writing a long letter because he didn't have enough time to write a
short one.
--
Doug McIlroy
Ever since, Unix programmers have maintained a tradition that exalts the elegant over the excessive.
The central tension in the Unix tradition has always been between doing more with less and doing
more with more. It recurs in a lot of different contexts, often as a struggle between designs that
have the quality of clean minimalism and others that choose expressive range and power even at the
cost of high complexity. For both sides, the arguments for or against Emacs have exemplified this
tension since it was first ported to Unix in the early 1980s.
Programs that are both as useful and as large as Emacs make Unix programmers uncomfortable precisely
because they force us to face the tension. They suggest that old-school Unix minimalism is valuable
as a discipline, but that we may have fallen into the error of dogmatism.
There are two ways Unix programmers can address this problem. One is to deny that large is actually
large. The other is to develop a way of thinking about complexity that is not a dogma.
Our thought experiment with replacing Lisp and the extension libraries gives us a new perspective
on the oft-heard charge that Emacs is bloated because its extension library is so large. Perhaps
this is as unfair as charging that /bin/sh is bloated because the collection of all shellscripts
on a system is large. Emacs could be considered a virtual machine or framework around a collection
of small, sharp tools (the modes) that happen to be written in Lisp .
On this view, the main difference between the shell and Emacs is that Unix distributors don't
ship all the world's shellscripts along with the shell. Objecting to Emacs because having a general-purpose
language in it feels like bloat is approximately as silly as refusing to use shellscripts because
shell has conditionals and for loops. Just as one doesn't have to learn shell to use shellscripts,
one doesn't have to learn Lisp to use Emacs. If Emacs has a design problem, it's not so much the
Lisp interpreter (the framework part) as the fact that the mode library is an untidy heap of historical
accretions - but that's a source of complexity users can ignore, because they won't be affected
by what they don't use.
This mode of argument is very comforting. It can be applied to other tool-integration frameworks,
such as the (uncomfortably large) GNOME and KDE desktop projects. There is some force to it. And
yet, we should be suspicious of any 'perspective' that offers to resolve all our doubts so neatly;
it might be a rationalization, not a rationale.
Therefore, let's avoid the possibility of falling into denial and accept that Emacs is both useful
and large - that it is an argument against Unix minimalism. What does our analysis of the
kinds of complexity in it, and the motives for it, suggest beyond that? And is there reason to believe
that those lessons generalize?
[July 15, 1999] Ailanto
Editing & Textprocessing -- very nice collection of links. The author seems to be VI enthusiast.
This collection has a lot more editors listed, that on this Softpanorama page. Suggested by Tom
Moran.
There is A Perfect
Editor by
Bruce Ediger
--- an good bibliography of research papers dealing with editor design, usability, interface, etc.
The author personally prefers Vim ;-)
program.htm
-- Programmer features comparison table. He list several features that are really important
and thus the table can serve as a guide for the selection of the editor
Ctags generates an index (or tag)
file of C language objects found in C source and header files that allows these items to be
quickly and easily located by a text editor or other utility. A tag signifies a C language
object for which an index entry is available (or, alternatively, the index entry created for
that object).
Alternatively, ctags can generate a cross reference file
which lists, in human-readable form, information about the various objects found in a set of
C language files.
Tag index files are supported by the vi editor and its
derivatives
(such as vim, elvis, stevie,
xvi) through the use of the ":ta" command, and by the emacs editor
through the use of the "Meta-." command, both of which locate the object associated
with a name. There are other a number of other editors which support tag files. A list of these
is found here.
The acronym MICO expands to MICO Is CORBA.
The intention of this project is to provide a freely available and fully compliant
implementation of the CORBA 2.2 standard.
MICO has become quite popular as an OpenSource
project and is widely used for different purposes (see our success stories).
Our goal is to keep MICO compliant to the latest CORBA standard. The sources of MICO are placed
under the GNU-copyright notice. The
following design principles guided the implementation of MICO:
start from scratch: only use what standard UNIX API has to offer; don't
rely on propietary or specialized libraries.
use C++ for the implementation.
only make use of widely available, non-proprietary tools.
omit bells and whistles: only implement what is required for a CORBA
compliant implementation.
clear design even for implementation internals to ensure extensibility.
"The comparison of widely varying text editors
has only recently evolved beyond
subjective preference and name-calling."
- Nathaniel S. Borenstein, 1985
The "My editor is better than your editor" argument easily comprises
the longest-running continuous argument in computer programming. One can easily dismiss most
of the common arguments on the topic, since the argument-makers appear ill-informed, no definitions
of terms ever get offered or agreed-upon, hidden assumptions riddle the arguments and subjective
preference carries more weight than experiment. Nevertheless, editor users bring up important
points on ease-of-use, editing power, and what sort of interface an editor possesses. Despite
endless discussion, poorly-formed concepts like "easy",
"powerful", "consistent""intuitive" and their opposites appear in most of the arguments. No
two arguers agree on what the terms mean.
In order to form more perfect arguments, I present a first cut at a bibliography of real
research that seems directed toward finding the perfect editor. I did not perform an exhaustive
literature search, so please inform me of any missing citations.
I'm missing electronically-retrievable forms for almost all of these papers.
***** Anti-Mac -- an
interesting critique of MAC-style graphic interface
WordStar was first released
in 1979, before there was any standardization in computer keyboards. At that time, many keyboards
lacked arrow keys for cursor movement and special function keys for issuing commands. Some even
lacked such keys as Tab, Insert, Delete, Backspace, and Enter.
About all you could count
on was having a standard QWERTY typewriter layout of alphanumeric keys and a Control key. The
Control key is a specialized shift key. When depressed simultaneously with an alphabetic key,
it causes the keyboard to generate a specific command instruction, rather than the letter. The
control codes are named Ctrl-A through Ctrl-Z (there are a few punctuation keys that can generate
control codes, too). Control codes are frequently indicated in text by preceding the letter
with a caret, like so: ^A.
WordStar's original designers,
Seymour Rubenstein and Rob Barnaby, selected five control codes to be prefixes for bringing
up additional menus of functions: ^O for On-screen functions; ^Q for Quick cursor functions;
^P for Print functions; ^K for block and file functions; and ^J for help.
Now, the first
three of these are alphabetically mnemonic. The last two, ^K and ^J, might at first glance seem
to be arbitrary choices. They aren't. Look at a typewriter keyboard. You'll see that for a touch
typist, the two strongest fingers of the right hand rest over ^J and ^K on the home typing row.
WordStar recognizes that the most-often-used functions should be the easiest to physically execute.
To serve as arrow keys
for moving the cursor up, left, right, or down, WordStar adopted ^E, ^S, ^D, and ^X. Again,
looking at a typewriter keyboard makes the logic of this plain. These four keys are arranged
in a diamond under the left hand:
E
S D
X
Such positional, as opposed
to alphabetic, mnemonics form a large part of the WordStar interface. Additional cursor movement
commands are clustered around the E/S/D/X diamond:
W E R
A S D F
Z X C
^A and ^F, on the home
typing row, move the cursor left and right by words. ^W and ^Z, to the left of the cursor-up
and cursor-down commands, scroll the screen up and down by single lines. ^R and ^C, to the right
of the cursor-up and cursor-down commands, scroll the screen up and down a page at a time (a
"page" in the computer sense of a full screen of text).
^Q, the aforementioned
quick-cursor-movement menu prefix, extends the power of this diamond. Just as ^E, ^S, ^D, ^X
move the cursor up, left, right, and down by single characters, ^QE, ^QS, ^QD, and ^QX move
it all the way to the top, left, right, or bottom of the screen. ^W scrolls up one line; ^QW
scrolls up continuously. ^Z scrolls down one line; ^QZ scrolls down continuously. And since
^R and ^C take you to the top and bottom of the screen, ^QR and ^QC take you to the top and
bottom of the document. There are many more ^Q commands, but I think you can see from this sampling
that there is an underlying logic to the WordStar interface, something sorely lacking in many
other programs -- particularly WordPerfect.
Now, for many of these
functions there are dedicated keys on IBM PC keyboards. WordStar allows you to use these, if
you're so inclined. But touch-typists find that using the WordStar control-key commands is much
more efficient, because they can be typed from the home row without hunting for special keys
elsewhere on the keyboard. Because of this, many applications, including dBase, SuperCalc, SideKick,
CompuServe's TAPCIS and OzCis, Genie's Aladdin, Xtree Pro, and even Microsoft's own editor included
with MS-DOS 5.0 and above, have adopted some or all of the WordStar interface.
Some keyboards have the
Control key to the left of the letter A. This makes using WordStar commands very simple.
Other keyboards instead have CapsLock next to the A and place the Control key below the
left Shift key, making WordStar commands a bit of a stretch. Because of this, WordStar comes
with a utility called SWITCH.COM to optionally swap the functions of the CapsLock and Control
keys. One of the problems with other word-processing programs is that many commands can only
easily be issued through function and dedicated cursor keys, and the locations of these keys
changes radically from keyboard to keyboard (for instance, function keys are sometimes arrayed
as two columns of five on the left-hand side of the keyboard and sometimes as a continuous row
across the top of the keyboard; cursor keys are sometimes clustered in a diamond and sometimes
laid out in an inverted-T shape; on laptop computers you may have to press a special "Fn" key
in combination with the arrow keys to access PgUp and other functions, making using these programs
an exercise in contortion). But all one has to do to make any keyboard an optimal WordStar
keyboard is run the CapsLock / Control switcher, if necessary. The locations of the other keys
are irrelevant, because you don't need them for WordStar.
On the other hand, WordPerfect's
interface forces touch typists to constantly move their hands from the home typing row, slowing
them down. To issue a WordPerfect command, you must first press a function key, either separately,
or simultaneously with a Control, Shift, or Alt key. Then, for many functions, you must select
a sub-function. Now that your hands have moved to the bank of function keys, can you select
your sub-function using them as well? You cannot. Rather, you must next reposition your hands
to the numeric keys and select your sub-function by number. Finally, you must re-orient your
hands on the home row before continuing typing (recent versions of WordPerfect attempt to smooth
out this tortuous interface, but it's still difficult to use).
See also:Eastern Orthodox Editors (Xedit/Kedit/THE) are probably
the oldest (Xedit seems to be around on VM/CMS from early 70th) and the most widely used folding editors.
Although it's hard to teach old dog now tricks vim 6.0 will support folding. I consider folding
(actually there are several types of folding -- one is slicing (and in orthodox editors command
All, the other is outlining as implemented in Ms Word and
other word processors and some HTML-editors) an extremely useful feature. Once you have got used to
the folding paradigm, you will not want to use a flat editor again! That's why I consider EOE family
of editors so important.
Franz
J. Kurfess -- Master's Project Topics at NJIT include folding
Developer: Bernhard Lang <lang@tu-harburg.d400.de>
Version: V0.8
Hardware: MSDOS
Languages: All (must allow comment lines)
Formatter: LaTeX
Availability: Anonymous ftp from:
kirk.ti1.tu-harburg.de (134.28.41.50)
/pub/fold2web/readme
/pub/fold2web/fold2web.zip
Readme: In distribution
Description:
The idea behind the Fold2Web tool is the following: A programmer can write his program source with
a folding editor and later map the folded source files automatically to WEB-files. The generated
WEB-files can then be modified by inserting required documentations.
The advantage by starting program developement with original sources is to get short design cycles
during the compile/debug steps. By using a folding editor the global structuring information can
be already captured in folds during this developement phase. Fold information is typically stored
in comment lines and thus will not affect the
efficiency of the compile/debug design cycle.
Some folding editors and a folding mode for the emacs are available (e.g. see our FUE folding editor
for MSDOS machines which is a modified micro emacs. Pick it at kirk in directory /pub/fold2web).
After reaching a stable version of a program source its time to convert the source file to a WEB-file
and do the program documentation. Fold2Web is written to convert folded source text of any programming
language to nuweb files. The folded structure is kept by mapping folds to scraps. Fold markers which
differ between languages due to different ways of specifying comments can be configured for each
language.
Good results can also achived when given but poor documented program sources have to be modified.
Such sources can be folded using a folding editor to extract the global structures. This offers
a global view tothe program structures and help to understand its functionality. Furthermore the
program code is not affected, only comment lines are
inserted. Once folded the program source can be automatically translated to a WEB document using
the above tool.
After working with Origami for many years, both as user and developer, I have
decided to implement a new folding editor: fe. There are a few basic design decisions which make
it different from Origami:
Origami is partially written in its extension language. While being more of a
hack in the beginning, it has changed to a full programming language. As such, it takes time to
be learnt. Code written in it is not well usable by most people who don't know it. The conclusion
for fe is not to support any extension language, neither a homebrew one or a standardised language,
like scheme. Instead, fe is implemented as a library of basic editor primitives. Its is easy to
write your own editor by using that library. fe can be modified easy without having to learn a new
programming language. The editor also stays small and elegant this way, while Origami has to offer
zillions hooks for extension functions.
Origami implements folds as double-linked n-trees, with nodes being single lines
or folds. This allows quick manipulation of folds or lines. But region oriented functions become
hard to implement and are mostly not too quick any more. fe uses a gap buffer to store text, folds
are represented as meta-characters in the flat buffer. This means basic fold primitives are slower
than in Origami, but more complex and region oriented functions are faster. During development of
the first prototype of fe, I found many functions in Origami not to be as canonical as they should
be after I implemented them in fe. From my past experience, the performance of typical personal
computers to have increased by a factor of 10 every 5 years in the last decade, so the circumstances
for editor design have clearly changed over time.
Folding has its merits, because it adds a structure to flat files. But,
it also means that by bad structure design and badly commented folds the file will get harder to
understand, not easier. This can happen up to the point where you want all folds to be gone to see
what the file contains. If you need to keep many folds open during development to see their
contents, you are probably preparing that situation at least for others. Although in general I don't
like programs forcing me to do something, fe makes an exception here for two reasons: If the structure
is obvious, you want the editor to close folds for you automatically. If it is not, you
want to recognize that before it is too late. For that reason, fe closes all folds when you
leave them. If you want to transport code from one fold to another, just split the current display
and edit the file at two places. If both places are sufficient far away from each other, that's
what you even had to do if you could leave folds open. \"}}}
Most folding capabilities in editors such as
GNU Emacs and most folding
editors such as Origami and fe, are inspired by the Inmos Transputer Development System. After several
years, folding/outlining capabilities in text editors are not as exotic as they used to be, but
they are still far from being well known. This document explains what "folding" is all about.
A folding editor extends the principle of tree structured directories to editing
text files. This allows the simultaneous display of large amounts of text by folding sections of
text away behind a descriptive heading. This results in a tree structure very similar to a subdirectory
structure of, for example, UNIX. By suitable structuring of a text it should be possible, in most
circumstances, to ensure that no display exceeds a single screen at any time. To access text that
is folded away, you open the fold, in which case the contents are displayed in context of the surrounding
text. The advantage of this system is that it eliminates the need for seemingly endless paging through
long files to find the section of interest, allowing you to move down the tree structure, following
the (hopefully) descriptive headers to locate the text you require.
Hybris -- a very interesting
implementation of scrollable nesting -- it's actually more looks like outlining, but probably can be
used for folding. anyway this is something new and no other editor seems to be able to do the same trick.
Fe User Guide -- A Folding
Editor, which aims to be fast and small.
After working with Origami for many years, both as user and developer, I have
decided to implement a new folding editor: fe. There are a few basic design decisions which make
it different from Origami:
Origami is partially written in its extension language. While being more of a
hack in the beginning, it has changed to a full programming language. As such, it takes time to
be learnt. Code written in it is not well usable by most people who don't know it. The conclusion
for fe is not to support any extension language, neither a homebrew one or a standardised language,
like scheme. Instead, fe is implemented as a library of basic editor primitives. Its is easy to
write your own editor by using that library. fe can be modified easy without having to learn a new
programming language. The editor also stays small and elegant this way, while Origami has to offer
zillions hooks for extension functions.
Origami implements folds as double-linked n-trees, with nodes being single lines
or folds. This allows quick manipulation of folds or lines. But region oriented functions become
hard to implement and are mostly not too quick any more. fe uses a gap buffer to store text, folds
are represented as meta-characters in the flat buffer. This means basic fold primitives are slower
than in Origami, but more complex and region oriented functions are faster. During development of
the first prototype of fe, I found many functions in Origami not to be as canonical as they should
be after I implemented them in fe. From my past experience, the performance of typical personal
computers to have increased by a factor of 10 every 5 years in the last decade, so the circumstances
for editor design have clearly changed over time.
Folding has its merits, because it adds a structure to flat files. But, it also
means that by bad structure design and badly commented folds the file will get harder to understand,
not easier. This can happen up to the point where you want all folds to be gone to see what the
file contains. If you need to keep many folds open during development to see their contents, you
are probably preparing that situation at least for others. Although in general I don't like programs
forcing me to do something, fe makes an exception here for two reasons: If the structure is obvious,
you want the editor to close folds for you automatically. If it is not, you want to
recognize that before it is too late. For that reason, fe closes all folds when you leave them.
If you want to transport code from one fold to another, just split the current display and edit
the file at two places. If both places are sufficient far away from each other, that's what you
even had to do if you could leave folds open.
This editor was designed as a language configurable
folding
source code editor. A page describing the
concepts
involved is provided, and also a full list of all the
editing primitives
supported, with an
index for
speed.
This editor provides these features :
Folding, the ability to group lines into a larger 'meta-line'.
FOR THE REST OF THE WORLD, XYWRITE IS HISTORY --
BUT TO ITS DEVOTEES, THE ANTIQUATED WORD PROCESSOR STILL RULES.
Not long ago, a writer friend and I were talking software (there's
a sentence I never thought I'd write) -- specifically whether we were Luddites for resisting a Windows
98 upgrade. Well, she said, she hardly felt out-of-date, since most of her publishing-world friends
were still using XyWrite. I was stunned. I hadn't even heard the name in years, and suddenly I'd
learned that, in a world in which six months is a generation, there lingered a dedicated cadre of
loyalists to a program that hasn't been upgraded since 1993, that still runs best in DOS, that isn't
compatible with most printers, and that has all but vanished as a commercial product. It was like
finding out that a cargo cult was operating down the hall from my apartment.
For those of you unfamiliar with XyWrite -- the "GOD of word processors," as one poster to alt.folklore.computers
recently put it -- the program was an offshoot of ATEX, which in the '80s was the standard in newspaper
and magazine editorial hardware and software. It was created in 1982 by an ATEX programmer named
David Erickson, who'd bought a PC and was unhappy with the word processor that came with it. So
Erickson decided to write his own, and not long after he and another employee left ATEX to set up
shop as XyQuest.
XyWrite was fast, it could do things no other word processor at the time could (like open two
windows simultaneously), and because of the nature of the underlying programming language, XPL,
it could be endlessly customized. The screen was a blank page with a command line at the top (hitting
F5 would take you there), and when you wanted XyWrite to do something, you simply typed in an English-language
command (such as "print" to print a file) or used one of your own custom keystrokes to carry out
the task. It was defiantly not a "what you see is what you get" program, but it was extremely transparent,
with all the formatting information easily viewable. And it was an instant hit among professional
writers and editors, many of whom, um, borrowed their copies from their employers on a single 5
1/4-inch floppy -- mine, I confess, came from New York magazine, circa 1984.
Nancy Friedman was editorial director at Banana Republic when the clothing retailer started using
XyWrite (version 2). "I loved it," says Friedman. "All of a sudden I was using this program that
thought the way a writer thinks. All other word processing programs were created for secretaries
-- they're all about creating standard one page documents. This one really expected that I was doing
sophisticated editing and writing."
High-profile devotees included television's Brit Hume, John Judis of the New Republic and high-tech
guru
Esther Dyson. Critics called it the "Porsche 911 Carrera" or the "velociraptor" of word processors.
And as much as they admired the software, users also loved the scrappy, down-home nature of the
company: Erickson would sometimes answer tech support calls himself, and XyQuest was headquarted
in decidedly unglamorous Billerica, Mass. "I was always so happy driving through Billerica knowing
they were working to update XyWrite," remembers one writer who had occasion to pass through town
in XyWrite's heyday. "It sounds so dopey, but that's how it was."
But XyQuest's marketing was never as good as its software, and it lacked the resources to compete
with the big boys -- like WordPerfect, which the XyWrite faithful held in contempt. Then, in early
1990, IBM stepped in. The computer giant announced it was hooking up with XyQuest to create a new
product, called Signature, based on the XyWrite model, and it looked like XyWrite was about to join
the commercial mainstream. Instead, IBM delayed the product for a year and a half -- then, with
boxes printed and diskettes ready to go, decided it was getting out of the software business altogether.
A reconstituted XyQuest tried to sell the program on its own (renamed XyWrite 4), simply slapping
stickers over the IBM logos on the boxes, says Tim Baehr, then a XyQuest programmer. But "sales
just got lower and lower. We were bleeding money."
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
in our efforts to advance understanding of environmental, political,
human rights, economic, democracy, scientific, and social justice
issues, etc. We believe this constitutes a 'fair use' of any such
copyrighted material as provided for in section 107 of the US Copyright
Law. In accordance with Title 17 U.S.C. Section 107, the material on
this site is distributed without profit exclusivly for research and educational purposes. If you wish to use
copyrighted material from this site for purposes of your own that go
beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no
less then 90 days. Multiple types of probes increase this period.
The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to make a contribution, supporting development
of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with.We do not warrant the correctness
of the information provided or its fitness for any purpose.
Softpanorama
Posted in Vim Tagged command line , option , splits , start , tabs
