setting the frame title

The 'frame title' (window title) that emacs uses in graphical environments defaults to something like emacs@hostname.

Of course emacs lets us customize this, by changing the value of frame-title-format. Emacs accepts many different things there, (see the documentation for frame-title-format and mode-line-format for that), but let's look at an example.

Instead of the default emacs@hostname, I find it more useful to include the name of the file I'm working on instead, or, in case of non-file buffers, the buffer name. To do this, I have something like the following in my .emacs:

(setq frame-title-format
  '("" invocation-name ": "(:eval (if (buffer-file-name)
                (abbreviate-file-name (buffer-file-name))
                  "%b"))))

As you see, frame-title-format is a template for the items that are present in the title bar; i.e.. emacs concatenates the items in the list, and it supports various %-constructs, which are replaced with actual values; see below.

In addition to the %-constructs, you can use :eval to make emacs evaluate the expression whenever it wants to update the title bar.

invocation-name is the name of the emacs binary.

abbreviate-file-name replaces the home directory part in file names with ~; for very deep paths it might be nice to do some abbreviation as well as some shells do; this is left as an exercise to the reader :)

You can experiment with some other things to put in frame-title-format; use the :eval construct as above to use emacs-lisp functions, and the various %-specifiers which are replaced by certain values; the emacs documentation lists the following:

%b -- print buffer name.      %f -- print visited file name.
%F -- print frame name.
%* -- print %, * or hyphen.   %+ -- print *, % or hyphen.
      %& is like %*, but ignore read-only-ness.
      % means buffer is read-only and * means it is modified.
      For a modified read-only buffer, %* gives % and %+ gives *.
%s -- print process status.
%i -- print the size of the buffer.
%I -- like %i, but use k, M, G, etc., to abbreviate.
%p -- print percent of buffer above top of window, or Top, Bot or All.
%P -- print percent of buffer above bottom of window, perhaps plus Top,
      or print Bottom or All.
%n -- print Narrow if appropriate.
%t -- visited file is text or binary (if OS supports this distinction).
%z -- print mnemonics of keyboard, terminal, and buffer coding systems.
%Z -- like %z, but including the end-of-line format.
%e -- print error message about full memory.
%@ -- print @ or hyphen.  @ means that default-directory is on a
      remote machine.
%[ -- print one [ for each recursive editing level.  %] similar.
%% -- print %.   %- -- print infinitely many dashes.
Decimal digits after the % specify field width to which to pad.

So, if we'd like to include the host (system) name and some indication of the status of this buffer, we could do something like:

(setq frame-title-format
  '("emacs%@" (:eval (system-name)) ": " (:eval (if (buffer-file-name)
                (abbreviate-file-name (buffer-file-name))
                  "%b")) " [%*]"))

Of course, some of the information is available elsewhere already, but it might be clearer in the frame-title. Or not – there's a lot of room for tweaking and experimentation here.

color theming with emacs 24

The emacs development team is hard at work on emacs 24. As far as I know, there is no planned date for it yet. I'll write more about all the new cool things when we're a bit closer to the release date, but I'd like to highlight emacs 24 color-theming already, as it's an area people outside the core development theme should be able to contribute to as well.

Here at Emacs-fu, we already discussed color-theming and in particular the zenburn color theme; this was all based on the color-theme-package. While being popular, there were a few problems with that package, which is why emacs-24 comes with a new scheme for doing this.

The current development versions of emacs ship with a few themes (tango, tango-dark and wheatgrass), which you can activate with M-x load-theme. It would be great to include some more color themes, and to encourage this, emacs maintainer Chong Yidong has written the GNU Emacs Theme Generator (currently in bèta), which helps you in the process of making a simple theme. This tool currently only support changing colors, and not e.g. the boldness or slant, but it's a nice way to get started, and to immediately see the results.

For more complex theming, there is M-x customize-create-theme; however, that is built on the (in my opinion) cumbersome customize-interface, so I'll probably start by creating a basic theme with the web tool, and then edit it by hand. If you design some attractive color theme and would like to propose it for inclusion in emacs 24, you can send it to emacs-devel.

conkeror: web browsing the emacs way

Web browsing is one of the few computer-based activities for which I usually do not use emacs. Of course, there are of emacs-based browsers like w3m, which is pretty good. But for the 21st-century web, a text-mode browser is a bit limited. There are some efforts underway to integrate a graphical web browser experience in emacs (e.g., using Xembed), but it will take a while before that is ready.
The next best thing to web browsing with emacs, is a browser that is inspired by emacs. Such a browser exists: it's called conkeror (not to be confused with KDE's Konqueror). conkeror is a Mozilla-based browser that brings an emacs-like experience to web browsing. I've been using it for more than a year now as my primary browser, and I am quite happy with it.
Conkeror is a user-interface for the normal Mozilla/Firefox engine (xulrunner); this means that all those websites that work with Firefox, work just as well in conkeror, including things like ad-blockers, Java, Flash etc. and many plug-ins. This is a very important point for me.
If you like emacs, you'll probably also like conkeror. For starters, it uses many of the same key bindings – C-x C-f will open a url in a new buffer (tab), C-x 5 2 will open a new window (frame), I can inspect a key-binding with C-h k… and so on. Some of the single-key shortcuts are the same as those in w3m, like g to go to a webpage, or B to go back. Conkeror is fully keyboard-driven; it allows you do almost anything on the web without using the mouse – it can overlay numbers on items in a webpage so you can interact with them by their number. Of course, you can still use a mouse if you want, too.
The conkeror wiki gives many more examples. It also discusses installation in quite some detail, which makes life a bit easier for me :) Instead, I will just list a couple of the customizations I have made and encourage you to try for yourself.

configuration

Like emacs, conkeror is very configurable. The big difference is that conkeror uses Javascript instead of Elisp for the configuration; however, the concepts and naming should be familiar for emacs-users. Conkeror's equivalent of ~/.emacs is ~/.conkerorrc. Below are some snippets from my setup, that can hopefully help you to create your Perfect Browser ™; all examples below are based on the latest development version of Conkeror, as per end of November 2010.
First, some basics:

//allow for 'contrib' stuff
load_paths.unshift("chrome://conkeror-contrib/content/");

// teach me something whenever I start my browser
homepage = "http://en.wikipedia.org/wiki/Special:Random";

// give me new tabs; open buffers (tabs) in the background
require("new-tabs.js");
require("clicks-in-new-buffer.js");
clicks_in_new_buffer_target = OPEN_NEW_BUFFER_BACKGROUND; 
clicks_in_new_buffer_button = 1; //  midclick links in new buffers with

// auto completion in the minibuffer
minibuffer_auto_complete_default = true;
url_completion_use_history = true; // should work since bf05c87405
url_completion_use_bookmarks = true;

modeline customization

As in emacs, you can customize the modeline. Also in good emacs tradition, this is far from intuitive…

require("mode-line.js");
// funky icons in the modeline
require("mode-line-buttons.js");
mode_line_add_buttons(standard_mode_line_buttons, true);

// we'd like to see the # of buffers being loaded 
add_hook("mode_line_hook", mode_line_adder(loading_count_widget), true);
// we don't need a clock
remove_hook("mode_line_hook", mode_line_adder(clock_widget));

bookmarks

Plain-old bookmarks are easy to add with define_webjump – and you can just bind them to a short string. You can then 'jump' to the corresponding website by pressing g and then this short string. For example, to go to Emacs-Fu, you could type g efu RET. No mousing around needed.

// some bookmarks
define_webjump("conk",  "http://conkeror.org");
define_webjump("efu",   "http://emacs-fu.blogspot.com");
define_webjump("lkml",  "http://lkml.org");
define_webjump("ew",    "http://emacswiki.org");
// ...

smart links

Smartlinks are just like normal bookmarks, which the one difference that they contain an %s-parameter which will be replaced by whatever you type after the name of the bookmark. Thus, g imdb grande bouffe RET would take you to the IMDB-page about the movie La Grande Bouffe.
Some examples:

define_webjump("so",    "http://stackoverflow.com/search?q=%s");
define_webjump("yts",   "http://www.youtube.com/results?search_query=%s&aq=f");
define_webjump("imbd",  "http://www.imdb.com/find?s=all&q=%s");
// ...

integration with emacs

Another useful feature in conkeror is the ability to interact with Emacs (or any other text editor), so you can use emacs for writing text in web pages; for example, when you're using emacs-daemon (you should), you could can add the below, and C-i will then take you to emacs whenever you are in a text field in a web page.

editor_shell_command = "emacsclient -c";

adding your own functions

It's fairly easy to add your own functions; admittedly, I'm still at the beginning stages with that, but it's not too hard to combine the internal function, and assign them to key bindings. Some examples:

// copy url with C-c u
interactive("copy-url",
        "Copy the current buffer's URL to the clipboard",
        function(I) {
            var text = I.window.buffers.current.document.location.href;
            writeToClipboard(text);
            I.window.minibuffer.message("copied: " + text);
        }
);
define_key(default_global_keymap, "C-c u", "copy-url");


// reload conkerorrc with C-c r
interactive("reload-config", "reload conkerorrc",
       function(I) {
          load_rc();
          I.window.minibuffer.message("config reloaded");
       }
);
define_key(default_global_keymap, "C-c r", "reload-config");

It's not necessarily so easy to find the exact functions / objects you need to accomplish what you want. There's a certain learning curve – just like when using emacs.

integration with org-mode

The integration with emacs can go further than merely editing text fields though; it's possible to integrate conkeror with org-mode in emacs; I have the following in my .conkerorrc (this requires emacs-daemon), based on the code in WOrg:

// org-protocol stuff
function org_capture (url, title, selection, window) {
    var cmd_str =
        'emacsclient \"org-protocol:/capture:/w/'+url+'/'+title+'/'+selection+'\"';
    if (window != null) {
      window.minibuffer.message('Issuing ' + cmd_str);
    }
    shell_command_blind(cmd_str);
}

interactive("org-capture", "Clip url, title, and selection to capture via org-protocol",
          function (I) {
              org_capture(encodeURIComponent(I.buffer.display_uri_string),
                        encodeURIComponent(I.buffer.document.title),
                                encodeURIComponent(I.buffer.top_frame.getSelection()),
                        I.window);
          });
// capture with C-c c
define_key(content_buffer_normal_keymap, "C-c c", "org-capture");

Then, on the emacs-side (in your .emacs), you should have a capture template for this; for example:

;; ;; the 'w' corresponds with the 'w' used before as in:
;;   emacsclient \"org-protocol:/capture:/w/  [...]
(setq org-capture-templates
  '(
     ("w" "" entry ;; 'w' for 'org-protocol'
       (file+headline "www.org" "Notes")
       "* %^{Title}\n\n  Source: %u, %c\n\n  %i")
     ;; other templates
))

Now, when in conkeror, you can select some text, push C-c c ('capture'); emacs will offer you to save this text, including a link to the source, the date and so on, and saves it for later retrieval. I really love this feature!

so…

These were just a couple of the many things you can do with conkeror; there's so much potential here. I haven't discussed many of the other powerful features, such as the page-specific modes, that give special features to specific websites, be it GMail or Wikipedia.
I've been using this fine browser for a year or so now, and I really like it. There are a few rough edges here and there, but it's quite amazing what the small development team has accomplished. I heartily recommend it – for web-browsing the emacs-way, there's simple no better alternative.
Finally, if you're using conkeror already, and have some clever tricks you'd like to share, feel free to do so in the comments.

undo

One of the advantages that text-editors have over daily life is the ease of undoing things. Emacs in particular has a powerful undo-system to return to the previous state of things.

Undo can be activated by pressing C-x u or C-_; if you are more comfortable with using C-z for undo (as is the standard in many non-Emacs environments), you can of course add that key binding as well, by putting in your .emacs:

(global-set-key (kbd "C-z") 'undo)

This overrides the default of C-z triggering suspend-frame, which is not a great loss for most people.

Emacs-undo has some nice features - for example, if you have selected some text ('marked a region'), the undo operation only applies to that area. At the same time, however, the undo-model can be confusing: in emacs, undo is treated like any other command, which means that undo can be applied even to… undo, which is different from what most other editors do. Let me give an example – if it's confusing or tedious then, well, that's what it is…

Suppose I type

hello
world

now I press C-_, and I get

hello

Now I type foo

hello
foo

And press C-_ C-_; and I get back:

hello
world

This is because we're 'undoing the undo' of adding the word 'world', and thus, it reappears! When you try this in most other editors, it would result in

hello

because those editors completely forget about 'world' after it is undone.

So, emacs' model is strictly more powerful - but some (many? )people find it a bit confusing, esp. when a series of 'undos' is interrupted by a 'do'.

If you prefer the model that many other editors use, you might be interested in redo-mode, in particular in RedoPlus. Using that package, undo (or rather, redo) follows a different model. In that model, redo is 'special': it's not registered as a buffer change, and as such it's conceptually different from the redo=undo-undo model that emacs uses by default. As seen above, you actually lose some information in the process.

Yet another way to tackle the undo-problem is implemented by UndoTree: the states of your buffer are seen as nodes in a tree, and you can freely move to specific nodes. UndoTree is as powerful as the emacs system, yet easier to understand. It can even visualize the tree of changes - and you can then by clicking on a node go back to the corresponding buffer state.

Now, when using UndoTree, let's look at our example again:

We started with:

hello
world

then did C-_ (which removed 'world') and typed 'foo' to get:

hello
foo

Now press C-u again, and 'foo' disappear. Now we press C-x u (undo-tree-visualize) and we get a buffer with:

  |
  o
  |
  |
  x
  | 
 / \
o   o

and we can now visually move to any of the nodes, and our buffer is instantly brought back. Cool! The two branches correspond to the states 'world' and 'foo'. I have been undo-tree-mode for the last few weeks, and it works very well: usually I don't even notice it, but when I need the extra power, it's there.

I am told that UndoTree is inspired by the way the vim-text editor does this. Anyway, there is another very powerful feature in the vim undo-system that would be nice to have in emacs to: time-based undo. In vim you can e.g. say something like:

:earlier 5m

to go to the state of your buffer 5 minutes ago. That would be a nice addition for undo-tree-mode!

Update Tavis Rudd notes that pressing t in undo-tree-visualizer-mode (i.e.. what you see when your press C-x u) will give you timestamps instead of o and x:

                  |
                  | 
             18:54:20
                  |
                  |
             18:54:20
          ________|___ 
         /            \
     18:54:15       18:53:37
        |              |
        |              |
     18:54:15       18:53:37
     ___|___           |
    /       \          |
18:54:10  18:53:43  18:53:36

auto-complete-mode

Recently, we discussed CEDET in the interview with Eric Ludlam. CEDET has a deep understanding of the source code, and assists the development process by exploiting that knowledge. For example by drawing class diagrams (COGRE) or providing auto-completion for function names and parameters.

Currently, however, CEDET is also be a bit hard to set up effectively, and may also not support your programming language yet. Therefore, it's still useful to look at some other packages that can substitute (part of) the functionality.

For me, auto-complete-mode has been very useful for that. It's not as fancy as CEDET in the sense that it does not really understand the code – but in practice I found it to work quite well for both C/C++, Elisp and shell scripts. It can even display the docstrings of functions. And when editing shell-scripts, it can complete path names as you are editing the scripts; very nice.

To install, follow the instructions. Then, in your .emacs, have something like:

(when (require 'auto-complete-config nil 'noerror) ;; don't break if not installed 
(add-to-list 'ac-dictionary-directories "~/.emacs.d/ac-dict")
  (setq ac-comphist-file  "~/.emacs.d/ac-comphist.dat")
  (ac-config-default))

After that, M-x auto-complete-mode to start using it. Alternatively, there's a YouTube-video explaining how to install and use auto-complete-mode; recommended. In any case, it is fully documented.

auto-complete-mode uses a configurable set of sources from which it takes it knowledge about what can be completed. For example, when writing in org-mode, it takes its input from

(ac-source-filename ac-source-abbrev ac-source-dictionary
 ac-source-words-in-same-mode-buffers)

while in a c-mode buffer it is (in my case):

(ac-source-filename ac-source-yasnippet ac-source-gtags ac-source-abbrev
ac-source-dictionary ac-source-words-in-same-mode-buffers)

You can customize this, and (for the more ambitious), it's possible to add your own sources as well.

interview with Eric Ludlam (CEDET)

One of the notable new features of emacs 23.2 was the inclusion of CEDET. CEDET adds IDE-type functionality to emacs, and one only needs to read the responses to the 100th post to see the great interest in that.

The man behind CEDET is Eric Ludlam (EML), a long-time Emacs user and developer. He kindly answered the many questions we had for him. Thanks, Eric!

djcb: Eric, could you tell us a little bit about yourself? And about that fantastic hobby of yours, building siege engines?

EML: I manage a software engineering team at the MathWorks. The MathWorks are the creators of Matlab. In my spare time I maintain CEDET, the Matlab support for Emacs, and build replicas of ancient siege engines.

I've been building catapults of various types for use at the World Championship Punkin' Chunk since 1998. My team started with a traction trebuchet, then a HCW Trebuchet, then moved to Human Powered Centripetal, and finally to the torsion division with MistaBallista. As far as I know, Mista Ballista is the worlds largest farthest throwing currently functional ballista.

Most recently, I got to help demolish a building where I work by shooting stuff at it, which was a lot of fun.

djcb: How did you get involved with Emacs? Do you spend a lot of time with it?

EML: I've been hacking Emacs since version 18.54 on Ultrix because the alternative was vi. My first post (and thus contribution to Emacs) was to gnu.emacs.sources on June 6, 1992. I've used Emacs to work on C/C++ code for many years which inspired all the various parts of CEDET, but these days I don't get much coding time.

My work with Emacs and CEDET is seasonal currently. The summers are usually busy with family activities, and my falls are busy getting the catapult ready, so CEDET work usually happens in the winter.

djcb: Can you tell us a bit about the background of CEDET?

EML: I started with some really basic editors and eventually with LSE (Language Sensitive Editor) on VMS. LSE was pretty cool. When I switched OSes to Ultrix and was forced to use Emacs, and discovered you could script it, I was hooked. My first big Emacs hack was etalk, an implementation of Unix talk in Emacs.

In one of the Emacs related newsgroups, a spoof story floated around about how Emacs became sentient, and started writing code for Richard [Stallman] instead of the other way around. Since then I've always wanted to get Emacs to start writing my code for me. I wrote cparse.el, a regexp nightmare that could parse almost any C file into a sequence of highly detailed tags. The tags could be used to then generate code, and I had a cool comment writing utility, automatic prototype generation, and some navigation features. On the whole it failed for many reasons.

The concept, however, continued. CParse became the basic idea behind what is now the Semantic package in CEDET, though none of the old stuff remains beyond some echos in some SRecode utilities.

My end goal is to provide round-trip code management in Emacs. Emacs needs to be able to read your code, allow you to perform transformations in the code in an abstract way, and then write new code for you. Everything in CEDET is building toward that goal. It is taking a long time, and you can see it starting to take shape. Semantic can parse the code, COGRE can manipulate UML diagrams representing your code, and you can export diagrams into code through SRecode. Unfortunately this isn't a round-trip solution as the generated code currently should not replace existing hand-written code.

Can you tell us a bit about the CEDET-project?

EML: I maintain CEDET and field questions on the mailing list. There are several contributors who either own some tool in the "contrib" area, fix bugs, answer questions or apply patches for new features. There has always been someone to pick up the slack when I'm busy elsewhere, and I've greatly appreciated that.

The easiest (and most common) way to contribute code to CEDET is to provide support for some new language, or to create a language agnostic tool using the CEDET APIs. As with Emacs, you need to be able to assign copyright to the FSF to contribute to CEDET's core, but new language support or utilities can have a home in the contrib area as well.

djcb: CEDET is part of Emacs since 23.2. Can you tell us a bit about how that happened?

EML: I've been providing assignments for the parts of CEDET since 1996 or so. For Emacs 23.1, CEDET was at a stable and useful enough state that Chong Yidong was willing to do the work to integrate it into Emacs. My ability to get a legal release for CEDET in time for Emacs 23.1 failed, so it went into 23.2 instead. It is my understanding that CEDET's smart completion engine reached a performance and reliability point that made it desirable to have in Emacs.

Emacs currently includes the parts of CEDET needed to make EDE, the project management system, Semantic and it's user tools, and SRecode all work from a user perspective. Emacs lacks the Semantic development environment, needed for writing new language support, and COGRE, the UML diagram editing tool.

djcb: Are there plans to include those parts as well?

Yes. It is important for users with a stock Emacs to develop new languages using the missing Semantic development tools. I don't know if COGRE will ever go in, though I expect that this will be done via the new package management system [elpa].

djcb: Did you ever try IDEs such as Eclipse? How do you think CEDET stacks up against such programs?

EML: I have used Visual Studio more than Eclipse, and certainly watched demos on how these and other tools work.

These tools win over CEDET's features in that they usually integrate directly with the compiler, VM or whatever, and have very good completion engines and UIs that you can interact with.

CEDET wins in that you don't need a compiler, or even code that can compile for it to work and start providing useful completions. It can infer an awful lot from a project.

CEDET's language support structure is thus simple in comparison, and CEDET supports many more languages as a side effect. It also wins because it is in Emacs, and I've done my best to try and match the "Emacs Way". For an Emacs user, this is intuitive, but can appear quirky to outsiders.

djcb: What about other development tools for in emacs?

EML: There are a lot of language specific solutions like GCCSense, slime, JDEE, and others out there. These projects are great in that they take a language, and push it to the edge of what you can do, and the users generally love that stuff. When someone wants to do the same thing, like when CSDE started for C#, and it tried to copy JDEE, it was just that, a copy that didn't quite make it.

It is my hope that CEDET will become the target of choice for users who want to make their language support in Emacs the best. They will save a lot of time doing so as well. The same infrastructure for integrating in external tools can be used to get improved results out of CEDET, but CEDET will handle converting that into a representation that would then allow any tool built on CEDET to work. This is the same model that worked well for comint.el, and gud.el.

Yasnippet is a bit different in the way it "competes" with SRecode. My first implementation of SRecode tried recycling tempo templates, but I couldn't get it to work. In fact all the template systems I investigated fell short of what I was trying to do, so I had to roll my own, and ended up using a variant of the Google template format.

The key difference is that the goal was for SRecode to provide a series of base templates for code generation. A tool writer would then write some tool to generate code. A user would then use the tool, and say "This is great, how do I change where the { goes?"

The answer is to override the template with that detail in it without interfering with the system templates. That only works if the templates are sufficiently granular that the changed template can be simple. Template reuse needs to be high so that if your company formats your methods as:

int mymethod() { implementme() };

instead of

int mymethod() {
}

that one template change will allow this to happen for all code generated from every tool.

Thus, the audience for yasnippet and SRecode is quite different. Of course you could do yasnippet like things with SRecode if someone took the time to improve the field-editing feature in SRecode, but that has not been my focus.

djcb: Do you follow the overall Emacs development process? Are there things you would like to see changed/improved?

EML: I watch the emacs-devel mailing list, mainly to see if anything related to CEDET goes by that I can help with, or what the latest cool feature might be. My first contribution of Speedbar to Emacs in Emacs 20 helped drive some features related to overlines, boxes, and other face attributes that appeared in Emacs 21.

In the future, once CEDET and Emacs cross merge techniques are hashed out, I would expect some key parts that need performance improvements might move into C. Another part of CEDET that I'd love to see become bound closer to Emacs is mode-local.el. It tries to simulate mode-local variables and mode-local functions. This is critical in a complex system like CEDET that needs to provide a language support author with fine grained control. There are good reasons not to make what is currently implemented "the Emacs way", but it would be nice to resolve those and enable mode authors a with a more powerful way to customize the user experience.

djcb: Do you have specific plans for CEDET in the future?

EML: Here is the short list:

• Improve Emacs/CEDET cross merging
• Offload tag storage to an external process - needed for scalability
• Design/define a "CEDET mode" as a way of simplifying the confusing array of distinct tools and modes that make up CEDET now.
• Finish the smart-context menu project
• Resolve the "code replacement" problem of parsing a block of code, transforming it, and re-creating that code in place reliably.

djcb: In addition to all these 'generic' improvements, are there specific areas where new contributors could make a difference?

EML: Supporting new "stuff" in CEDET is one big win. Stuff can be:

• New project types under EDE to ease transition from something like Visual Studio to Emacs.
• Language support, such as parsers, or mode overrides. Finding ways to take existing cool tools, like JDE's beanshell, or slime's inferior lisp process and allowing it to do work for CEDET is another big win.
• Templates for code generation in new languages.

Tool writing would also be good. JDEE's author Paul Kinnucan converted many bits of JDEE to CEDET and co-designed many of CEDET's parts along the way, such as semanticdb, and that was a huge help. ECB's current maintainer Klaus has also had a big impact on the way concepts are abstracted to a tool that depends on CEDET.

Naturally, joining the mailing list and fixing reported bugs and improving the doc is also a huge help, but not as exciting as writing new code. :)

djcb: Finally, many people want to start using CEDET, but it seems they have a bit of trouble to get started. Do you have any recommendations for them?

EML: Start with the cedet.info file which has many of the common setup configurations in it. If you run into something not explained well or at all, be sure to join the mailing list and be specific about how that doc failed. Very few questions on the mailing list refer to the doc, so the doc is rarely improved in a way that can help others.

Another good starting point is Alex Ott's article A Gentle Introduction to CEDET, which is very helpful.

Thanks a lot for your time, Eric! Wishing you a lot of success with CEDET and all your other projects!

narrowing buffer contents

'Narrowing' is yet another of those many useful emacs features that took me years to appreciate, mostly because I never really tried it. I may not be the only one, so here's a short introduction.

Narrowing is the concept of hiding the buffer contents except for what you are currently working on. This is useful when you don't want to be distracted, but also because it allows you to execute commands only on the narrowed part. You can narrow different things:

what's shown	name	binding
region (selection)	narrow-to-region	C-x n n
current page	narrow-to-page	C-x n p
function	narrow-to-defun	C-x n d
everything	widen	C-x n w

I never used narrowing for the current page, but apparently it's used by e.g. Info-Mode to show only one page.

That last one is pretty important to remember; it's not totally obvious how to get back to 'normal' mode where you can see everything. For this very reason ('where the #>*$@ did my text go'), always-helpful emacs by defaults disables narrow-to-region (but, for some reason, not the other ones). To enable it, put the following in your .emacs:

(put 'narrow-to-region 'disabled nil)

Also note that the mode-line will show 'Narrow' when you're in narrow mode, lest you forget.

When you're using org-mode there is an additional one you might want to memorize:

what's shown	name	binding
subtree	org-narrow-to-subtree	C-x n s

I'm using that last one quite often; I have org-files where I keep meeting notes etc., and when in a certain meeting, I only want to see the notes for that specific meeting.

One bug? feature? of narrowing is that line-numbering is relative to the narrowed area rather than the full buffer. I'd prefer to have the real line numbers.