tags/emacszack's home pagehttp://upsilon.cc/~zack/tags/emacs/zack's home pageikiwiki2015-03-09T09:21:47Zinterview for The Setuphttp://upsilon.cc/~zack/blog/posts/2015/03/interview_for_The_Setup/2015-03-09T09:21:47Z2015-03-09T09:21:47Z
<h1>my setup, take #2</h1>
<p>Look Ma, I've been <a href=
"http://stefano.zacchiroli.usesthis.com/">interviewed</a> by
<a href="http://usesthis.com/">The Setup</a>, a popular blog with
<em>"interviews asking people from all walks of life what they use
to get the job done"</em>; so I now sport a fancy <a href=
"http://stefano.zacchiroli.usesthis.com">http://stefano.zacchiroli.usesthis.com</a>
too.</p>
<p>While there is overlap with <a href=
"http://upsilon.cc/~zack/blog/posts/2014/09/interview_for_the_gnu_linux_setup/">my
previous take</a> on my setup, the questions are different so most
of the content is novel. In particular, I quite enjoyed the
question about what would be my "dream setup", and indulged in free
software/hardware desiderata.</p>
<p>Many thanks to Daniel Bogan for running the blog and kudos for
his editing work: while it's just a detail, such an abundance and
quality of link titles is not easy to come by on the Web.</p>
interview for the gnu linux setuphttp://upsilon.cc/~zack/blog/posts/2014/09/interview_for_the_gnu_linux_setup/2014-09-03T14:02:16Z2014-09-03T08:48:14Z
<h1>my setup, take #1</h1>
<p>Among the various things I've catched up with during the summer,
I've finally managed to set aside some time to answer a pending
<a href=
"http://www.mylinuxrig.com/post/96462880004/the-linux-setup-stefano-zacchiroli-former-debian">
interview</a> request for <a href=
"http://www.mylinuxrig.com/setup">The [GNU/]Linux Setup</a>: a blog
run by Steven Ovadia that collects interviews about how people use
GNU/Linux-based desktops.</p>
<p>In the interview I discuss my day to day work-flow, from GNOME
Shell to Mutt, from Emacs to Notmuch, and the various glue code
tools I've written for integrating them.</p>
<p><a href=
"http://www.mylinuxrig.com/post/96462880004/the-linux-setup-stefano-zacchiroli-former-debian">
Enjoy</a>!</p>
<p>Feedback is most welcome.</p>
from Vim to Emacs - part 2http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/2009-11-28T12:00:16Z2008-11-15T12:30:05Z
<h1>One month with Emacs and counting - Part 2</h1>
<div class="notebox">
<p>Other posts in the <em>from Vim to Emacs series</em>:
<span title=
"Why Emacs is now ready to be switching to"><strong><a href=
"http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/">
part 1</a></strong></span></p>
</div>
<p>A while ago I've blogged about <a href=
"http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/">my switch
from Vim to Emacs</a>, promising a blog post <em>series</em>, quite
a mouthful <img src="http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" />
nevertheless, it's time to continue the series. The <a href=
"http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/">first
part</a> was about why I think that nowadays <a href=
"http://www.gnu.org/software/emacs/">Emacs</a> is ready to be
switching to. This second part is about <strong>flawed <a href=
"http://www.vim.org">Vim</a> design choices</strong> which
substantially contributed to my choice.</p>
<p><small>(Of course all this post is under a IMO-/rant-disclaimer,
it can't be otherwise, so take it <em>cum grano
salis</em>)</small></p>
<h2>Flawed Vim design choices</h2>
<p>Vim started as a wonderful editor, following the path of Vi,
which in turn has got right a good deal of design choices. One is
the often debated <strong>modality</strong>. In spite of being a
<acronym title="Human-Computer Interaction">HCI</acronym>
<acronym title="Pain In The Ass">PITA</acronym> in general,
modality is not a problem at all for software you are using every
single day (and the editor is the 2nd program I use the most, with
the terminal being the 1st), because you learn it as <a href=
"http://en.wikipedia.org/wiki/The_Humane_Interface">a habit</a>. In
the case of Vim, modality is good because it let you use powerful
yet simple <strong><a href=
"http://vimdoc.sourceforge.net/htmldoc/usr_04.html#04.1">motions</a></strong>
in command mode, which can be easily combined with <strong><a href=
"http://vimdoc.sourceforge.net/htmldoc/intro.html#Operator-pending">
operator-pending</a></strong> commands.</p>
<p>This can be considered yet another incarnation of the <a href=
"http://en.wikipedia.org/wiki/Unix_philosophy">UNIX philosophy</a>,
casted <em>inside</em> the editor itself. ... which brings us to
the good old joke which describes Emacs as <q><em>a great operating
system, lacking only a decent editor</em></q>. In fact, <strong>Vim
is no longer the nice Unix philosophy player</strong> which it used
to be, and Emacs plays much more nicely with external tools than
Vim.</p>
<p>As arguments, let's consider a few (not so) recent Vim
evolutions:</p>
<ul>
<li>
<p><strong>Spell checking</strong>. Starting with version 7, Vim
has got support for <em>on-the-fly</em> spell-checking of text
buffers. It is a super-nice feature, which I've <a href=
"http://erlug.linux.it/talkdisera/media/vim7.pdf">advertised in the
past</a>, because spell checking is needed in many tasks we daily
do with editors (mail/doc writing, code commenting), and having a
single interface to do it comes handy.</p>
<p>Unfortunately, <em>how</em> that is implemented in Vim is
definitely <em>not</em> along the lines of the UNIX philosophy. We
have countless different FOOspell implementations whereas Vim
implemented yet another one, without relying on any pre-existing
implementation. Even more so, the file format of spell files is
basically ad-hoc, and not sharable with other tools. This is
already a PITA for packaging (let's add to Debian another 20 binary
packages <code>vim-spellfiles-FOO</code>), but is even worst than
that: the spell files must be generated in ad-hoc ways which are
seriously prone to failures (guess why in Debian we don't have yet
the <code>vim-spellfiles-FOO</code> packages which used to exist in
experimental a long time ago?).</p>
<p>What would have been the UNIX-friendly way of achieving the same
result? Well, obviously spawning <code>FOOspell</code> and
<em>interact with its process</em> from the editor. Keep that in
mind.</p>
</li>
<li>
<p><strong>Internal grep</strong>. A feature of Vim I've always
loved is <a href=
"http://vimdoc.sourceforge.net/htmldoc/quickfix.html#:grep">:grep</a>
(yet another instance of <a href=
"http://vimdoc.sourceforge.net/htmldoc/quickfix.html">quick-fixing</a>,
which is also used for jumping to compile-time errors). In its
original incarnation it was as simple as invoking <code>grep</code>
and parse its output. <span title=
"Keep It Simple, Stupid">KISS</span>.</p>
<p>Then, Vim started to have a problem: <code>grep -r</code> can
take ages and in the meantime the editor was stuck. Hence, starting
with Vim 7, <a href=
"http://vimdoc.sourceforge.net/htmldoc/quickfix.html#:vimgrep">vimgrep</a>
has born: an <em>internal re-implementation of grep</em>. OK, it is
more portable (but how many of us do care? on how many system you
use you are missing grep? damn, I used to install it also on
Windoze!), and the editor retain control. Control that is exploited
just to show a nice progress bar of what is being scanned ...,
while the editor is still stuck.</p>
<p>Well, to me it looks like the problem would have been solved
much more nicely by adding the ability to <em>interact with an
external process</em> (deja vu?). That process can then be
<code>grep -r</code>. Full stop.</p>
</li>
<li>
<p><strong>Lack of debugging support</strong> (on purpose). Long
standing missing feature of Vim: you can not "easily" drive a
debugger from Vim, because a firm choice in Vim is to ... (OK, I
confess, I'm starting to beat a dead horse) ... <strong>not have
support for interaction with external processes</strong>.</p>
<p>I found such a choice quite dumb: to me it is evident that it
induces a trade-off between being feature-complete wrt programmer
needs (as available external tools get available to face those
needs) and not "re-implementing the wheel" <em>inside</em> the
editor.</p>
<p>Going back to the lack of debugging support in Vim, that has
spawned projects like <a href=
"http://www.volny.cz/zellerin/gdbvim/">GdbVim</a>, <a href=
"http://clewn.sourceforge.net/">Clewn</a>, Bram's <a href=
"http://www.a-a-p.org/">Agide</a>, and my own tiny teeny
incarnation specific to <a href=
"http://caml.inria.fr/pub/docs/manual-ocaml/manual030.html"><code>ocamldebug</code></a>
called <a href=
"http://upsilon.cc/~zack/hacking/software/wowcamldebug/">WOWcamldebug</a>. Every
single project of that list acts as an intermediary between Vim and
an external process (a debugger of some sort), whereas that could
have been implemented by an editor plugin, provided that the editor
offer, guess what, support for interaction with external
processes.</p>
</li>
<li>
<p><strong>Top-level</strong>. Similar to the debugging support
issue, there is the <em>interpreter</em> issue, namely how to
evaluate "phrases" of your interpreted language of choice directly
from the editor. Nowadays a lot of languages have the so called
top-levels which evaluate language phrases interactively (Python,
Ruby, OCaml, many Lisps, ...) and show evaluation results. That
ability can speed up testing considerably, but can become
cumbersome to use for large code snippets without editor support
(good luck with copy and paste).</p>
<p>Yes, Vim has support for that, but the implementation choice is
close to be ridicolous: only if you have <em>linked</em> Vim
together the interpreted for a given language, then you will be
able to interactive evaluate phrases of that language. What if you
program in Python, Ruby, and Perl? Well, you need to link all of
them. What if you also program in OCaml? Then you're screwed,
because Vim currently does not support linking with it.
<small>(Yes, I know that there are other reasons for doing that
linking, they are discussed below.)</small></p>
<p>Do I need to tell you which feature will be enough to address
top-level support? <strike>interaction with extern..</strike> OK,
I'll drop it, you know that already.</p>
</li>
</ul>
<p>Well, I acknowledge that Emacs got this choice right, and that
it's <em>an important one</em>: Emacs supports interaction with
external processes, and plugin authors have been happy to exploit
it to create really cool stuff (sticking to the UNIX philosophy).
Please welcome: <a href=
"http://www.gnu.org/software/emacs/manual/html_node/emacs/Spelling.html">
Flyspell</a>, <a href=
"http://www.emacswiki.org/emacs/GrepMode#toc2"><code>M-x
grep</code></a> (shameless smartass plug: same number of keystroke
of <code>:grep</code>), <a href=
"http://www.gnu.org/software/emacs/manual/html_node/emacs/Debuggers.html#Debuggers">
Grand Unified Debugger</a>, <a href=
"http://www.emacswiki.org/cgi-bin/wiki/PythonMode">a</a> <a href=
"http://www.emacswiki.org/cgi-bin/wiki/TuaregMode">sampling</a> of
language-specific major modes with top-level support. (But I
recommend having a look at least once at the coolness of other
stuff built-on top of external process support, like <a href=
"http://flymake.sourceforge.net/">Flymake</a>, <a href=
"http://www.netfort.gr.jp/~dancer/diary/200810.html.en">mentioned
by dancer</a> not a long ago.)</p>
<ul>
<li>
<p><strong>Its own scripting language</strong>. I've bored you
enough with the external process topic, hence here is the second
one: the saga of Vim and its scripting language, i.e., the
programming language using which you can customize the editor.</p>
<p>Note that the choice of scripting language impacts on 2
different targets: final users in need of fire and forget
automations (when they start to get to complex to be implemented on
top of, say, <a href=
"http://vimdoc.sourceforge.net/htmldoc/repeat.html#recording">macros</a>),
and developer of editor extensions such as <a href=
"http://www.vim.org/scripts/index.php">addons</a>.</p>
<p>The impact of scripting language on extension developer is
crucial for the evolution of an editor aiming at being powerful. If
the scripting language and the API towards the editor is flexible
enough, then a lot of cool extensions and features will be
developed by third party authors, otherwise the burden stays on
editor upstream author.</p>
<ol>
<li>
<p>In its <em>phase 1</em> (my term, Vim < 7.0) Vim pretended
that it needed only a <em>minimal</em> scripting language (<a href=
"http://vimdoc.sourceforge.net/htmldoc/usr_41.html">Vim script</a>)
and that everything else can be developed using external
programming languages, linked in the editor. As a consequence Vim
script was just a tiny teeny procedural language with editor
interfacing capabilities, most notably lacking any "decent" data
structures (no lists, no dictionaries, ...).</p>
<p>In that phase, if you were a user it was fair enough. You just
had to chose your external programming language (at compile time
...), and you were able to write your quick hacks with it. But if
you were willing to develop an extension you were screwed, because
you had either to impose your external programming language to the
final user (that is what gave born to absurdities like <a href=
"http://packages.debian.org/etch/vim-full"><code>vim-full</code></a>,
look at the deps!) or to enjoy a good deal of masochism to explode
your 30 lines of Python extension into 200 lines of Vim script to
make your Vim extension more "portable".</p>
</li>
<li>
<p>In its <em>phase 2</em> (Vim >= 7.0) it has been realized
that something were wrong in the initial choices about Vim script,
and data structures (lists, dictionaries, function references!)
have been added to it, relieving a bit the pain of programming
portable extensions.</p>
<p>Nevertheless, and probably due to how it started, Vim script is
far from being a programming language one can enjoy programming in.
Consider for example the <a href=
"http://vimdoc.sourceforge.net/htmldoc/eval.html#functions"><em>standard
library</em></a> of the language. It started as a random collection
of unrelated functions being added on a "as-needed" basis, ... and
continued along that path! Now the API reference lists together
totally unrelated functions, organized inconsistently, and making
really painful finding what you need (assuming it exists).</p>
</li>
</ol>
</li>
</ul>
<p>Even in this respect, I acknowledge that Emacs got this right.
It has chosen a single, now full-fledged, programming language
(<a href="http://en.wikipedia.org/wiki/Emacs_Lisp">Elisp</a>),
which is offered both to the final user (<em>fact</em>: the average
Emacs user knows much better how to program her own editor than the
average Vim user) and to extensions developer. The standard library
of the language is organized with a consistent naming (even though
not always intuitive) and <a href=
"http://www.gnu.org/software/emacs/manual/html_mono/elisp.html">documented
in an organized manner</a>.</p>
<p>You might not like the language, but at least is has been taken
seriously and managed as such. Finally, being a Lisp dialect, you
might need what you learn with Elisp elsewhere. Vim script is too
committing: it is useful only inside Vim. I believe that
contributed significantly in its scarce diffusion among Vim
users.</p>
<p>The fact that Elisp was born together with Emacs and that it is
also used internally for the editor implementation is not relevant
here: I do care about what is offered to me as an user and as an
extension developer. What I see on the Emacs side in this respect
is much better that what I see on the Vim side. Moreover, from the
point of view of the users, is the difference between what is
<em>inside</em> the editor and what is <em>outside</em> (i.e., the
extensions) that relevant? I think it is not, and that brings me to
the final Vim choice which I consider flawed and which has the
potential of seriously limit its future evolutions:</p>
<ul>
<li>
<p><strong>Editor as a distribution</strong>. Emacs is managed as a
intermediate software distribution layer, similarly to what happens
in other softwares where many third party authors cooperates (e.g.,
<a href="http://www.tug.org/texlive/">TeXLive</a>). The
distribution architecture has advantages and contributes to the
longevity and potentialities of a software project.</p>
<p>What does this mean concretely in the Vim vs Emacs dispute? For
example it means that Emacs get more feature-complete each passing
release, still preserving uniformity in documentation and
keybindings. On the contrary Vim sports many addons, which are very
likely to step on each other feet when enabled simultaneously.
Actually, that is one of the reason which brought me to the
creation of <a href=
"http://packages.debian.org/lenny/vim-addon-manager">vim-addons</a>:
you cannot enable all the content of <a href=
"http://packages.debian.org/lenny/vim-scripts">vim-scripts</a>
together due to various kind of conflicts. As we know well in
Debian, distributions have a fundamental role in blending together
lightly-coupled software components, that's role is missing in Vim
evolutionary path and I find that worrisome.</p>
</li>
</ul>
<p>Where to from here in this blog post series? For sure some tips
on how to migrate for hard-core Vim users, then we'll see ...</p>
<p>If you did enjoy the read please let me know commenting in the
discussion page (as you did in the last post, thanks!).</p>
from Vim to Emacs - part 1http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/2009-11-28T12:00:16Z2008-10-23T07:24:26Z
<h1>One month with Emacs and counting - Part 1</h1>
<div class="notebox">
<p>other posts in the <em>from Vim to Emacs series</em>:
<span title="Flawed Vim design decisions"><strong><a href=
"http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/">
part 2</a></strong></span></p>
</div>
<p>Straight to the point: <strong>since mid September I've been
using <a href=
"http://www.gnu.org/software/emacs/">Emacs</a></strong>, trying to
evaluate whether I was willing to switch from <a href=
"http://www.vim.org">Vim</a> to it.</p>
<p>Yup, that's true, me (user of Vim since the day I've started
using GNU/Linux 10 years ago, (not so) active <a href=
"http://alioth.debian.org/projects/pkg-vim/">maintainer in Debian
of <code>vim</code> and related packages</a>, author of some
popular Vim extensions and of <a href=
"http://packages.debian.org/sid/vim-addon-manager"><code>vim-addon-manager</code></a>)
it's considering switching to Emacs. What is worse is that
<strong>I've de facto already switched</strong>. May <a href=
"http://alioth.debian.org/users/jamessan/">jamessan</a> forgive
me.</p>
<p>OK, that was the hardest part to write, now ...</p>
<p>This choice will have an impact on me: partly because I'm quite
sure several fellow DDs will start making fun of this story
<img src="http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> , and partly
because as many geeks I've always had strong opinions on <a href=
"http://en.wikipedia.org/wiki/Editor_war">the editor war</a>.
Switching side ain't easy.</p>
<p>Hence, I've decided to write a small (2-3) series of blog posts
on the issue, to future memory. The post you are reading is about
<em>why, since a few months ago, I wasn't willing to give Emacs a
try, and how I've changed my mind</em>.</p>
<h2>Why I wasn't willing to give Emacs a try, but then changed my
mind</h2>
<p>I love knowing tools which can improve my workflow, no matter
the task. Editors happen to be at the intersection of many tasks,
hence <em>knowing well</em> his own editor and <em>feeling
satisfied about it</em> is quite important. This is even more so
for free software hackers which, for a reason or another, happen to
use the very same editor for a lot of different tasks; in my case:
programming, conf file hacking (i.e., playing the sysadm role),
mail writing, and everything in between.</p>
<p>I've started using <code>vi</code> on Solaris around 1998, then
switched to Vim starting from version 4.0, and then followed all
its releases up to 7.0. I consider my "Vim karma" to be quite hight
and I've delivered several talks about using Vim for LUGs and other
free software-related events. Still, I've always been hit bit
several minor nuisances and glitches of Vim which couldn't be fixed
by simple configuration tuning or add-on implementations (more on
this in a future post).</p>
<p>In the quest for the perfect workflow, those glitches have made
me try several times other editors hoping for more satisfying work
environments. Of course Emacs was one of them, which I've tried
repeatedly during the years; the last time was circa 2006.</p>
<p>For one reason or another, after a few days of experiments, I've
always decided to give up with it. Why? Various reasons, listed
below, together with an explanation of what (I think) has changed
since then.</p>
<ol>
<li>
<p><strong>Poor Unicode/multibyte support.</strong> Support for
whatever Unicode encoding was close to null. It was not available
in the legacy editor, and you had to use something called MULE, to
be specifically enabled. That was so 60's, and rather hard to
use.</p>
<p>Now (<a href=
"http://en.wikipedia.org/wiki/Emacs#Release_history">apparently
starting from Emacs 22.1</a>, June 2007) finally you have built-in
Unicode support and the needed two variables for setting the input
encoding and the file encoding, which is basically all you need.
Looks easy once you have it ...</p>
</li>
<li>
<p><strong>Lack of "modern" UI toolkit support.</strong> Yes, I do
live in a console and invoke my editor from it, but nevertheless
for long coding sessions I do also love having a nice GTK+ window
containing my editor using settings which smoothly integrated with
the graphical settings of my desktop environment. Maybe I'm getting
old, maybe GNOME has changed my perceptions, but why the heck I had
to tolerate different monospace fonts in my
<code>gnome-terminal</code> wrt my GUI editor I never understood.
Firing up Emacs was like getting back in time of 15 years, and if a
geek having a maximized terminal on most of its workspaces had this
feeling, then something was really wrong.</p>
<p>This has changed: starting again from Emacs 22.1, the editor has
frown support for that "bleeding edge" technology called GTK+.
Finally you can use Pango font faces and avoid the time travel
feeling when switching from a terminal to your GUI.</p>
</li>
<li>
<p><strong>"Dead upstream" syndrome.</strong> As we all know by
experience, choosing a free software product is not only a matter
of evaluating bugs and features, there are other environmental
factors. A notable example is how active upstream is. A few of us
will use a product affected by the "dead upstream" syndrome. That's
exactly what I was feeling about Emacs. The first argument I can
offer to back that feeling is again the <a href=
"http://en.wikipedia.org/wiki/GNU_Emacs#Release_history">Emacs
release history</a> (noted that "small" hole between 2001 and 2007?
Rest In Peace <q>release early, release often</q> ...).</p>
<p>The second argument is the bug tracking system: there was none,
bug discussions happened only on the development mailing list and
the bug tracker was a text file on CVS! (Yes, Vim doesn't have a
proper BTS either, but I was looking for reasons to switch from it
and hence looking for something better in several respects.)</p>
<p>That has changed completely, as I discovered only at <a href=
"http://debconf8.debconf.org">this year DebConf</a> thanks to
<a href="http://luca.pca.it/">gismo</a>. 2007 has enjoyed 1 Emacs
release and 2008 already two. They do have <a href=
"http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacs">
a BTS now</a> and guess what? is dear old <a href=
"http://bugs.debian.org">debbugs</a>. According to my first
experiences as Emacs bug reported the maintainers are very reactive
and also friendly in dealing with bug reporters. Finally, also
keeping up with snapshot releases in Debian is entirely trivial,
thanks to <a href="http://emacs.orebokech.com/">Romain's
repository</a>.</p>
</li>
<li>
<p><strong>Poor performances & memory consumption.</strong>
This goes in the direction of probably the most popular joke used
by Vim zealots in the editor war: <q>Emacs is a nice operating
system, but lacks a good editor</q>, or something such.</p>
<p>In the past I had the impression that starting Emacs was really
slow and that generally the memory footprint was too high to be
acceptable. You know what: starting a <a href=
"http://packages.debian.org/sid/vim-full">full-blown</a>
<code>gvim</code> with a good deals of add-ons (and I used quite a
lot of them, that's why <a href=
"http://packages.debian.org/sid/vim-addon-manager"><code>vim-addon-manager</code></a>
was born) is not that faster. And on the contrary, firing up an
<a href=
"http://www.emacswiki.org/emacs/EmacsClient"><code>emacsclient</code></a>
is way <em>faster</em> than starting up a new <code>gvim</code>
instance.</p>
<p>Regarding memory consumption Emacs is still "gaining" the
battle. Still, one has to keep in mind the different workflow: with
Vim you are encouraged to enter and exit the editor (not without
drawbacks, as I'll discuss in a future post), while with Emacs you
always use the same one. It turns out that via
<code>emacsclient</code> the resulting feeling is the same as
having multiple editors (as you can fire them up as separate
windows or in separate consoles), still sharing all user
memory.</p>
<p>A final comment on memory consumption while looking at my
<code>top</code> sorted by decreasing RSS memory: the top process
is xulrunner (from the browser) with 356Mb, then Xorg (159M),
pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ...,
Emacs shows up with 51 Mb at the 7th position. Yes, it is not the
thinnest editor in the world, but on average machine it doesn't
really matter <em>at all</em>.</p>
</li>
</ol>