Showing posts with label TextMate. Show all posts
Showing posts with label TextMate. Show all posts

Thursday, October 14, 2010

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.

Tuesday, October 5, 2010

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.

Sunday, August 15, 2010

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.

Tuesday, October 31, 2006

TextMate easter egg

Very nice Halloween icon...

Thursday, February 23, 2006

TextMate: the definitive editor?

Unfortunately it appears I've no time to talk about programming. It takes lot of time to think about something useful, to write examples and such. However, I promise I will doing it soon.

And yet I'm again talking about a text editor. In fact since most of my computer time is spent on an editor, this makes sense. It's the most crucial application to me (and the one I spend most time to learn using its full power).

I already said I discovered TextMate. The more I study the more I'm amazed. In fact it did substitute Aquamacs even for latex editing. The new bundle is perfectly integrated with Texniscope and "Command-B" opens in TextMate the pdf document compiled from the document I'm editing. That makes environment such that TexShop almost useless to me.

Emacs is more powerful. But most of the times I'm not using that power. It's my fault, of course. Still TextMate is always open on my Mac, and I started using it even for latex. That's the main reason. If I have to do a very long latex editing session I still do prefer Aquamacs.

The Python mode is now wonderful. It lets me check my sources with pychecker or with pyflakes. It allows me to run them from inside TextMate, lets me run unit-tests with one command. And even more. Right at the moment it's the best python programming environment I've ever met (a part from WingIDE).

The only thing I'm missing right now is a "prolog mode". And probably I have to work on TextMate/Xcode integration (it has been done, but I haven't done it yet). Oh, and I'm looking forward to see TextMate 2, that should have massive improvements on the "project management" side. And probably I'd like some more refined auto-completion with static languages. This could have somehow been added (TextMate can be extended and customized a lot, still in a really simple way), but I've not yet discovered if and how.

But the reason I wrote this is another. For years the "Text editors" with capital T have been Emacs and vim. BBEdit was a beautiful Mac editor, but first it is very web-oriented, second it is somehow less powerful in the way it deals with text.

On the windows platform I have not found really impressive text editors. There are a bunch that are powerful and easy to use. But in fact I installed vim (gvim) and I was happy with that. Most such editors were more concerned in "integrating" command line utilities (compilers, latex, interpreters) with the editor not to have the "programmer" opening the "DOS console" than pure text editing.

Newer editor for Linux (Kate for example) also paled in comparison with Emacs or vim. Now I'm wondering:

  1. Was I superficial? It is possible that no one did something that could be compared with vim or Emacs before TextMate? This seems really unlikely.
  2. Why haven't I spotted such editors? They exist? Let me know. I'm talking about "pure text editors", not about "IDEs".

TextMate 1.5 is out

New TextMate version is out. It is a big improvement over the last stable (I happen not to know which version number it had, since I've always been on the edge with betas -- and with no problems, update system is wonderful )

These are some of its new features (following list is copy & pasted from TextMate website)

You are supposed to go and it!

More informations here

TextMate

BBEdit, vim, Emacs
Until recently I thought BBEdit was the best possible editor for the MacOS. I probably was influenced by my previous experiences (I used BBEdit years ago, before I switched to *nix). In fact I was amazed how simple was to do complex queries (in fact it was easier than vim from a psychological point of view), and project wise or directory based queries are as easy to do as standard queries.
Moreover in that period I needed a tool with good HTML and site management capabilities (and BBEdit has them both, and in fact for HTML projects is in my opinion still the best tool out there) and it is fully scriptable (and files can be partially generated by scripts, which is good).
These qualities made me forget about other things I looked for in an editor. That is to say: I want to use an editor that lets me code faster, helping me in manipulating text. BBEdit has extensive facilities, but most of them are really not immediate.
Basic text handling is somewhat poor (for example indenting). It's best feature (glossaries) are not really useful for what I do most of the time. Still I liked it. It was better integrated with the mac os environment. This is the main reason because I did not use Emacs or vim: I am quite skilled in both of them, for I had to work on machines where one of them was not available. Mac ports exist, but are somehow less "native".
Vim does open a single window per application, and if you want to have more windows you need more applications, and that is not extremely practical.
If you are interested in an Emacs version that is MacOS friendly, read this.
The key question is: it is that important to behave like a Mac application? What does it mean being a "mac application"?
You'll be reading a more complete post on Mac philosophy on this blog later on. Right at the moment we can summarize: Apple philosophy is to keep things simple but not simplistic.
About the Apple UI there are lots of documents out there, but it's no mystery that nor vim nor Emacs follow Apple guidelines (and that makes perfectly sense, it's not a critic).
An application well integrated in its environment, works better. It's easier to use, you already know shortcuts, drag n drop behaves as you expect, integration with LauncherServices is present and so on. That is the reason I preferred BBEdit to vim or Emacs (now both Emacs and vim have some integration features, but do not have them all), even if I was skilled in both and they both have features BBEdit hasn't (and the features BBEdit has they haven't are not so important to me, in fact I found out my use of BBEdit is really basic: I'm a lot more into TextMate).
TextMate
When I tried TextMate for the first time, I thrashed it almost immediately. It missed CVS and SVN support (and BBEdit SVN support was wonderful -- unfortunately I'm not using SVN anymore). In fact I did not give it any chance. I had just bought BBEdit and was learning it's more complex features.
I wasn't ready for TextMate.
Text editing
Text editing is smooth. You can use all Cocoa standard shortcuts (that borrow heavily from Emacs) and Cocoa spell-checking is builtin. Fonts are smooth and beautifull.
TextMate does "smart typing", that is to say when you type a bracket or quotes, both the opening and the closing bracket or quote is typed and the cursor is placed inside. The first times I met with this feature (and it was with some IDE's) I hated it. Now I can't live without and I do a lot of mistakes when typing with something that does not support it. In fact I think it makes you save a lot of typing and a lot of time.
TextMate has other smart features, for example you can edit more than one line in a time (and the key are rectangular selections of any kind)
Folding is supported, that is to say you can look at the code with the level of granularity you chose. You can collapse blocks you are not interested and expand them when you are not interested.
Another useful feature is auto-completion: it's not as sophisticated as some C++ and Java IDEs since it's based on typed text rather than "possible code", but it has the advantage it applies to non-static languages too (Perl, Python, Ruby).
In fact TextMate can be used to code in C or C++, Java (even if it lacks some useful features that are necessary do to poor language design), Perl, Python, Ruby and a lot of other languages. Moreover it can be easily extended to other languages.
The most interesting thing is that you can define macros that put inserted text in more than one place. The most simple example is with HTML. Most HTML tags are kind of <tag></tag>. With TextMate you just say insert a "tag pair" (that is to say <p></p>, since p is one of the most used tags), and the editor will insert the text, selecting the first "p". Then you can type the correct tag (for example h3, or maybe table) and the closing tag will be updated accordingly. This makes a lot less typing: and can be used in clever ways for other languages too (think about latex environments).
The last (well not really) interesting feature is macro completions. You can easily define macros and type only a few characters, then tab complete. This is great.
The beautiful thing is that TextMate can be easily extended. There is a lot of support for many languages (unfortunately not for Prolog, and that is something I miss a lot, even not enough to write my own bundle).
Organize code
TextMate has some basic project managing. It can be further extended with TmCodeBrowser.
It's improving in this field. It can also import projects from Apple's XCode.
To be completely sincere to manage this website I prefer BBEdit (however most "text editing" and maintenance is made with TextEdit). I miss an FTP browser (I know this is controversial and the "current" solution is to have TM interact with FTP clients, I also do this, but sometimes it is just to good to directly edit).
And remember that TextMate + BBEdit do cost less than Dreamweaver (and produce better code -- of course this does not apply if you write code manually with DW, but then I think TextMate text editing facilities are just superior).