Too many cool languages (Python, Clojure, ...)

There is plenty of languages I like. I'm naming just a bunch of them here... so a non exclusive list may be:

1. Python
2. Common Lisp
3. Scheme
4. Clojure
5. Erlang
6. Haskell
7. Prolog
8. Ruby

The list is quite incomplete... for example I left out languages from the ML family. I do not have anything against them, I just think Haskell nowadays is way cooler (cooler != better) and also the Haskell platform is a definitive advantage. I did not mention languages such as Io, because although I'd really like to do something with it, it just does do not feel enough motivation to try and do it in Io instead than in one of the languages above.

Same thing for Javascript. It's not that I do not like it... it is just that if I can, I would rather use one of the languages I mentioned (which at least in case of client side JS most of the times is a no go). I also left out things like CoffeeScript and a whole lot of languages that did not even jump to my mind right now.

The list is quite representative of my tastes in programming languages. All the languages are very high level languages (I enjoy plain old C, but I tend to use it to extend the above languages and/or for problems which really need C points of strength). Most of them are declarative languages, almost every one of them has a strong functional flavor (basically just Prolog hasn't, the others are either functional languages or received a strong influence from functional programming).

Some of the languages are better for certain tasks, because they are built for them or have widely tested libraries/frameworks. And this somewhat makes it a difficult choice which one to chose. For example, every time a network service has to be written, I consider Python (Twisted/Stackless), Erlang and recently Clojure. If the system has to be highly concurrent, probably Erlang has an edge, but also Haskell (with STM and lightweight threads) and Scheme (Gambit/Termite) are strong contenders.

This is essentially about personal projects. In fact, for "serious" stuff, I am still using Python or Java (and C/C++ if more muscle is needed). This is basically because I have far more experience with those technologies. Clojure is probably a viable choice as well, as I can easily interact with Java and I have been using that quite intensively in the past two years (I also used it to extend one of the "serious" projects, though I had to remove it because I had other experimental components and it was tiresome to find out whether bugs were due to the other components or my relative inexperience with clojure). Besides, I have still to find winning debugging strategies for clojure: probably I'm missing something obvious here. I'm also trying to increase my expertise with Erlang.

These are some random thought about developing in the environments.

Editing Tools

The first issue, is to find the right tools. It is not exactly easy to discover the right tools to develop in non mainstream languages. For example, with Java any major IDE is a good enough tool. For Python, both PyCharm and WingIDE are excellent and easy to use tools. Moreover, vim is an excellent tool with only minor tweaking. Oddly enough, I'm still struggling to find a good setup for Emacs.

On the contrary, Emacs is quite easily one of the best environments for Scheme/Common Lisp/Clojure (thanks to slime), Haskell, Erlang and Prolog (thanks to the improved modes). Still, after years of switching back and forth from Emacs to vim and vice versa, I think I'm more comfortable with vim. Unfortunately, it is not always the case that customizing vim for these languages is as easy as it is with Emacs. For example, I found an easy to use Erlang plugin, but I have still to try using advanced plugins for Haskell and Clojure (I know the plugins, still I did not finish the setup). For Clojure it's just easier to fire LaClojure or Emacs+Slime. For Haskell, I'm not serious enough to know my own needs. I wrote software for my bachelor's in Prolog with vim, and I have to say that Emacs is quite superior (especially considering Sicstus custom mode).

Back in the day I used TextMate for Ruby. Right now I guess I'd probably go with RubyMine or vim.

Platform

Now this is a serious point. Many of my "difficulties" with Scheme lie here: chose one interpreter/compiler with libraries to do most things I want to do and some tool to ease the installation of other libraries (I should probably just stick with Racket). For example with Python it is easy: pick the default CPython interpreter, use pip/easy_install for additional libraties.

Common Lisp is also going well (SBCL + Quicklisp here). I was pleasantly surprised by Haskell: the Haskell platform is wonderful. Some years ago it was not completely clear which interpreter to use and external tools (like Haskell) were not completely immediate. Now with the Haskell platform you just have everything under control.

About clojure, I feel rather satisfied. For project oriented stuff there is leiningen, which works fine. My main objection is that most of the time I'm not *starting* with project oriented stuff... which is something which so much remembers me of the Java world, where first you start a project (as opposed to unix, where you just start with a file). Luckily enough in the clojure community there are also guys like me, and so there is cljr which just fills the area of "before" something becomes a project.

Cljr is very nice with emacs/swank/slime. Unfortunately I've not yet found a way to make it interact with vim.

Erlang already comes bundled with an interesting platform and rebar does lots of nice stuff too. Erlang/OTP tends to be a bit too project oriented but it quite makes sense. Basically all of the times you are setting up systems with many processes and all and it just makes sense to do it that way.

Prolog is essentially a complete mess. I advise just using SWI-Prolog and forget the rest even exists, unless you need some of the advanced stuff Sicstus offers. In this case you pay and enjoy.

BBEdit 10 is out

Essentially that is the new. That and the fact that eventually they dropped the price to reasonable levels (39 $, IIRC). Unfortunately, the upgrade from older versions is also 39 $ (so I just bought a new serial).

The real question is why I keep buying BBEdit. I suppose I'm nostalgic about the old MacOS. It is a good editor, nothing to say that. I find it excellent with HTML and also has a nice PostgreSQL mode (not just SQL, it supports PosgreSQL dialect). The syntax highlighted grep searches (that is to say, regular expressions in fact, not grep) is another nice feature.

Other nice features are the possibility to customize the different modes (e.g., Python tab 4 spaces, auto-expand tab -- that is to say that tabs are not written in the source). Nothing other editors do not have, still, it is quite easy to customize. A couple of nice features is the fact that trailing whitespace stripping and trailing newline addition can be enabled. Once again, nothing vim and Emacs do not have, but easy to setup and somewhat missing in other "lesser" editors.

Among the addition of version 10, BBEdit has improved project management features, support for different color schemes (before that, a hack had to be used -- and the hack is forward compatible: color schemes for that can be used for the official feature).

While when I first tried TextMate I thought the next big thing after Emacs and vim was there, BBEdit is just a solid MacOS X editor. I like the fact that many a program is aware of BBEdit and lets me use it to edit stuff (and that is usually an improvement over the built-in editor). I will not stop using Emacs or vim for my serious editing, but BBEdit is a nice tool to have around.

Technorati Tags: Editors, BBEdit, Emacs, Vim

'(leiningen slime Emacs) are the way.

Leiningen seems to be really the easiest way to create a clojure developing environment.

Up to now, I worked mainly with IntelliJ + LaClojure. The rest of the project is Java (so having IntelliJ is a huge plus) and is very "project oriented" stuff. In fact, it is not even possible to think about individual scripts or so, things are meant to work in an environment and the environment needs to be started beforehand. As a consequence, a solution which does not work well "one file at a time" is not a big issue right now.

Although LaClojure plugin is very good, I feel more at home with Emacs. Not that I'm been an assiduous Emacs user (I use and used pretty much everything), it is just that Emacs has been optimized in last "don't even know how many years" to work with Lisp. Emacs indentation is beautiful and all. Moreover, leiningen should be a good choice even for my main project.

As a consequence, I decided to test leiningen with smaller projects.  I started a one file project as an example. The first step was just lein new'ing, then I had to manually add the :dev-dependencies [[swank-clojure "1.2.1"]].

$ lein deps

Then it is just a matter of lein swank and the server is there, waiting for my Emacs to connect. I had already installed slime (and swank) for my common lisp development. I installed swank clojure and set some configuration variables in my emacs configuration:

 
(require 'clojure-mode)
(add-to-list 'load-path
             "~/.emacs.d/swank-clojure/src/emacs")

(setq swank-clojure-jar-path "/usr/local/Cellar/clojure/1.2.0/clojure.jar"
      swank-clojure-extra-classpaths (list
                                      "~/.emacs.d/swank-clojure/src/main/clojure"
                                      "/usr/local/Cellar/clojure-contrib/1.2.0/clojure-contrib.jar"))

and that is the rest of the slime related configuration

(eval-after-load "slime" 
  '(progn (slime-setup '(slime-repl))))


(setq load-path 
      (cons "~/.emacs.d/slime" load-path))
(cond
 ((macosx-p)
  (setq inferior-lisp-program "/usr/local/bin/sbcl --noinform"))
 ((win-p)
  (setq inferior-lisp-program "C:/Program Files/Steel Bank Common Lisp/1.0.37/sbcl.exe --noinform")))

; (slime-setup)
(require 'slime)
(require 'slime-autoloads)
(add-hook 'slime-repl-mode-hook 'split-window-vertically)

I think that I should improve the configuration, as it is still sub-optimal. However, with M-x slime I just run a new sbcl slime server, with sbcl client. Then I can use it just to hack with common lisp. On the other hand, M-x slime-connect asks me which server to connect. With default values, if I already run lein swank in my project, it connects to that one (but ports and servers are completely configurable).

At that point I have a familiar lisp developing environment. I can easily compile and load with C-c C-k, reload every function with C-M-x and everything that is standard in slime.

It seems that functions in src/projectname/core.clj can be used directly when they are loaded with C-M-k, but not with C-c C-k. However, I find more useful to do the latter most of the times. Moreover, I believe that files outside src do not load directly in user. Besides, I prefer not to. As a consequence I switch namespace in slime.

(in-ns 'org.enrico_franchi.paip.simplegrammar.grammar)

I believe that this should make clojure.core functions not accessible; however, I have the habit of importing the "core" libraries (at least, I did that in common lisp packages, as recommended). Consequently my namespace declaration is, for example:

(ns org.enrico_franchi.paip.simplegrammar.grammar
  (:use
   clojure.core
   clojure.contrib.combinatorics))

And slime is in my namespace, so I can use the functions as I want (user is not modified) and I can also call clojure.core and whatever I need.

Technorati Tags: Clojure, Lisp, Programming, Leiningen

Lexical Scope vs. Dynamic Scope

Most languages have lexical scope, nowadays. This is good news, as it is easier to use. In fact, many programmers do not even know the difference between lexical and dynamic scopes, leaving the distinction to programming language junkies.

In languages with lexical scope a variable name is resolved to the object with the same name in the nearest lexical environment. In other words, the compiler chooses the innermost object considering local variables, function parameters, enclosing function variables, global variables and so on. If it is not clear, by the description I gave (which is not clear, I admit) just think to C or Java or Python. That is lexical scope. It is also called static scope, as it can be statically determined with just the source and no runtime information.

It is good because the one who writes the function knows the environment where it is defined (and that is what matters), while the one who calls it does not need to know anything about it:  just to pass the parameters. On the other hand, with dynamic scope functions access the object with a given name that is *nearer* on the call stack. That is to say... the caller environment influences the function behaviour.

Early Lisp dialects have this strategy, as well as Emacs Lisp. Luckily, Common Lisp default mode is lexical scope (but dynamic scope can be used as well). Perl has dynamic scope (with optional "my") static scope.

A good example of the two different strategies is this snippet:

(let 
    ((f (let ((x 1))
          (lambda () x)))
     (x 0))
  (funcall f))

If that snippet is evaluated in emacs *scratch* buffer (C-j) the result is 0. This is because when f is executed, the x nearest in the call stack is the one labeling 0. On the other hand a common lisp compiler would evaluate the thing to 1, as the x referenced in the lambda function is the one in the lexical closure.

* (let 
    ((f (let ((x 1))
          (lambda () x)))
     (x 0))
  (funcall f))
; in: LAMBDA NIL
;     (LET ((F
;            (LET (#)
;              (LAMBDA # X)))
;           (X 0))
;       (FUNCALL F))
; 
; caught STYLE-WARNING:
;   The variable X is defined but never used.
; 
; compilation unit finished
;   caught 1 STYLE-WARNING condition

1

Emacs, Lisp, Functional Programming

JEdit: the forgotten editor

These days, I'm rethinking lots of stuff regarding my geeky life. For work reasons, I hugely increased my exposure to Java. And to my surprise, I find it quite bearable. Perhaps, one day, I'll say that I actually like it. This is much more likely if they just add closures... but that's another story.

In this process, I decided to try JEdit. Back then, some people suggested JEdit as a viable alternative. I quite refused the claim based on some hasty experiments. I think that my bias was such that I could not be pleased with it. Perhaps back then (10 years ago or something like that) it was not that good; perhaps not. And then I sticked to my early negative experience.
As a partial excuse I can point out that back then the unix community was very skeptical on everything which was not vim and Emacs (with the same old flame wars among the editors).

Right now, I'm using jEdit quite a lot and I want to describe my impressions. First: its main drawback is that it is slow to load. It is quite objective, even on my MacPro. However, BBEdit is not much faster and I use that regularly. But like BBEdit it is very fast to open new files once it is opened. In other words, you can just leave it open and that is fine. Of course, with vi this is not necessary. The other major drawback is that it can't work in text only mode: if you need to edit files remotely, you might be in a trouble.

However, the ssh/ftp plugin is quite useful and partially solves this problem. By the way, there is no reason not to use vim when needs arises.

jEdit supports 130 syntax languages (according to wikipedia, I did not count them), which is good. In fact, it is likely that you open a file and gets the correct syntax highlight and customizable options for each of them. Which I find nice.

Plugins

jEdit plugins are very easy to install; easier than default installation process on Emacs and vim, though auto-installers are catching up. In fact, even easier than text mate and bbedit plugins. In the plugin list, there are lots of different plugins; the majority are java related, but this is not exclusive. Some plugins just remind me of good old programming practices. For example the whitespace plugin does many whitespace related functions, like showing trailing whitespace and auto-removing it on save or auto-converting between tabs and spaces. This is something most programmers want.

jEdit has very flexible frame management. It is possible to split text area in different parts, dock and undock specific panes. For example with the Console module it is possible to have a "shell". The users chooses to have it in a separate window or to place it at the bottom of the main frame. Emacs anyone?

Of course, in the console windows it is possible to place many different REPLs, such as a Python or a Prolog shell. Or clojure (which, is also installed by the plugin: installing the plugin fully sets up a working clojure environment).

Another very useful feature is the integration with BeanShell (which allows running Java snippets). Moreover, plugins can also be written in Jython and other JVM supported languages. Of course there are plugins providing Java autocomplete and refactoring and similar stuff.

The are plugins to do spell-check and most things one expects from a text editor, latex mode, etc etc etc. The XML mode provides autocomplete for HTML files (or perhaps it is just builtin), and that makes it quite a powerful editor for HTML.

Macros

jEdit supports macros, which should be rather akin to other macro facilities ;they do not only generate text (but can remove, modify or do completely text unrelated stuff like changing interface elements). I have not explored this part yet.

The Editor

Then, it comes to basic text editing capabilities. Here is the point where most NENV (Non Emacs, Non Vim) editors fail. They just suck at manipulating text. jEdit, even though not the most powerful editor I tried, is an honest contender here.

Abbreviations provide expansion of long snippets of text. Buffer based completion is also available.

The clipboard is very powerful: there are "registers" and it is possible to manipulate text in there, append text to clipboard, vertical paste, etc. All this possibilities have keyboard shortcuts.

Selection is also keyboard controllable (move one word/character/paragraph forward/backward etc). It is possible to select code blocks, up to parentheses, etc...

Search comes in two flavors: incremental search and "standard" search. Regular expressions are available. Moreover, it is possible to apply search to whole directories, filtering files according to file names. The "replace" part can also be provided by a bean shell expression, which basically gives unlimited power to the replace feature.

Other text related features (spaces->tabs, lowercase, delete to end of line, delete to start of line, etc) are provided. So it is paren matching.

Markers (bookmarks) are supported, and so it is folding. Some utilities (file managers and similar stuff) are provided, and manual editing of jedit configuration files is also available.

Conclusion

I think that jEdit is a seriuos contender in the "2nd generation" editor market. It is free, it supports many languages in a rather complete way. Of course, many languages which are supported in Emacs (haskell, ocaml, erlang, ...) are not supported. However, it is a nice alternative to do lightweight java editing, to work with Python, web editing and similar stuff. Moreover, it is a very interesting alternative for Clojure/Scala development.

Me and my IDE

Introduction

As customary in my articles on text editors and IDE I originally started this post with a self-condescending presentation of my skills and expertise. Then there have been some miscomprehension between chrome and blogger and the second part of the draft was not saved although blogger stated otherwise.

As a consequence I had the more self-condescending part and I lost the slightly more interesting one. I thought to do everybody a favor and delete that stuff. Now, a slightly less condescending paragraph on myself in order to motivate my point of view.

The past

I almost always used editors. Emacs, vim… and when on BBEdit and TextMate. Ah… light tools. Not only that: I was quite vocal in the IDE vs. Editor war (from the editor side, of course). And this can also be related to my choice of  “freedom languages” (more on this on later posts, perhaps?).

But some weeks ago I realized that now, without noticing, I’m mostly using IDEs. How has that happened? The easy part to explain is the Java related one. Java greatly benefits from IDEs (or perhaps the widespread diffusion of IDEs has tampered the development of good language features?); in fact it is quite much harder to develop Java without an IDE, since the language is very verbose. On the other hand its restrictions and bounds make it quite easier to develop good and powerful tools. Of course I could use UltraEdit on Windows… but no luck with OS X and Linux (moreover, I had to pay that as well… and I preferred to buy IntelliJ).

Emacs has very nice modules to work with Java. On the other hand they have to be installed separately (and in my experience also slowed down normal operations). When I have to loose to much time configuring my editor, I usually try other solutions. That is why I used TextMate and BBEdit extensively… because they are almost already set-up. I also like vim, since has decent default setups for most situations.

For somewhat similar reasons, I bought WingIDE to work with Python. I could set up Emacs (or vim) to do that stuff, of course. Still, I had not much time, not motivation… and I bought the thing. I especially liked it because it worked equally well on single files and on large projects. It also had the best auto-completion for Python I ever tried, nice debugging features (I use them rarely, but when I do I love to have an easy to use environment, especially because I use them rarely and I tend to forget the tricks). In the pack there is also nice support for unit-testing (and that is a definite plus).

In the same time I worked extensively with C++. I mostly used editors (vim, because I especially like it with C/C++) and BBEdit because of its easy to set up “project management” features. BBEdit also has most the processing power of classical editors and that is nice. I quite enjoyed the best effort auto-completion it provided and ctags based stuff. Ok… still too much template metaprogramming (or simply correct and not basic use of templates) crippled smart “IDE like” features which I would have liked.

In other words, I sincerely craved for a nice C++ IDE. Perhaps I should try Java based IDEs with C++ as well… I may be surprised. Though I hate setting up projects in IDEs. Every IDE has its conventions and it is not always immediate how to work with a project that both needs “classical command line build interface” (which is something I’m not disposed – nor can I afford to – lose) and the IDE based build. Somewhat CMake eases the problem, but at the price of restricting myself to the supported IDEs.

Other languages I use, but I think that they account for less than 30% of my development time (and it is going to drop). And perhaps they could be moved to IDEs as well… as soon as I solve the “single file project problem” [or I simply give up my hopes with that].

This basically rules me out from editor flame-wars. Still, I believe that learning using IDEs is a terrible mistake… but is a modest position. Moreover, nowadays most editor proponents show you how to add all the IDE features to their editor of choice. So what’s the point? It’s not an Editor vs. IDE matter, it’s Emacs vs. Eclipse. And somewhat I believe Eclipse is going to become what Emacs was in the past years. And hopefully it is going to become faster like Emacs did…

The future

So what now? I’m lazy to the bone. And I’m quite new to the IDE world. I have my habits and I don’t really want to change them. And don’t believe the ones who tell that using IDEs is easier. Nor faster. It depends on your skill set. As I have my own requirements, some things may be slower with IDEs, at least until I figure out how to do them.

Which basically means that an IDE is not automatically more productive: it may be, provided that you know the tool. Yes, some have a very good learning curve (like WingIDE), others are very good, but need you to figure the way they work to exploit them fully (IntelliJ). Moreover, I still have to figure out how to develop Java projects easily built both with IDEs and with command line tools. Perhaps I should explore maven (which should be well integrated with all the main IDEs). After-all its racist on my part to spend time with cmake and auto-tools and not doing that for Java “based” projects.

ErgoEmacs

I recently stumbled[0] on the ErgoEmacs project. Well, it looks very promising.
I like the huge set of libraries they packed in and how easy it is the installation process.
If I discovered this one before, it would have saved me lots of time in learning the minimum basis of elisp needed to configure my emacs.

Unfortunately, in the meantime (which means... a lot of years, indeed) when my brains sees an Emacs window, it switches to Emacs mode. That is to say that  the easier keybindings ErgoEmacs provides are, for me, very hard to learn. This is rather surprising, since when I use TextMate or BBEdit I don't have no troubles in using the editors (though many Emacs keybindings are recognized).

I don't even have troubles with vim. Why is so hard to use an Emacs which does not behave like Emacs, considering I'm not particularly fond of how Emacs behaves? What did Emacs do to my brain?

Notes

[0] Thanks, Nicola!

Oh, my Clojure [Emacs]

Clojure is very well supported in Emacs, of course. The instructions are here.
The Emacs Automatic Package Manager is needed!
Stuff on vim and TextMate, here.

I followed them I found myself with no usable REPL. I tried both with slime (which works, though I don't like how) and without, which basically does not work.

In fact I have to admit I'm not extremely pleased with the current situation. I suppose I will stick with IntelliJ. There is another Clojure plugin besides LaClojure, and perhaps that one works better. I may also be in the phase "I like scheme better than clojure right now" and that could explain my dissatisfaction.

I'm probably to try NetBeans with its plugin (LaClojure is broken right now).

Emacs Automatic Package Installer

While following the instructions to install clojure support for Emacs, I stumbled in  an automatic package installer. Installing the package installer is the nicer thing I have done with emacs.

You basically put this snippet in the *scratch* and C-j. I wonder why more packages do not follow this procedure... well, perhaps it's not necessary after I installed the package manager.

(let ((buffer (url-retrieve-synchronously
        "http://tromey.com/elpa/package-install.el")))
  (save-excursion
    (set-buffer buffer)
    (goto-char (point-min))
    (re-search-forward "^$" nil 'move)
    (eval-region (point) (point-max))
    (kill-buffer (current-buffer))))

Oh, my clojure! [TextMate and Vim]

I started hacking with clojure some time ago. I was looking for a decent language on the JVM and I found a wonderful language. Since it was "JVM stuff" I started working with JVM tools. That it to say, Idea.
Which is great, by the way.

Now I believe my reluctancy to use clojure is related to Idea. Idea has a rigid "project-based" approach. I kind of circumvented it creating a "clojure" project where I put all my scripts, and it kind of works. However, most of the wonderful features of IntelliJ are not useful in Clojure (I have HOF and macros, who needs IDE code-generation?).

On the other hand, I happily use Emacs for most lispish (and functional languages in general) I use. It works great: the interpreter is in its frame and I can just try snippets of code. By the way this is available with LaClojure (that is to say IntelliJ clojure plugin) as well. Well, it was, since now it is broken and does not work with clojure 1.1.

Here I found instructions on adding nice clojure support to TextMate. In principle the support looks rather good, though it seems broken. I have no time right now to fix it.
Edit: apparently it is not an issue with TM bundle. I had issues with cake related to the interaction between some environment variables set by zsh (with my custom zshrc file) and cake. Now the thing works as expected. Still, no REPL by design. Probably the REPL is meant to be in the terminal and that's it. Nonetheless, I don't like it very much.

The instruction for vim are here and here you can directly download the package. Unfortunately the package seems to have been compiled for windows and I probably should recompile and do a bit of configuration. The documentation is not extremely clear, though it should do. Probably I will try to make it work. Right now does syntax highlighting and all the nice editor things: the piece which I did not manage to make it work is the REPL inside vim.

Emacs, Carbon Emacs and color-theme

I don’t like very much standard emacs theme, especially when in “GUI” mode (that is to say Carbon Emacs/Aquamacs if you are on the mac).
Luckily color-theme module does an excellent job. I have a long list of themes ready to be selected. In fact, for nostalgic reasons I like the “Classic” theme.
I wanted this theme to be automatically loaded when I start Emacs. Unfortunately default OS X Emacs does not have color-theme installed (and I don’t mind the way it looks by default in the terminal). So it was only a matter of conditionally branching between GUI emacs and terminal Emacs.
Moreover, I could not use (require ‘color-theme), for this would give error when run in the terminal version. This is my solution:

(defun my-color ()
 (load-library "color-theme")
 (color-theme-initialize)
 (color-theme-classic))
    (if window-system
     (my-color))

Emacs and emacsclient (Ruby script to call them both)

I usually call one single emacs server (I've got (server-start) at the very beginning of my .emacs), then connect to it with some emacsclient.

Unfortunately enough emacsclient just quits if there is no active emacs server.

I need a process that tries to run emacsclient: if there is no active server, it runs emacs.Moreover, emacsclient has a -n switch that makes it return ASAP, so the terminal is available for more commands.emacs has not such a switch, but that behaviour is the one I want.

So I decided to write a small ruby script that does just this:

1. Tries to run emacsclient with the -n option.
2. If it succeeds, we are done. Otherwise we run Emacs doing some standard posix process manipulation in order to return to the shell as soon as possible.

This is the script:

#!/usr/bin/env ruby

fork do
    exec('emacsclient', '-n', *$*)
end

Process.wait
    if $?.exitstatus != 0
        fork do
        Process.setsid
        Signal.trap('HUP', 'SIG_IGN')
        exec('emacs', *$*) if fork.nil?
        exit!(0)
    end
    
    Process.wait
end

Adding scrolling to Emacs...

Easy...

;; mouse-wheel: scroll
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)

I found a lot of posts about this, but none worked for me. I just took some pieces of information here and there and I came up with this (that works for me).
Emacs 21.4 on Ubuntu PPC.

Developing on Mac, Win, Linux (Editors - pt. 1)

I kind have to tell something about me, since it better helps understanding my position.

I chose MacOS X as my main developing platform. Of course it happens to write software meant to run on GNU/Linux (or other *nix flavours) or even on Win. Usually when this happens I'm using a cross platoform technology. I never wrote something longer than 100 lines with the WinAPI, for example.

Before I used GNU/Linux, fBSD and even before other unices (OSF1) and MacOS "Classic". This is my background. I never quite got exposed to windows. So my point is unusual: most people come from windows to other platforms. To me is quite the contrary (a part that I don't "go" to windows, I just happen to use it from time to time).

About programming environments, I've done (and do) lots of things. I like high level languages, such as Python or Ruby. I like ObjectiveC and Cocoa (of course this won't be in our comparison...). But also do a lot of low level C coding with the POSIX api (well I did... right now I prefer to do it in Python), develope some software in C++, I'm going to graduate with a project in Prolog. I quite like XML and CSS and I also have to use some Java and some calculus (both Matlab and C -- no, I don't quite master Fortran)

So my skills are not particulary vertical (for example someone who does all his job in the XML processing fields, or numeric calculus). They range in many different fields (this does not mean I'm really "guru" in each of them, on the contrary I've got much to learn).

Editors

Basically those who work in the Linux community used to share in equal parts between Emacs and vim. There used to be some other editors (nedit), but that was the story. Recently I've seen a lot interest around IDEs (kdevelop, anjuta) and some "lesser" editors have reached the status of full programmer's editors. Among these Scite and Kate, for example. Moreover HTML/web centric editors have also increased their popularity.

On the other side the Windows community has always been more IDE oriented. There were the Borland products, Microsoft Visual Studio, Wacom. The most used web environments were Dreameaver and Homesite (now builtin in dw).

Of course there were also a bunch of editors.

Linux pt. 1

If I have to work on Linux, I've got no problems of any sort. I'm average skilled both in vim and in Emacs and I can make it. I do use Aquamacs (an Emacs version) even on the MacOS: once I preferred vim, but right now I need some things Emacs has and vi hasn't (a decent Prolog mode, for example).

Windows

About an year and an half/two years ago I had to develop an application with Twisted. For a 0-based array of reasons I used Windows as my main developement environment. I installed entought python (and in those times there was no Python 2.4, so no problem), I put Twisted 1.3 on the top of it and chose gvim. Gvim is beautifully integrated with windows. Of course it acts quite much like vim does (i don't like the evim variant). I did it. Still I wasn't using windows. I cloned my linux environment on Windows. And it is what I made when I had to code some C++ with mingw and so on.

I chose to use gvim not because I really wanted to, but because other editors were really priced or poor. Yes I tried scintilla too. Not particulary poor, of course not priced... but in fact too simple.

Windows and MacOS

If you compare the situation with the MacOS it's tragic. MacOS has many "simple" editors that I do not really like (but some love SubEthaEdit or Smultron), but it has also BBEdit (the best web editing environment I've seen, much better than dreamweaver and priced 199$ - 129$ for TextWrangler users -- TW is a free editor everybody can download and use ). And it has TextMate: the best general programmer editor a part from Emacs.

UltraEdit (Windows)

Recently I had to do some more work: I tried UltraEdit, priced 39 $. The same as TextMate. A couple of users said it is a wonderful editor and I gave it a try. Out of the box it did not support nor Python nor Ruby. Quite annoying in fact.

I googled the solution and I find I had to copy some strings in a file. The format is awful. Where TM has a lot of small bundles, BBEdit has plugins, UltraEdit has only this big flatfile. Ok. What matters is functionality.

But functionality is missing. For example Python or Ruby indenting is really disappointing. TextMate indents code back and forth to match the syntax of the code. It takes less time to try than to read. If you haven't a Mac, Emacs does it.

TextMate also has lots of ways (and easy one) for saving me from typing lots of code. Snippets are poweful, and I also have commands (snippets are short words or commands that are expandend to full constructs with placeholders to fill in).

I find nothing like this (nothing that simple) in UltraEdit or in Scintilla. Not that Scintilla is not a bad editor. It correctly deals with a lot of languages, the syntax theme is clear and easily readable (I think I should do a "Scintilla Theme" for TextMate one day). With Python/Ruby it lets you run or check syntax directly from editor.

And UltraEdit (in the Studio Version) is a very good "tiny ide"-"enhanced editor" for Java, for example (but we are at 99$). Much better than BBEdit or TextMate in Java editing. It's fast and has some useful basical functions. Of course Eclipse or NetBeans do a lot more stuff, but UltraEdit Studio takes a couple on microseconds to load.

I've not tried it with PHP and HTML (have I already said I don't use PHP?), but it appears to be really good. I just can't stand feature bloated IDEs like DreamWeaver. They tend to make the programmer not to think... but that's another story.

The many windows editors

It could be a matter of taste. Another friend of mine who did a lot of coding in Windows suggested another text editor (I don't even remember the name of the editor -- I still remember my friend's name of course). Probably among all editors out there (more or less shareware) there is the one that suits my taste (a part from the Emacs/gvim variants). Still everybody knows a good way to fuck up a windows installation is to install and try software (I know ghost, but it looks like I've no time to waste to play with software).

GNU/Linux pt. 2

Again... GNU/Linux is quite convenient in this sense. Emacs and vim are wonderful editors (and they are both free and free). They can be extended to do almost everything (think about Emacs mode to make it a Java IDE or the Auctex package).

They are both available for Windows and Mac, but additional packages are not as easy to install (on Debian is a matter of aptgetting...)

About the IDEs... well, KDevelop is told to be really good. Probably For sure it outperforms XCode, but should be not as good as MS Vistal Studio, even if it should support more languages (so if you need one of those...). So depends on what you have to do... anyway it's a really good IDE, nothing to say... but :)

Windows pt 2

I tried some more editors. Notepad++ is nice (but not really suited for Python or Ruby: in this sense Scite is much better).

I tried Komodo, and it's wonderful (and also cross-platform). The best thing it does are easy debugging and intellisense like for dynamic languages (tried with python and ruby, it should work with PHP and Perl too). Unfortunately the full version costs almost 300 bucks. If you don't develop professionally you can buy the "personal or educational" version, that at 29$ is quite affordable.

Anyway some things in Komodo to me look quite akward, while TextMate is as easy as poweful. Of course comparing Komodo to TM in Rails editing is playing dirty. TM is the editor of choice of Rails developers. And Komode has that intellisense... well, I think it should be great (even if I didn't really use it, so I think I'm not really gonna miss it).

I've seen there are a lot of targetted small IDEs that are worth trying, but I'm not gonna spend all my time this way.

Next time I'm gonna talk about databases

Emacs bindings in Cocoa?

Key	Meaning
ctrl-q	Beeps. If pressed twice deletes selection.
ctrl-w	Cuts text
ctrl-e	Moves to end of line
ctrl-r	Beeps??
ctrl-t	Swaps near characters
ctrl-y	Pastes text
ctrl-u	Beeps??
ctrl-i	Beeps??
ctrl-o	Insert new line after current
ctrl-p	Moves cursor to previous line
ctrl-a	Moves to beginning of line
ctrl-s	Beeps??
ctrl-d	Deletes character on the right
ctrl-f	Moves forward one character
ctrl-g	Beeps??
ctrl-h	Deletes character on the left
ctrl-j	Beeps??
ctrl-k	Cuts line from cursor to the end
ctrl-l	Does nothing?
ctrl-z	Beeps??
ctrl-x	Beeps??
ctrl-c	Beeps??
ctrl-v	Moves half screen down
ctrl-b	Moves backward one character
ctrl-n	Moves cursor to next line
ctrl-m	Beeps??

Aquamacs 0.9.7 is out (Printing + Latex + ... )

Download/Scarica

Among new features, you can print right out of the box (using Preview.app) and Auctex is beautifully integrated with Emacs. In fact it is the more user-friendly and more complete latex editing environment I've ever used.

And don't forget to read this, if you want to make it even more user-friendly.

In short:

1. Copied txs-search.el in my ~/.elisp directory (which is loaded inside Emacs with (add-to-list 'load-path "~/.elisp")
2. Loaded txs-search.el in Emacs adding in .emacs(require 'txs-search)
3. Added shortcut with (add-hook 'tex-mode-hook (lambda ()(local-set-key "\C-c\C-j" 'txs-jump-to-line))). This does not work, I have to call directly Meta-X txs-jump-to-line. I also tried different keybindings, with no success.
4. Changed editor line inside Texniscope, and cancelled useless option for alternative editor (read this in the tutorial I linked above)
5. Compiled dvis with -src-specials option: everything works as expected (except that I'm not able to enable source specials with pdf, I'll have to take a look at it)

In the end I have to thank David Reitter for the tutorial for Emacs/Texniscope, which I suppose is taken from a mail/post he did.

More on Aquamacs (frames and dired)

This is a short tip from the wiki (and most of the notes here will come from the wiki)

After some time, I found quite annoying the way Aquamacs manages frames and windows when I use it as a filemanager (which is something Emacs is really good at) -- in fact this ain't a problem, since I rarely use it that way and I can quickly change behavior with a menu toggle --.

If you would like it to behave like "traditional Emacs" you may want to read this tip

Since I was speaking about dired mode, I add it here: another tip. With this you can open files using mac os open command.

Mac Emacs (Aquamac)

Unfortunately enough this seems to be going to be a "text editor blog", with BBEdit post, this post and almost finished post about TextMate.

In fact I already told Mac Emacs versions do seem to miss something, and this is the reason why I chose to buy TextMate (a cheap 39$ affair).

Right now I'm just trying to convince myself that TextMate was worth 39$. I mean, probably if I discovered Aquamacs earlier (the first version I tried long time ago were "new") I would not have bought it (even if once I was a vi fan -- and in fact I still am, for some things).

And not because I don't like TextMate anymore... just because Aquamacs is free and is free software [ which is good ].

Aquamacs

You can download Aquamacs here.

I told how weird do seem Emacs key bindings on MacOS (in fact they look odd everywhere outside Emacs). Some of them are pretty standard, readline supports them by default (and so most command line applications do) and Cocoa controls also do (that is to say they work in any text editor.).

I'm talking about ctrl-a, ctrl-e, etc.

But you are never going to convince a Mac user he has to ctrl-x ctrl-s to save or ctrl-x ctrl-c to quit.

So Aquamacs uses standard Apple bindings. Command-C, Command-S, Command-Q. This way the command-key is not free. And meta has to be mapped on alt.

So if you have a not english keyboard, you may not be able to type square brackets, for example. And braces. In fact this is a serious design flaw, in my opinion.

In fact I found out the flaw was in the user (me) who did not read the wiki. Meta, Apple/Command, Option keys are fully configurable.

In my opinion if you are going to use Emacs, you expect to find Emacs key bindings. The more logical choice is to use Command for meta, and leave alt as alt, to enter braces (and on american keyboards accents.).

Still you may want (and it is my choice) to allow Command-key to be used for mac key shortcuts, but you want to pass option/alt to the OS (so that you can use [] and other characters). You do this with

(setq mac-pass-option-to-system t)

.

Should you have troubles with copying and pasting text from outside into Emacs or vice-versa, try to use

(setq x-select-enable-clipboard t)

In fact you can find lot of informations in the wiki:

Emacs wiki.

The nice thing was that you are able to use standard MacOS open and close dialogs, that is really nice.

But there is something even more beautiful features:

• Frames are mapped to windows: when you open a file, you open it in a new window, and you can manage windows with Expose. Probably a hardcore Emacs user is not going to like this (but probably he will prefer some other more standard version).
• Fonts: fonts are nice. It uses MacOS fonts and locales and unicode characters appear to be handled correctly (not sure for full unicode, for european >7bit characters, it works).
• You also have transparencies. It's just a little nifty feature.
• Cut and paste works as you expected, so does deleting a text selection. This is probably one of the single features users that are not used to Emacs are going to hate, even if it makes perfectly sense in the Emacs way of working.
• Last but not least, you can associate files with Emacs, so you can use it as a standard MacOS text editor to open files double clicking in the finder.

I'm really impressed by this project: in fact it's enought Emacs you want get too confused if you are used to Emacs, but it's also enought Mac you can use it along your other Mac applications, without having to rethink basic commands (if you don't want to).

Right at the moment it is in my opinion the best Emacs version for the MacOS out there.