Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Orthodox Editors as a Special Class of Advanced Editors

News Introduction to Orthodox Editors Recommended Links

Recommended Articles

Eastern Orthodox editors Western Orthodox Editors (VIM)

Beautifiers and Pretty Printers

Folding Slicing Outlining Ctags Regex PC-style text editors for Unix Light-weight win32 Editors
VIM Slickedit FTE Mcedit -- Midnight Commander’s Editor LE - Lukyanov Editor jed Html editors
GUI-based programmable Programmable Word processors HTML programmable History Random Findings Humor Etc

The introductory paper Orthodox Editors introduced 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:

We define the notion of  "orthodox editors" as having the following distinct features:

  1. 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. 
  2. 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)
  3. 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. 
  4. They support folding (all command in XEDIT and its derivatives; folding capabilities in VIM )
  5. They distinguish between editing buffer and the windows in which this editing buffer is displayed allowing multiple windows to display the same buffer.
  6. They support regular expressions
  7. They permit processing selected part of the editing buffer or all the buffer via pipe connected to external command (! command in vi)
  8. They support multiple views of the same editing buffer.
  9. 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: 

This paper explores two sets of  deep interconnections that were previously unnoticed in the literature:

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.

Read more

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 

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. 

Read more

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.


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

2004 2003 2002 2001 2000 and earlier

[Nov 01, 2017] Vim character info by Tom Ryder

Mar 31, 2013 | sanctum.geek.nz

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:

< -- > 8212, U+2014 EM DASH, ^K-M, &mdash;

Or a COPYRIGHT SYMBOL:

<©> 169, \251, U+00A9 COPYRIGHT SIGN, ^KCo, ^KcO, :copyright:, &copy;

Or as one of the eyes in a look of disapproval:

<ಠ> 3232, U+0CA0 KANNADA LETTER TTHA

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.

[Nov 01, 2017] Bash prompts by Tom Ryder

Jul 09, 2012 | sanctum.geek.nz

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:

-(23:38:57)-(4 users)-(0.00, 0.02, 0.05)-
-(Linux sanctum 3.2.0-3-amd64 x86_64 GNU/Linux)-
[tom@sanctum:/dev/pts/2:/home/tom]{2}!?[MAIL]$

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:

tom@sanctum:~$ PS1=bash-"$PS1"
bash-tom@sanctum:~$

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:

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:

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:

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:

color_red='\[\e[31m\]'
color_blue='\[\e[34m\]'
color_reset='\[\e[0m\]'

PS1=${color_red}'\u'${color_reset}'@'${color_blue}'\h'${color_reset}

A more robust method is to use the tput program to print the codes for you, and put the results into variables:

color_red=$(tput setaf 1)
color_blue=$(tput setaf 4)

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) :

$ PS1='[$(uptime) ]\$ '
[ 01:21:59 up 7 days, 13:04,  7 users, load average: 0.30, 0.40, 0.36 ]$

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:

$ PS1='[$(uptime | cut -d: -f5) ]\$ '
[ 0.36, 0.34, 0.34 ]$

For clarity, during prompt setup in .bashrc , it makes sense to use functions instead for reasonably complex commands:

prompt_load() {
    uptime | cut -d: -f5
}
PS1='[$(prompt_load) ]'$PS1

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.

[tom@conan:~/.dotfiles](git:master!)$
[tom@conan:~/Build/tmux](svn:trunk)$
[tom@conan:~/Build/vim](hg:default!)$

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:

prompt_on() {
    PS1="$color_prompt"'\u@\h:\w'"$(prompt_jobs)"'\$'"${color_reset}"' '
}
prompt_off() {
    PS1='\$'
}
prompt_on

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.

[Nov 01, 2017] Actually using ed by Tom Ryder

Notable quotes:
"... 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. ..."
Jun 17, 2012 | sanctum.geek.nz

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.

[Nov 01, 2017] Advanced Vim registers by Tom Ryder

Oct 24, 2012 | sanctum.geek.nz

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:

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:

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.

Knowing your registers well isn't as profound a productivity boost as squelching a few of the other Vim anti-patterns , but it can certainly save you some of the annoyance of lost text. Posted in Vim Tagged advanced , black hole , expression , named , numbered , read-only , registers , unnamed Start Vim with splits Posted on September 11, 2012 by Tom Ryder If you want to call Vim to edit more than one file, you can add an option to the command line to open all of the buffers in split windows on startup:

Command line splits

The same can also be done for tabs:

Command line tabs Posted in Vim Tagged command line , option , splits , start , tabs

[Oct 31, 2017] Vim filename completion

Oct 31, 2017 | sanctum.geek.nz

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 .vimrc consistent 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:

inoremap <Tab> <C-X><C-F>

[Oct 31, 2017] Safely editing as root

Oct 31, 2017 | sanctum.geek.nz

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.

[Oct 31, 2017] Faster Vim search/replace by Tom Ryder

Apr 29, 2012 | sanctum.geek.nz

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 # .

[Oct 31, 2017] Advanced Vim macros by Tom Ryder

Notable quotes:
"... macros are just text ..."
"... 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. ..."
Jun 04, 2012 | sanctum.geek.nz

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:

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:

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

[Oct 31, 2017] Local .vimrc files by Tom Ryder

May 26, 2012 | sanctum.geek.nz

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.

[Oct 31, 2017] Vim eval feature by Tom Ryder

Jul 19, 2012 | sanctum.geek.nz

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:

#ifndef FEAT_EVAL
# define ex_scriptnames     ex_ni
# define ex_finish      ex_ni
# define ex_echo        ex_ni
# define ex_echohl      ex_ni
# define ex_execute     ex_ni
# define ex_call        ex_ni
# define ex_if          ex_ni
# define ex_endif       ex_ni
# define ex_else        ex_ni
# define ex_while       ex_ni
# define ex_continue        ex_ni
# define ex_break       ex_ni
# define ex_endwhile        ex_ni
# define ex_throw       ex_ni
# define ex_try         ex_ni
# define ex_catch       ex_ni
# define ex_finally     ex_ni
# define ex_endtry      ex_ni
# define ex_endfunction     ex_ni
# define ex_let         ex_ni
# define ex_unlet       ex_ni
# define ex_lockvar     ex_ni
# define ex_unlockvar       ex_ni
# define ex_function        ex_ni
# define ex_delfunction     ex_ni
# define ex_return      ex_ni
# define ex_oldfiles        ex_ni
#endif

[Oct 31, 2017] Vim misconceptions by Tom Ryder

Jul 19, 2012 | sanctum.geek.nz

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:

To do pretty much everything Windows Notepad would let you do, on top of that you'd only need to learn:

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.

[Oct 31, 2017] Vim annoyances by Tom Ryder

Notable quotes:
"... Several of these fixes were inspired by Steve Losh's .vimrc file . Thanks also to commenters Alpha Chen and Rob Hoelz for suggestions. ..."
Aug 02, 2012 | sanctum.geek.nz

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:

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.

[Oct 31, 2017] Shell from vi by Tom Ryder

Feb 18, 2017 | sanctum.geek.nz

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:

:exe "!gcc " . shellescape(expand("%")) . " -o foo"

The Vim help for this is at :help :! .

Reading the output of commands into a buffer

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 :

#!/usr/bin/awk -f
{ print toupper($0) }

Or Perl :

#!/usr/bin/env perl
print uc while <>;

Or Python, or Ruby, or Rust , or

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:

*1,2w !upp > tmp
*1,2d
*0r tmp
*!rm tmp

[Oct 31, 2017] Vim search highlighting by Tom Ryder

Jan 21, 201 | sanctum.geek.nz

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.

nnoremap <leader>i :set incsearch!<CR>
nnoremap <leader>h :set hlsearch!<CR>

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:

autocmd InsertEnter * :setlocal nohlsearch
autocmd InsertLeave * :setlocal hlsearch

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.

[Oct 31, 2017] Buffers, windows, and tabs by Tom Ryder

Notable quotes:
"... open instance of a file ..."
"... viewport onto a single buffer ..."
"... collection of one or more windows ..."
"... Thanks to Hacker News users anonymous and m0shen for pointing out potential confusion with the :set hidden option and the :bdelete command. ..."
Jan 22, 2012 | sanctum.geek.nz

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.

Windows in Vim

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 .

Tab usage in Vim

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.

[Oct 31, 2017] Vim command window by Tom Ryder

Feb 05, 2012 | sanctum.geek.nz

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:

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

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

Vim search window

For more information on how the command window works, check out :help command-line-window .

[Oct 31, 2017] Vim anti-patterns by Tom Ryder

Feb 07, 2012 | sanctum.geek.nz

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.

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 :

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:

y/search<Enter>
y?search<Enter>
d/search<Enter>
d?search<Enter>
c/search<Enter>
c?search<Enter>
Searching for the word under the cursor

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:

noremap <Up> <nop>
noremap <Down> <nop>
noremap <Left> <nop>
noremap <Right> <nop>

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.

[Oct 31, 2017] Debugging Vim setup by Tom Ryder

Oct 31, 2017 | sanctum.geek.nz

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:

:scriptnames
1: /usr/share/vim/vimrc
2: /usr/share/vim/vim73/debian.vim
3: ~/.vimrc
4: ~/.dotfiles/vim/autoload/pathogen.vim
...

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:

:so plugin/fugitive.vim
:so plugin/unimpaired.vim
:so plugin/badplugin.vim
Profile startup time

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.

[Oct 07, 2017] 4 Best Modern Open Source Code Editors For Linux

Notable quotes:
"... 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. ..."
Oct 07, 2017 | itsfoss.com

4 Best Modern Open Source Code Editors For Linux

Last updated October 5, 2017 By Abhishek Prakash 47 Comments

Share 1K Tweet 27 +1 165 Share 39 Reddit Shares 2K

Best code editors for Linux

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 one of the best open source code editors

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:

You can get the source code as well as binaries for Linux, OS X and Windows on its website.

Get Brackets

2. Atom

Atom is considered to be an excellent code editor for Linux

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:

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.

Get Atom

3. Light Table

Light Table is the next generation open source code editor for Linux

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:

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.

Get Light Table

4. Visual Studio Code

Microsoft Visual Studio Code has been deemed as the best code editor for web development

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:

You can download packages for Ubuntu and Fedora from its website:

Get Visual Studio Code

What's your pick?

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

by Newest
by Best by Newest by Oldest
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.

There is also Anjuta IDE as well.

Note above that I said Komodo IDE not Komodo Edit. Also note that the IDE is not free.

3:56 pm August 9, 2016 David Dreggors Netbeans, Eclipse, Geany, and even Komodo IDE all work on Linux (even Ubuntu)
2:12 pm February 25, 2016 Shan You can use Geany Editor
9:44 pm February 16, 2016 Old Fart VIM is too recent. VI for old school.
6:11 am April 13, 2017 Compro Prasad Try neovim man
1:22 am January 31, 2016 Marek Komodo Edit is the best. For me. Great performance, addons, etc.
8:03 pm December 10, 2015 Snehal Vim.. anyday..
2:54 pm October 24, 2015 Dhruman Bhadeshiya Love, Atom!!
2:27 am October 9, 2015 Muhammad Dary Azhari i choose gedit
5:49 pm October 7, 2015 Airon +1 to Atom! GitHub team have done good work! (y)
Author
12:12 pm October 28, 2015 Abhishek Prakash Indeed
1:21 pm September 10, 2015 Lokesh sanapalli In atom, there is no option to execute the code. Geany is much better than these!!!
Author
1:44 pm September 10, 2015 Abhishek Prakash It's because Geany is more of an IDE than code editor.

[Mar 03, 2017] How to Make Vim Editor as Bash-IDE Using bash-support Plugin in Linux

Notable quotes:
"... 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: ..."
Feb 20, 2017 | www.tecmint.com

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.

curl http://www.vim.org/scripts/download_script.php?src_id=24452 >bash-support.zip 

How To Use Run Operation in Vi Editor

The following is a list of some run operations key mappings:

\rr – update file, run script (n, I)
\ra – set script cmd line arguments (n, I)
\rc – update file, check syntax (n, I)
\rco – syntax check options (n, I)
\rd – start debugger (n, I)
\re – make script executable/not exec.(*) (in)

Make Script Executable

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.

[Aug 01, 2014] Comparison Linux Text Editors

Slashdot

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."

Replacing KEdit by UltraEdit - any thoughts?

This forum is user-to-user based and not regularly monitored by IDM.
Please see the note at the top of this page on how to contact IDM.

Re: Replacing KEdit by UltraEdit - any thoughts?

by rhapdog " Tue Feb 14, 2012 9:34 pm

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.


Re: Replacing KEdit by UltraEdit - any thoughts?

by billdehaan " Wed Feb 15, 2012 12:21 am

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.
Kedit is considered Eastern Orthodox, UE seems more Western Orthodox (http://www.softpanorama.org/Editors/eoe.shtml).

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.
Probably true. It certainly seems more verbose.

Compare

Code: Select all
UltraEdit.document[index].top();
UltraEdit.document[index].write("// Script Name: ");

to
Code: Select all
'top'
'text // Script Name: '
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.

Re: Replacing KEdit by UltraEdit - any thoughts?

by rhapdog " Wed Feb 15, 2012 10:03 am

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.
billdehaan wrote: 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.

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.

Seriously, take a good look at the UE/UES comparison before you make a final decision.
http://www.ultraedit.com/products/uestu ... ences.html

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.

An excerpt from http://www.softpanorama.org/Articles/or ... tors.shtml
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).


That is good advice for anyone.

Re: Replacing KEdit by UltraEdit - any thoughts?

by billdehaan " Wed Feb 15, 2012 7:01 pm

...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.


Re: Replacing KEdit by UltraEdit - any thoughts?

by rhapdog " Wed Feb 15, 2012 10:59 pm

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.

LE - Lukyanov Editor

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 – Freecode

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.

[Nov 23, 2012] Highly programmable non-Emacs editor?

December 24, 2003 | http://www.fogcreek.com/
Junkster

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.

[Mar 06, 2011] How many other editors in use - comp.editors Google Groups

DMcCunney: Apr 27 2009, 12:15 pm

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

JussiJ wrote: > On Apr 3, 9:01 am, Chetan <chetan.xs...@xspam.sbcglobal.net> wrote:

I am surprised to find that most of the posts here are about vi or vim. Aren't there other editors (besides the ones that have their own groups) that people use?

> 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!

Aaron W Hsu

> Chetan <chetan.xs...@xspam.sbcglobal.net> writes:

>>I am surprised to find that most of the posts here are about vi or
>>vim. Aren't there other editors (besides the ones that have their own
>>groups) that people use?

> As has already been mentioned, many other editors have their own lists
> or groups to which people post. However, I myself regularly switch
> between using Vi and NEdit. On Windows I use Boxer Text Editor, and
> on Mac I often use BBEdit.

> If you want to have a general discussion about text editors, I'd be
> happy to read it. :-)

I think the reason most questions are about vim is because other editors
don't provide so many "hidden" tricks" or offer so much functionality.
I use vim and occasionally emacs, but in different contexts: I prefer
vim for config file editing but emacs for email and longer works. But
in GUI environments I mostly enjoy jedit, a java editor that works
equally well on every platform I use - that's handy. I carry my macros
and config files on a USB key and can instantly work the way I like to
on any machine I use. I also find it easier to customize than emacs,
whose lisp I've never really gotten the hang of.

But if I don't post any questions about jedit here it's because it's been pretty easy to figure out and I haven't got any questions to ask. Still, I think a comp.editors.vim group would be appropriate, since the emacites have a separate group.

For the record, I, too, like switching around my editors from time to time, but mostly because it's fun to learn new software. I've used jed, and joe as well: they're fun for what they are. Joe is actually good on usenet because it defaults to hard wrapping, something I want on usenet but don't want on longer works. (yeah yeah yeah, vim and emacs can do that too. I get it, I get it).

Cheers.
--
http://www.therandymon.com

DMcCunney: Apr 18 2009, 11:58 am

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.

______ Dennis

[Mar 05, 2011] would like a recipe to pull down a free online book - 2

10-09-2010 | MobileRead

DMcCunney

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.

Dennis

[May 9, 2008] What is a folding editor

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.

[May 9, 2008] Code Browser - A Folding Text Editor

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.

freshmeat.net Project details for Cooledit

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

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.

ConText Editor

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 User-friendly Text 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

Linux.com Some Linux apps are small wonders

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 !!!

e3 text editor

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.

Exuberant Ctags Version 5.5.2 [17 September 2003]

[Sept 12, 2003] The Right Size for an Editor

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 :-).

Is Emacs an Argument against the Unix Tradition?

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 vastness of Emacs, on the other hand, did not originate under Unix, but was invented by Richard M. Stallman within a very different culture that flourished at the MIT Artificial Intelligence Lab in the 1970s. The MIT AI lab was one of the wealthiest corners of computer-science academia; people learned to treat computing resources as cheap, anticipating an attitude that would not be viable elsewhere until fifteen years later. Stallman was unconcerned with minimalism; he sought the maximum power and scope for his code.

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?

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Top articles

Sites

See also

Top

Design issues:


Articles

The Craft of Text Editing by Craig A. Finseth -- free e-book

Preface
Introduction: What Is Text Editing All About?
Chapter 1: Users
Chapter 2: User Interface Hardware
Chapter 3: Implementation Languages
Chapter 4: Editing Models
Chapter 5: File Formats
Chapter 6: The Internal Sub-Editor
Chapter 7: Redisplay
Chapter 8: User-Oriented Commands: The Command Loop
Chapter 9: Command Set Design
Chapter 10: Emacs-Type Editors
Epilogue
Appendix A: A Five-Minute Introduction to C
Appendix B: Emacs Implementations
Appendix C: The Emacs Command Set
Appendix D: The TECO Command Set
Appendix E: ASCII Chart
Bibliography
Book Index


Folding

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

comp.programming.literate FAQ

9.5. Fold2Web

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.

Illustrative Browsing A New Method of Browsing in Long On-line Texts

Fe User Guide

A few words on the design of fe

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. \"}}}

Richard King Home Page

Published Papers

A user interface for a multi-user folding editor

Animation techniques for folding editors

Masters Thesis

What is a folding editor -- not very correct, but still interesting discussion

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.

Internet Parallel Computing Archive Tools Editors Folding-editors -- links to several implementations

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.

GRASP Graphical Representations of Algorithms Structures and Processes -- the idea of syntax diagrams

JED -- the latest version has folding

Internet Parallel Computing Archive Tools Editors Folding-editors -- I believe that folding is a must for any editor. Here we have slightly outdated and incomplete collection of relevant links.

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.

Andys Source Code Folding Editor -- a language configurable folding source code editor


History

Salon 21st The Xy files BY AMY VIRSHUP |

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."

Random Findings

...



Etc

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.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

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.

Last modified: November 08, 2017