
Ditching tmux - tetraodonpuffer
http://hkupty.github.io/2016/Ditching-TMUX/
======
andrewstuart2
I discovered i3 and the concept of tiling window managers a few years ago and
have never looked back. A new terminal or browser window is always a keystroke
away, as is swapping between "pages" of windows. It's all navigable completely
by keyboard, so my vim/i3/dmenu editing environment has me very rarely
touching the mouse. As an added bonus I get to use every part of the screen by
default. No wasted space.

It's also pretty trivial to get some nice window arrangements so that I can
quickly move to relevant parts of the code for whatever I'm working on.

I guess the major trade-off is that there aren't any menus for accessing
functionality, but I personally consider that a win because I end up being
forced to learn how to manage everything at the lowest config level, usually
editing text files. This makes it vastly easier to script things when I
realize I've been making the same changes over and over.

So if you like tmux and you're on Linux, I'd strongly recommend giving i3,
awesome, or some other TWM a try.

~~~
bphogan
Agree 100%. And I wrote a book on tmux. I would love something like i3 on my
Mac. I can't give up OSX because I need its accessibility features because I'm
low vision.

But if you're on Linux and you're not using i3, gosh, you have to give it a
try.

~~~
microcolonel
I'm interested in accessibility; what accessibility features of OS X are most
valuable to you? Where are these things lacking or unavailable on linux?

~~~
bphogan
OSX has an unbeatable ability to zoom the full screen without losing mouse
focus. No other OS I've tried supports this. Windows Magnifier comes close but
it doesn't let me set focus to follow the mouse and it's awkward.

I use the full screen zoom and run Windows apps in virtualization. That's how
important it is to me.

Ubuntu tried to make this work with Compiz a few years ago, and it was
terrible as well. Slow and jerky.

But this is an absolute necessity for a low vision user like me. Got a Mac for
my dad and he also can't live without it now.

~~~
microcolonel
Hopefully with Wayland coming around, this will all be simpler. The reference
Wayland compositor (Weston) has a built in fullscreen zoom feature which is
basically identical to OS X's (hold down key, scroll).

In fact, the default implementation in Weston is, better in my opinion, and
also enabled by default. Instead of having to go to the edge of the screen to
move the region, it moves the region with the cursor in the same position
relative to the screen as the region. Of course, for those with dyslexia or
some other psychovisual disability; it may be worthwhile to have an option to
go the OS X route.

Thanks for the input, I'll maybe put it on the GNOME bugzilla if it isn't
already there. :-)

~~~
bphogan
The OSX zoom has the option to follow the mouse and is what I use (and
require) so I can track what I'm reading. It's not default, but it exists and
works incredibly well even under heavy graphics use. Seeing something like
that work well on something other than OSX would be great. But every other
attempt has bee spotty at best.

I look forward to seeing this work, but I worry about the hardware
requirements that will be imposed.

I have a 2007 white macbook that zooms flawlessly. If I need a high-end video
card to zoom as smoothly it will be a problem.

~~~
microcolonel
For some information, it is unfailingly buttery smooth even on integrated
graphics hardware from one generation before Intel HD graphics. I.e. a lenovo
Core Duo machine from 2006 I dug out of my closet the other month. This is all
probably thanks to Wayland being properly composited to begin with; they just
need to scan out part of the final framebuffer texture.

~~~
bphogan
This is really exciting. Link me to more information please?

------
vbezhenar
My main complain about tmux is that it messes with my terminal emulator scroll
buffer. I like to use a mouse to scroll my terminal emulator. For example I
can do `cat file` and then scroll around. If file is huge, `less` is better,
of course, but for most things terminal scrolling is perfect. But `tmux` and
`screen` completely ruin that experience. I know that they have their own
scrollbuffer and scroll mode and all that, but I've found that perfect user
experience for me is to blend GUI approach and text mode approach instead of
replacing it.

~~~
rhinoceraptor
I have my tmux set up as you describe, it's easy to do.

In newer versions of tmux, you just add 'set -g mouse on' to your
~/.tmux.conf. I also have copy mode set to use vi keybindings, and I can yank
to the system clipboard.

~~~
elliotec
It doesn't seem to be as simple for cross platform support, I have had to use
different settings for Linux and OSX

~~~
tomsthumb
Care to share those settings?

------
zeveb
At some point, neovim is going to have every feature of emacs, only with fewer
decades of testing and written in a worse language.

~~~
gecko
I love Emacs, and I've used it for years, but this is an insanely unfair
summary.

NeoVim can be trivially extended in any language. They're putting a _lot_ of
effort into making sure that the msgpack protocol supports basically
everything. This means that, unlike in Emacs, it's straightforward to write
extensions in whatever language is best for the job--something really, really
important when it comes to language bindings themselves, which is probably the
_main_ thing I frequently find myself extending in Emacs in the first place.
So saying it's written in a worse language seems bizarre to me.

NeoVim also, unlike Emacs, is cleanly split into a frontend and a backend so
that its editing core can be used in different contexts. Combined with the
above, that means you will eventually (hopefully) be able to get "the real"
NeoVim in lots of apps, rather than either a kind of broken "Emacs mode" (like
in IntelliJ, NetBeans, and Emacs) or having to do this weird "save a text blob
to disk, open in Emacs, wait for it to be closed, reload in the app" dance.
Already, this separation has allowed the creation of NyaoVim
([https://github.com/rhysd/NyaoVim](https://github.com/rhysd/NyaoVim)), a
browser-based front-end that I could imagine being incredibly useful for
remote editing, whether in a cloud-like environment (e.g. Cloud9,
CodeAnywhere) or on a remote server.

Emacs is great. NeoVim is also heading in an excellent direction. You don't
have to give it a chance, but you also don't need to be so dismissive.

~~~
Scarbutt
* it's straightforward to write extensions in whatever language is best for the job--something really*

Although this is great, this sounds like it can cause a lot fragmentation,
everyone writing plugins with their favorite language and consumers having to
deal with the pain of multiple runtimes.

Is there a preferred language endorsed by the project?

~~~
oblio
Lua, I think.

------
cm3
If your primary use wasn't the background/attach feature, sure this will work
as will many other mechanism. I know like many users my main motivation is not
losing the terminal session when (not if) X or Wayland crashes.

~~~
na85
My thoughts exactly.

In fact I'd go so far as to say if you aren't using it for the attach/detach
functionality why on earth would you bother? I'm not seeing how using tmux
beats "Just open another terminal" which is the absolute minimum.

Surely anyone doing dev work is using an editor that supports tabbing and in-
editor consoles a la emacs.

~~~
carussell
Most of the other features that both screen and tmux include give me reason
enough not to use either one. If you're just in it for the detachability, see
dtach. <[http://dtach.sourceforge.net/>](http://dtach.sourceforge.net/>)

Some people like split panes, though.

~~~
cm3
tmux and screen make it comfortable to manage multiple sessions. That's why I
don't just use dtach. Having one session with multiple buffers/windows is
easier to manage than one file for each dtach'ed program. Basically, I'd have
to script my way out of dtach's bare bones session management feature set.

I don't really use tmux's or screen's split functionality, and if I did I'd
probably start using [http://www.brain-
dump.org/projects/dvtm/](http://www.brain-dump.org/projects/dvtm/). Hmm,
abduco seems like dtach on stereoids and is thankfully separate from dvtm and
required for detaching dvtwm sessions. Maybe I should give that a try.

~~~
qu4z-2
I would recommend abduco+dvtm. That's where I've ended up. Then again, I'm
biased in favor of suckless-brand things.

I also somehow configured abduco to always start a dvtm instance inside it, so
there's no pain from it being two separate programs.

------
klinquist
I'm significantly more productive with tmux + autossh. I autossh into a single
server from which I have about 30 SSH sessions open - organized by environment
(tmux sessions) and host (tmux windows). The windows have the name of the
host. I rarely use my number keys - I just shift-left arrow or shift-right
arrow to the previous/next window since jumping around is so quick.

tmux-resurrect is awesome too - if the server I autossh into reboots, I can
just restore all my sessions and windows and it re-sshs into the 30 hosts.

~~~
nilkn
I have almost this exact same setup, except I use tmuxinator instead of tmux-
resurrect. Honestly tmux-resurrect looks like it's the better solution; I just
haven't bothered trying it out.

------
falcolas
Simply replacing tmux with the same inside NeoVim doesn't feel like a win to
me. Tmux is very powerful (providing for decent nesting with remote servers),
and until NeoVim reaches Emacs levels of configurability and extensibility, I
don't see it being a viable replacement anytime soon.

~~~
dguaraglia
Yeah, I can't see how I'd replace persistent sessions on remote servers with
this. I could see it working as a quick and dirty way to switch between my
editor and command line, but I've always been a bit skeptical of terminals
running under editors (they tend to lock up the whole process the moment you
have heavy logging.)

------
badosu
I highly recommend using dvtm instead: [http://www.brain-
dump.org/projects/dvtm/](http://www.brain-dump.org/projects/dvtm/)

And for session management, abduco: [http://www.brain-
dump.org/projects/abduco/](http://www.brain-dump.org/projects/abduco/)

~~~
chriswarbo
Personally I've had this combo segfault a couple of times in the past year or
so, which never happened with screen or tmux. I've been using dvtm+dtach for a
while now and had no problems.

abduco also used to leave cruft around if it didn't shut down cleanly (e.g.
laptop battery cutting out), which would confuse it when next starting up
(trying to attach to a non-existent session). I saw some entries in the
changelog which might have fixed this, but I've had no problems from dtach so
not felt a reason to switch back.

~~~
martanne
As the primary author of these tools, please report core dumps/stack traces of
the crashes (if you get hold of them). At least for my use cases, the current
git versions seem to be stable ...

Having said that, if I ever find the time I would like to overhaul/replace
dvtm's terminal emulation component.

~~~
chriswarbo
First of all, thanks for DVTM, it's really nice.

The crashes I was referring to were seg faults, which happened seemingly at
random, several months apart. If I had more useful/reproducible info I
would've filed a bug report :(

The unclean shutdown issue that I saw in the changelog seems to be
[https://github.com/martanne/abduco/issues/5](https://github.com/martanne/abduco/issues/5)

Before switching to dtach I was working around this by deleting stale sockets
in my .xsession file:

[http://chriswarbo.net/git/warbo-
dotfiles/commits/b182acaa1dc...](http://chriswarbo.net/git/warbo-
dotfiles/commits/b182acaa1dc89a62eac31a1f0acff5278ee45771/diff-
to-619b494b4c2e5f0ca694e863ada16ed57dfa9702.html#xsession)

------
baldfat
Not posting to cause drama BUT:

> I case you don’t know neovim yet, it is an awesome fork of vim with several
> enhancements, such as built-in terminal emulator and asynchronous jobs.

Vim has had asynchronous jobs before the fork. For example:
[https://github.com/tpope/vim-dispatch](https://github.com/tpope/vim-dispatch)

built-in terminal emulator: Why just do this in vim -

noremap <C-d> :sh<cr>

<C-d> goes into and out between vim and your shell. What am I missing?

~~~
zokier
A shell and a terminal are two quite different things. Try running a ncurses
application with :sh

~~~
baldfat
I do ranger.py

------
teddyknox
Turns out you can use the same navigational keybindings to move around nvim
splits and tmux splits, so that moving between the two programs is a sinch.
This is what I use.

[https://robots.thoughtbot.com/seamlessly-navigate-vim-and-
tm...](https://robots.thoughtbot.com/seamlessly-navigate-vim-and-tmux-splits)

------
joaomsa
Does neovim have session persistence for those embedded terminals? Can you
share a session with other people as easily for pair programming/debugging?

I'm not familiar with neovim's terminal emulator. What happens when I press
CtrlX-CtrlE? Is it similar to a normal terminal with readline set to vi
binding?

~~~
saidajigumi
No, if you're after session persistence or sharing ala tmux, that's right in
the sweet spot of what tmux does well and neovim's :term mode isn't designed
form.

It's quite possible that we'll see those features in the future, what with
neovim's separate frontend vs. backend architecture.

~~~
vegabook
_> No, ..._

Immediate deal-killer.

If your workflow involves a) more than one computer and b) usage of the
terminal (surely describing most developers), then tmux attach/detach is
easily one of the most awesome things since vim itself.

~~~
saidajigumi
This depends a lot on your workflow. Sometimes I've lived by screen/tmux
session management, but more recently I almost never need it. Yet tmux+vim is
a vital daily part of my workflow. In its current role, tmux serves primarily
as a window manager.

It's worth noting that I'm using other means to keep my state synced between
my working environments (place) or between working sessions (time). Version
control is part of that (such as private git branches), good environment
automation is part (via Vagrant + provisioning, packagers like npm, etc.), and
automated vim session save/restore is another part of that. For example, if a
vim dies or if I quit, my entire session state is completely restored for that
project when I start vim in that directory again. That all provides quite a
lot of what I'd traditionally depend on tmux for.

------
sunkencity
All that trouble for nothing. I use xterm and control-z, and fg, one terminal
window. If I need to work from more computers than one I use a screen instance
that I can detach/attach from the computer happen to be at.

~~~
a-saleh
Why screen and not tmux? Just curious.

~~~
sunkencity
it's bog-standard and readily available on most platforms. no real need for
split screen, either fullscreen web on one workspace and terminal on other or
side by side if working on computer with big screen.

------
jhallenworld
JOE has pop-up terminal emulators: hit F1 - F4 to bring up one of four
terminals, or flip between them (like Alt-Fn on Linux). It's nice, you don't
have to exit the editor to read a man page. But there is more...

JOE tracks the current directory of each of these emulators, so they are great
for navigation: use cd and grep to find something to edit, then type 'joe
filename' within the terminal emulator to replace the terminal emulator with
the requested file.

Also you can play games with regions and the compiler and grep parsers. This,
from one of the terminal emulators:

    
    
        parse grep -n main *.c
    

will find all of the .c files containing main, mark the grep command's output
as a region, and use the editor's grep parser to load the list of file
locations into the editor. So then you can step forwards or backwards through
the locations with Esc = and Esc - as you would step through compiler error
messages.

(Use 'parserr' instead of 'parse' to parse compiler error messages: type
'parserr make')

You can control the editor by writing programs which send editor macros to
JOE: just echo Esc { macro } to the editor. JOE runs a shell startup file
/etc/joe/shell.sh to provide some aliases. 'joe' and 'parse' are two of the
aliases from shell.sh.

~~~
CaptSpify
link?

~~~
jhallenworld
[https://sourceforge.net/p/joe-
editor/wiki/Home/](https://sourceforge.net/p/joe-editor/wiki/Home/)

This part of the manual talks about the shell windows:

[https://sourceforge.net/p/joe-
editor/mercurial/ci/default/tr...](https://sourceforge.net/p/joe-
editor/mercurial/ci/default/tree/docs/man.md#pop-up-shell-windows)

(BTW, I recently found an issue with installation on OS X: use "LC_ALL=C make
install" to make sed happy.)

------
krinchan
I can't give up tmux because it's what we use to remote pair at work. At the
very least our team worked out some good keyboard shortcuts: C-a leaders with
caps mapped onto Ctrl, VIM/Tmux setups lifted from YADR so when you hit
C-h/j/k/l you can jump through VIM windows and tmux panes seamlessly, etc.
With some work tmux is awesome and we mostly just copy/paste links over
hipchat if we're looking at documentation.

------
kohlerm
I also tried neovims terminal support and I must say I really like it. The
reason is that you have a consistent way to mark and copy text from your
terminal buffer(it basically works like in the editor). I had some other
issues with nvim, which why I'm not yet settled on using it. I also like
abduco for connection management.I'm currently using i3wm and a combination of
some other tools such as parcelite to make sure that the copy and paste
buffers are synchronized. I'm still looking for a simple way to be able to
select something from the terminal buffer and copy it to somewhere else
without the need of some complicated key bindings (e.g. not using screen or
tmux). neovims terminal works well for this use case.

I don't have the need to run a complicated dev enviroment using only terminal
windows on some remote server. I would rather run i3wm and use NX to connect
(its fast enough) if I had that use case.

------
joelbondurant
I fail to see the connection between tmux and vim. Vim is one of a billion
programs i use with tmux inside terminator.

------
zobzu
the amount of levels of stacking for work organization is pretty scary. Its as
if people spend more time trying to organize than actually working.

I use tmux for simple stuff that needs a "detached terminal", not work
organization. multiple terms, the wm and the editor buffers is already more
than i'd ever ask for.

------
trungaczne
I have been using i3, tmux, vim's conque, ... haven't used neovim's conque yet
so I can't comment on it, but here's my experience:

* i3 is fantastic for 90% of your tiling window activities: stacking a LOT of windows on the same screen without any problem, its different modes (stacked, windowed, tabbed) are ingenious, it makes it possible to use minimal number of keystrokes to navigate between any arbitrary windows. The ugly side is that once you've set up your screen with the windows you want, you probably want to keep them like that, while i3 allows you to shift your windows around it gets a bit messy (how do I group these windows together under a different layout?). Also, on Ubuntu, i3 doesn't have the nice "stuff" of other DE, the worst part is that windows don't carry over gnome themes properly and there are bugs with some applications (chrome). Also integrating an "Open another terminal in the current directory" is a headache.

* tmux is great for everything terminal related, it's not as good as i3, but it does its job well (splitting, windowing, saving sessions). It has a few interesting features that makes the move to i3 difficult, such as 1) opening another terminal in the same directory 2) scrollback with vim keys (so that you can run a command, do a reverse search on the output, and copy part of it out) and finally 3) sending the same keystroke to multiple terminals (handy when ssh'ing to multiple hosts for testing). The downsides is that tmux doesn't seem to handle the console all that well (editing in the middle of a bash command kind of breaks on my machine) and it can be annoying to make a script that works with tmux (since it breaks the process parent/child tree, this probably won't affect anyone though)

* I have tried vim's conque plugin, but the terminal freezes from time to time. I'm not sure if neovim's plugin is gonna have the same issue.

Overall I don't think there's a single piece of software that handles
everything completely satisfactory yet. i've been satisfied with tmux for a
long time, now making the move to i3 (it's everything I never knew I wanted),
despite its several issues I think I'm gonna stick with it for a long time.

~~~
fmoralesc
neovim's terminal is not a plugin, is baked in and is a proper terminal
emulator, based on the libvterm library. So, it shouldn't have the same issue,
it makes use of the async features in neovim.

~~~
trungaczne
Thanks for the explanation. I actually just downloaded neovim to try out this
feature, and I must say that with neovim-remote this is incredible. I think i3
and neovim's terminal mode is about as close as I can get to an ideal desktop
setup. Having a terminal that can send arbitrary keystrokes to your editor
open up endless possibilities.

------
bch
I saw a neovim video[0] where the operator opened a terminal and then launched
emacs in it. Can one now (by keyboard only), copy/cut from the emacs terminal
and paste into the neovim screen? That's one of the nice things about tmux,
where I can run a cmd, copy from the backbuffer, and paste into an editor to
(e.g.) mail off the context for a bug report.

[0]
[https://www.youtube.com/watch?v=xZbMVj9XSUo](https://www.youtube.com/watch?v=xZbMVj9XSUo)

~~~
justinmk
Yes, that's always been a feature of :term in Neovim.

------
julienchastang
Here is my set up: I run emacs in server mode doing most of my work w/ an X11
emacs client, and eshell when I need a Unix prompt. As much as I like eshell
there are many scenarios where I prefer zsh so I run zsh in tmux and invoke a
non-X11 emacs (-nw) client within tmux to go back and forth (copy/paste
whatnot) between emacs and zsh. Repetitive strain problems aside, I am
generally pretty happy with this setup.

------
voltagex_
I still have problems with the ssh agent when running tmux. No amount of hacks
or symlinking sockets everywhere seems to give me a reliable (re)connection to
the agent when detaching and reattaching to tmux across machines and ssh
sessions.

------
placeybordeaux
This is very specific to people that already know and use vim, but I agree.
Once I learned about neoterm I have switched over to an instance of neovim
defaulted to term://zsh as my initial shell.

------
kough
Broken on safari on ios9: can see maybe 20px of the article at the bottom of
the screen, while a sticky header with the author's face fills the rest.

~~~
kleptako
Completely broken using noscript this is all i can see, no matter where i
scroll: [https://i.imgur.com/8WAJEmq.png](https://i.imgur.com/8WAJEmq.png)

~~~
vacri
Works fine for me with noscript, with the 'temporarily allow top-level
domains' option set.

------
DominoTree
I've been doing this for a while, and the only real issue is remembering not
to open nested neovim sessions when I want to edit a file :P

------
cm3
while we're talking about tmux, when will it gain screen's flow control (not
tty flow control you can enable/disable), so that something like 'tar xfv
linux-4.5.tar.xz' won't lock up tmux anymore. This works smoothly in screen
but breaks tmux.

~~~
farrelle25
Adding/adjusting these two variables in ~/.tmux.conf should stop TMUX lockups
and control the flow:

    
    
      c0-change-trigger
      c0-change-interval
    

edit: you probably know those 2 already so maybe they don't control large
tar.xz files

------
plugnburn
I don't usually use in-terminal tiling managers, but when I do, I use dvtm.

------
dominotw
i tried this with neovim for a while but went back to tmux due to lag in
neovim's terminal emulation.

------
keda
does this work in remote ssh session?

~~~
saidajigumi
That depends on your goal. If you just want to log in and work remotely in
neovim, sure. But neovim won't provide tmux's feature of being able to
reattach to a session in the face of unreliable connections.

That said, most of the time I use tmux is on localhost as a tiling window
manager for terminal-based work. In those cases, it's very rare that I use
tmux session recovery, so there's merit to simplifying the stack by dropping
tmux.

Even if you did adopt the "nvim multiplexer" approach for local work, you
could still use it remotely inside of one simple tmux pane. (i.e. ignore all
features of tmux _except_ for session management.)

------
TY
TLDR: a neovim user discovers that he can use it as terminal multiplexer
instead of constantly switching between neovim and tmux.

~~~
baldfat
I fail to see what he is saying is more efficient by cutting off tmux? When
switching from tmux to another pane seems to be exactly the same as switching
inside of neovim? I am missing the whole point, and missing something.

PS I don't use neovim (Proudly)

~~~
deanstag
Just to know. why did you mention proudly? I don't use it either, but i
thought it had gotten pretty stable over time and has very few issues. What
problems do you see using neovim?

~~~
baldfat
I just don't like the way this fork happened. I used Vim for 20 years and it
really made me mad how Vim was treated. It reminded me of the FFmpeg vs Libav.

Most of the claims from neovim seem over the top and off from factual i.e. vim
base code is so bad it is unreliable.

> Every other aspect of Vim is irredeemable. The codebase is atrocious. The
> plugin API is cumbersome and restrictive. The dev community is apathetic.
> The benevolent dictator is averse to change. There is no chance of fixing
> these problems. [http://usevim.com/2015/01/16/neovim-
> better/](http://usevim.com/2015/01/16/neovim-better/)

~~~
sipior
_Most of the claims from neovim seem over the top and off from factual i.e.
vim base code is so bad it is unreliable._

To be fair, the one example you give is from a person not directly (to my
knowledge) associated with the neovim fork. There was more than a bit of
discontent, I think, at the slow rate of progress Vim was making compared to
more modern options. I've been using Vim about as long as you have, and I have
to say that I welcome the options neovim brings to my favourite editor.

I suppose it's impossible to have any fork of such a well-worn, fundamental
piece of software without some feeling the need to be partisan. I have to say,
though, that Mr Arruda has regularly conducted himself with a great deal of
courtesy and professionalism, at least in every instance I have seen. I'm
quite happy to be throwing his team a few bucks every month.

~~~
baldfat
Well when they raised money and just went their own way flaming vim and its
maintainer seemed pretty childish.

[https://github.com/neovim/neovim/wiki/Introduction#motivatio...](https://github.com/neovim/neovim/wiki/Introduction#motivation)

Here was Bram Moolenaar (Vim foudner/Maintainer) The guy didn't take money for
the job but asked people to donate money to African Orphans and they do a
fundraiser to cut the man off?

"It's going to be an awful lot of work, with the result that not all systems
will be supported, new bugs introduced and what's the gain for the end user
exactly?

Total refactoring is not a solution. It's much better to improve what we have.
Perhaps with some small refactorings specifically aimed at making Vim work
better for users."
[https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...](https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8)

~~~
sipior
I have to say, the links you post don't really do much to bolster your case.
Was there something particularly damning in the first link that I missed?

I'm also a little unclear on what Ugandan fundraising has to do with this.
Does taking money for Vim development preclude charity? After all, Bram
himself took donations for his work on Vim for some time. From the Vim.org
sponsor page ([http://www.vim.org/sponsor](http://www.vim.org/sponsor)):

 _Fixing bugs and adding new features takes a lot of effort. To show your
appreciation for the work and motivate Bram and others to continue working on
Vim please send a donation.

Since Bram is back to a paid job the money will now (after March 2006) be used
to help children in Uganda. This is the charity recommended by Vim's author.
The money is used for a children centre in the south of Uganda, where AIDS has
caused many victims. But at the same time donations increase Bram's motivation
to keep working on Vim!_

I don't see the problem here.

~~~
baldfat
So saying Vim is bad because it doesn't do what it was intended and take away
potential funding and mindshare with vim to do a "refactoring." They were
saying make Vim good like emacs? Vim vs Emacs will never be settled and this
is such a waste. Vim works and does great things. If you want to do something
else entirely besides keeping vim scripts and the UI call it something else.

