[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feeling lost without tabs

From: Emanuel Berg
Subject: Re: Feeling lost without tabs
Date: Sun, 20 Jul 2014 20:28:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Sampath Weerasinghe <address@hidden> writes:

> I'm slowly migrating from notepad++ to emacs.
> I feel a bit lost because emacs doesn't show tabs.

You are not the first to experience this. A lot of
people got used to tabs from Firefox (or if it was
called Mozilla back then) and then it suddenly was a
common feature everywhere. (It would be interesting who
came up with it first though.)

In the Emacs world, I only have tabs in w3m
(screenshot: [1]), though in function names, commands,
etc. sometimes what I intuitively think of as tabs,
they refer to as buffers...

> I work on multiple projects, I get distracted by
> various things, but when I come back to the seat it
> is the tabs that remind me which project I was last
> working on.

`buffer-menu' would help you with that, as the most
recently used buffers are topmost.

> I know C-x C-b pops it up, but involves multiple keys

You can define your own shortcut. For example, I have
<caps> bring up the `buffer-menu'.

Specifically, I use this defun:

(defun buffer-menu-files-only ()
  (buffer-menu (not Buffer-menu-files-only)) )

It means, if I hit it again while the buffer menu is
shown, I get a new buffer menu, this time not only
showing "file buffers" but also buffers of w3m, Gnus,
and so on.
> and it also takes a a lot of screen real estate.

Yes, for this, `buffer-menu' is even worse than
`list-buffers' (the one you get with `C-x C-b') because
`buffer-menu' uses the whole window. On the other hand,
that makes it impossible to use as a poor-man's
substitute for tabs, so you just go there to switch

If you really like tabs, neither of these methods are
good. You need to find a tab package for Emacs.

The `buffer-menu' solution is good for simple switches,
but for more ambitious projects, and files that occur
regularly, I have a system that is based on keystrokes
and prefixes. `C-j e' is my "Emacs prefix", so `C-j e
e' is ~/.emacs, `C-j e f' is a file where I keep all
everything related to reaching files (f) from Emacs,
`C-j g g' is configurations/extentions for Gnus groups,
`C-j t' is ~/todo.txt, and so on. For a programming
project, I employ the same system, but with different
prefixes and/or keys, of course. Every single file I
setup this way. It is time consuming in the early phase
but then it is so fast it is not a loss of time, on the
contrary. But the main advantage isn't speed, but
workflow. When you have achieved a high degree of focus
then it really sucks to jump back and forth between
files writing long paths or searching for them in
nested files trees. With is system, I'm one keystroke
away from any other file, wherever I am in Emacs. [2]

Earlier, I used registers, like this:

(set-register ?l (cons 'file "/sudo::/etc/rc.local"))

And then I setup a shortcut to `jump-to-register'
(`C-j' actually, short, and doesn't require you to move
you hands from typing positions). That was a good idea
but there aren't enough registers, which is why I
thought of the prefix solution. (The prefix way is also
mnemonic/intuitive as it can be made to mirror the tree
structure of a filesystem, so you get more
familiar/comfortable with that just by jumping between

There are also bookmarks, and many, many other attempts
to solve this file problem, which a very important
problem for programmers and all computer people. We all
think the approach of "small, modular files, use the
filesystem to express purpose and association as well
as to encapsulate" is the best. But do that all day
long, and moving between all those soon-to-be zillion
files is a real pest! So to jump between them in the
close-to-speed-of-thought must be solved somehow,
otherwise all that overhead typing paths and navigating
the filesystem will just make for crappy workflow,
frustration and loss of focus, which is (as said) much
more important than the time loss, which is important
in itself.

So the Emacs "pros" should really put their minds to
this problem even more as it is an annoyance to many
veterans as well as an obstacle to many newcomers.


underground experts united

reply via email to

[Prev in Thread] Current Thread [Next in Thread]