Older blog entries for avassalotti (starting at number 13)

Tips on Emacs

Here a few Emacs tips and some gospel for those who are still using a butter-knife editor.

First, the most important skill you must develop is touch typing. This is what make the most difference in your productivity. I found out that Emacs is really pleasant when you are able to type, at a rate above 50WPM. One thing is sure, being able to type fast, make any typing task more pleasant. From my own experience, when you get good with the keyboard, you start spending less time reading about other people achievements and start creating your own cool stuff. And learning to type fast is easy. Find some online typing material and spend 15 minutes per day, working on your typing skills. You will never regret it.

Most IDE do a lot of code generation, because some programmers are too lazy to learn touch typing. So, they need snippets, IntelliSense, automated refactoring, etc. They’re all nice features. But, do they really make you more productive? I don’t think point-and-click programming is really productive. That is where Emacs comes in. Emacs, and also Vim, are different in the way they attack the problem of rapid development. They both try to make editing easier, and this is a truly challenging task.

Emacs gives you the power to make your editor. Some people may argues that, this feature made Emacs an operating system. Yet, it is this flexibility that mades Emacs so powerful. Almost all the commands in Emacs are coded with Emacs-Lisp — a full programning language built in Emacs. Even the cursor behaviour is coded in Emacs-Lisp. How many of these point-and-click IDE have you seen, which allowed you to change how you move the cursor? I bet the number is near zero. An example of this power, is a mode called chop. This mode makes your cursor behaves like a binary tree. It allows you to reach any line on your screen in O(log n) steps, where ‘n’ is the screen height. In plain English, this means you can reach any line, on a 130 lines screen, in less than 7 keystrokes. However in reality, the number steps is much smaller, because Emacs has a full set of other tools for moving your cursor, where you want it.

Now the interesting part, how to get good with Emacs. Learning Emacs is the same thing as learning touch typing. You need to practice a lot and frequently. The first thing you need to master is the keyboard shortcuts. There is a lot of shortcuts, in Emacs. There’s probably more than your brain can hold. But with some training, we will see that Emacs’ keyboard shortcuts are easy to remember. They all follow the same structure. Like touch typing, there’s also tools for learning the keyboard shortcuts. I highly recommend keywiz, which run within Emacs. This tool analyzes all the keyboard shortcut in Emacs, even the one you changed, and generate quizzes about them. Again, same idea as touch typing, practice about 15 minutes per day on a daily basis.

As your journey progresses, you will find the need to change some of the default behaviours of Emacs. This is done by putting stuff in your .emacs — the most precious file of any Emacs user. Trust me, you don’t want to lose this file. So, make sure you do regular backups or use a version control system, like Subversion, to protect it. How to use this file is an art itself. Some people like to keep all their configuration in a single file, some don’t; some others don’t care if it’s messy, some don’t; and so on. Personally, I like to separate the different components into smaller files. And, I like to use customize for the on/off type of settings. But, that is just question of personal taste. There isn’t a better .emacs. The best one will always be yours. You will, although, want to see how the others configured their Emacs. That is normal. We are all curious creatures, after all. A final note about .emacs, don’t spend too much time playing on it. Configuring Emacs is fun and addictive, but it won’t help your productivity by much, if you can’t touch type or use the keyboard shortcuts.

The last, but not the least, thing you need to know, is Emacs-Lisp. This is probably… No, this is the greatest feature of Emacs. And, it’s also the hardest to master. Learning a programming language is not the same thing as learning touch typing. Dumb practice won’t help you. You will need to sit down and think. Lisp, and all its parenthesises, freakes most people, who gots some programming experience. Unlike some people says, Lisp is easy to learn. There’s nothing exceptional about learning Lisp. You learn it as any other programming language. Get a book, read it attentively, write some code, repeat. That’s my general algorithm for learning programming languages, and it works. I learned several programming languages, including Lisp, this way. One more thing, knowing Lisp do not make you a superior programmer. What makes you a superior programmer is your ability to learn new ideas. So, don’t get caught by this lie from Lisp evangelists.

Emacs is still a great tool, even if you don’t learn Emacs-Lisp. In fact, many Emacs users never learn it and are still more productive than the majority of the other editors users. You can always copy-and-paste some Emacs-Lisp code found on the web.

However, I haven’t said yet why you should learn Emacs-Lisp. The reason is that if you know it, you can add features to your editor, on-the-fly, without even restarting Emacs. Did ever wished your editor had a particular feature? Well with Emacs, when you know Emacs-Lisp, you just add it. Emacs evolves with you. So, if you do a lot of programming, you will end with a lot of programming helpers and macros. On the other hand, if you write a lot of web articles, you will probably end up with a lot of text manipulation utilities. It is just beautiful, how Emacs can adapt to your editing needs.

Finally, mastering a good editor is a lifetime investment. You better choose one that can evolve with you or you will end up using many different editors poorly. Remember, that being productive isn’t that important, but the fun of mastering something is. You will smile when you will transform a painful editing task into a trivial one. So, enjoy your journey in the world of Emacs.

Syndicated 2007-03-03 20:26:21 from Alexandre Vassalotti

Don’t use fake emails

I just got a comment, on my post Pretty Emacs, which was:

<p>this is the error I get when trying to get your repositories

<p></p>

<p>Please help</p>

Has you probably see, the error message was probably truncated by the HTML filter of Wordpress. Unfortunately, when I tried to send an email to the author of this comment, I received a delivery error which told me that the author’s email address didn’t exist. So, I am stuck with a help request from a ghost.

I really care about the errors you get with the packages in my repository. If you stumble on a bug in one of my packages, it is my fault. And it is my responsibility to fix it. So please, don’t fake your email address when you leave a comment.

Syndicated 2007-03-03 00:15:26 from Alexandre Vassalotti

Daily links posting, not for me.

I disabled the daily links posting feature of del.icio.us. I tried it, and I don’t like it. Posting links automatically on my blog doesn’t feel right to me. If I want to share a link, I will do it myself.

Syndicated 2007-02-15 03:42:46 from Alexandre Vassalotti

links for 2007-02-14

Syndicated 2007-02-14 23:34:29 from Alexandre Vassalotti

links for 2007-02-12

Syndicated 2007-02-12 23:36:49 from Alexandre Vassalotti

links for 2007-02-11

Syndicated 2007-02-11 23:29:05 from Alexandre Vassalotti

Hello World!

For those who don’t know me yet, I am Alexandre Vassalotti (a.k.a. theCore on IRC), a French-Canadian from Montreal. Here some interesting numbers about me:

  • 19: My young age in year.
  • 20: Quizzes I have done in #ubuntu-trivia.
  • 34: The number of times I said “I love Emacs.”
  • 100: My estimated number of people I helped to use Ubuntu.
  • 195: My height in centimeters.
  • 539: Days rocking on Ubuntu.

Hopefully, I will be able to keep my blog on-topic. My roadmap in mind is to do posts about the interesting packages in Ubuntu, tips-and-tricks for Emacs and share my ideas how to improve the usability of Ubuntu.

Syndicated 2007-02-11 02:28:14 from Alexandre Vassalotti

11 Feb 2007 (updated 11 Feb 2007 at 05:46 UTC) »

Debian Packaging 101 (Part 1)

Making packages for Debian derivatives (like Ubuntu) isn’t really hard. It just required some dedication to learn how the packaging system work. Yet, most users don’t know how to make packages for their distribution. In this series, I will try to give a brief introduction packaging.

First, I would like to tell you that, if you never compiled a program before, this short guide will be useless for you. Therefore, I assume that you know and that you did compile a program before. Also, I will use the term “package” to refer to the compiled program package ready to installed on Debian or its derivatives. And, I will use the term “program” to refer to the software, like “GNU Emacs”.

A package consists of two things: the source code of a program and a debian/ directory which contains information how to build the program. There is different methods to specify the packaging information. The most common one, and the one I will discuss here, is using a tool called debhelper. This tool makes the packaging process easier by abstracting the common packaging tasks into little scripts, run at the build time. The typical directory structure of a package looks like this:

  gnu-hello/
  debian/
    changelog
    compat
    control
    copyright
    postinst
    prerm
    rules
  doc/
  man/
  src/
  AUTHORS
  ChangeLog
  configure
  COPYING
  INSTALL
  README

Obviously, this example is simplified, but you get the idea. That are the interesting things for a packager. By the way, GNU Hello a good example of package to study. You get it with:

  $ apt-get source hello-debhelper

Here, a quick description of the files in the debian/ directory:

  • changelog: The history of the package’s changes.
  • compat: A file that contains the debhelper version that is used.
  • control: The description of the package and the list of dependencies.
  • copyright: A copy of the licence the program uses.
  • postinst: A post-installation script used to setup things after the package has been unpacked.
  • prerm: Another script that is run before the removal of the package. It usually used to undo the things postinst has done.
  • rules: The instructions how to build the package. This is simply a Makefile.

In more complicated programs, there is usually other files. However, I won’t talk about them in this introduction. Anyway, I am out of time. In the second part of this series, I will explain the tools used to build packages.

Syndicated 2007-01-31 01:46:58 from Alexandre Vassalotti

29 Jan 2007 (updated 24 May 2007 at 23:26 UTC) »

4 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!