Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Making Emacs Stand Up To Visual Studio 7

By sludge in Op-Ed
Wed Apr 02, 2003 at 03:44:32 AM EST
Tags: Software (all tags)

Emacs users have reason to be jealous. The Visual Studio 7 IDE offers features that are seemingly unavailable in Emacs, and are certainly not 'on' by default. Admit it, it doesn't feel good to consider switching from Emacs to Visual Studio, and it certainly doesn't work well to have them both open at the same time.

What's not hopeful is the amount of help out there for aspiring Emacs users who are less than excited about using the Visual Studio 7 IDE, or feel themselves shamefully being wooed away from The One True Editor by the admittedly slick functionality of Visual Studio 7. The goal of this document is to pave the way for Emacs users to integrate with Visual Studio 7, something that is not covered in any depth elsewhere. I focus on Visual C++ (unmanaged), as this is what I spend all my time working with, though a C# programmer would probably see the majority of these tips as a good start.

I attack each issue that I consider important point-by-point. Keep in mind that these are my solutions, which means they're all in use by me, and that you may have a better idea. I'd love to hear it. I hope you find them a good start. It should also be mentioned that I use GNU Emacs 21.1.1 under Windows 2000 with the cygwin tools installed.

Hopefully reading on will fix one or more of your pet peeves with the one true editor, and keep you plugging away on Free Software as much as possible.

Syntax Highlighting

Although I do enjoy Emacs' font-lock mode, it does leave something to be desired after seeing the very fine-grained syntax highlighting of Visual Studio 7. In graphics heavy code such as the code I write, a lot of array lookups are done in tight loops. Visual Studio highlights operators, such as the '[' and ']' operators, which makes array heavy code much more readable. Emacs does not, by default.

Solution: Write new font-lock rules for c++-mode. I haven't included all of the syntax here, but this is what works for me without looking too fruity:

(font-lock-add-keywords 'c++-mode '(
;; Currently support for []|&!.+=-/%*,()<>{}
("\\(\\[\\|\\]\\|[|!\\.\\+\\=\\&]\\|-\\|\\/\\|\\%\\|\\*\\|,\\|(\\|)\\|>\\ |<\\|{\\|}\\)" 1 font-lock-operator-face ) <BR> ; End of c++ statement ("\\(;\\)" 1 font-lock-end-statement ) ))

Apologies to regex pros. I get the job done, but I'm not great. You will also want to define font-lock-operator-face and font-lock-end-statement:

(make-face 'font-lock-operator-face)
(make-face 'font-lock-end-statement)
(setq font-lock-operator-face 'font-lock-operator-face)
(setq font-lock-end-statement 'font-lock-end-statement)

There are multiple ways to assign a face. You will want to do it in a way that is similar to anything you already have customized.

Status compared to Visual Studio: Emacs is a perfectly acceptable alternative. If you turn off precaching of syntax highlighting, it's a bit slower to load a file. Jumping around a 60,000 line c++ source tree on my 1.2ghz Athlon is still easily within acceptable ranges.

"Go To Definition"

Visual Studio 7 lets you right click on a component of a statement (usually a function, variable or typedef) and go to it's definition. This handy feature lets you jump around a source tree in a snappy fashion. Emacs has a similar feature out of the box. You need to build a tags table, which is essentially a precached list of all of the definitions. Go to the root of your source tree, and type:

etags `find -iname "*.cpp"` `find -iname "*.h"`

This produces a file called 'TAGS' in the current working directory. Next, in Emacs, type M-x visit-tags-table and select the TAGS file.

In true Emacs fashion, the best way of navigating the tags is through the bindings. M-. will find a tag. M-* brings your cursor back to the place it was at before the most recent tag find. (Yes, this works recursively!) C-TAB completes the current keyword from the tags table database.

Status compared to Visual Studio: Not quite as smart or accurate as the Visual C++ tag finder. I find myself having to revert to M-x grep from time to time, or M-x occur (try it). On the bright side, there is no latency: the precaching in Emacs makes for one of those rare situations where Emacs is actually faster than Visual Studio in it's default state. I'm also a huge fan of the ability to push and pop my navigation points through the source tree. Mixed bag. I'd choose Emacs over Visual Studio if I had to take one implementation over the other, overall.


Getting Visual Studio 7 projects to compile through Emacs is one of the thorniest issues addressed here. If you used Visual C++ 6.0, you know that used to be able to export Makefiles. Well, in its infinite wisdom, Microsoft has removed this ability from Visual Studio 7. Instead, you must invoke the IDE from the command line and get it to build from the .sln file.

If you were to bring up a shell (with devenv.exe and .com in your $PATH), you could type "devenv.com foo.sln /build Debug /out output.log" and have it compile your project from the command line. Caveat - if you don't specify devenv.com, you get devenv.exe, which, for seemingly no good reason, sends it's output somewhere else than stdout, which ensures that you won't see it unless you're running cmd.exe. Always specify devenv.com when building from the command line.

In the simplest case of directory structures, all you need to do to compile a Visual Studio 7 project in Emacs is to set the default compile command:

(setq compile-command "devenv.com foo.sln /build Debug")

The usual C-` to step through the compiler errors works just fine with the compile buffer's output.

Honestly, I maintain a multi-directory project with some complications, so I call a perl script which actually goes ahead and calls devenv with the proper build configuration. I don't mind keeping that logic out of Emacs.

Compiling a Single File

One thing I hate about Visual Studio is what happens when I make a small change in a file, and the entire project's dependancies are checked before a single file is compiled. If you're like me, and you have a ton of dependancies in a big project, it can take upwards of around a minute to compile your single line change. Unfortunately, this minute can become two or three minutes if you muck your changes up and need to recompile. I'd rather compile the file by itself to make sure all of the changes are done and final before calling in the dependancy checker and the linker with the above step. In Visual Studio, I could hit ctrl-F7, but that's the grace an IDE gives you.

We can shell out and run Visual Studio's cl.exe (assuming it's in your path). But, with what arguments and environment? Good question.

You need to set the INCLUDE environment variable for the single file compilation environment. When loading my project, I run the following command:

(setenv "INCLUDE" "C:\\Program Files\\Microsoft Visual Studio .NET\\Vc7\\include;C:\\Program Files\\Microsoft Visual Studio .NET\\Vc7\\atlmfc\\include;C:\\Program Files\\Microsoft Visual Studio .NET\\Vc7\\PlatformSDK\\include\\prerelease;C:\\Program Files\\Microsoft Visual Studio .NET\\Vc7\\PlatformSDK\\include;C:\\Program Files\\Microsoft Visual Studio .NET\\FrameworkSDK\\include;")

Your mileage will vary. Don't copy this directly, but instead follow the directions above for aquiring your own INCLUDE environment variable set. Compile your project in Visual Studio, and check out the generated buildlog.htm. It will list off the environment the program was compiled in. Grab the contents of the INCLUDE line, and use it in Emacs, remembering to escape the slashes.

Next, we need to address the cl.exe syntax. We want to build the source file similar to the already-built obj files so it will drop in nicely when it's linked. Open the buildlog.htm back up. Near the bottom, there will be talk of options put into a temp file and then passed to cl.exe. We want these in emacs. Therefore, set this variable, which we'll use in a second. Mine looks similar to this:

(setq c++-compile-current-file "cl.exe /Od /D \"WIN32\" /D \"_DEBUG\" /D \"_WINDOWS\" /D \"_WIN32\" /D \"QUAKE3\" /FD /EHsc /MDd /YX\"stdafx.h\" /Fp\".\\Debug/foo.pch\" /Fo\".\\Debug/\" /Fd\".\\Debug/\" /FR\".\\Debug/\" /W3 /c /ZI ")

Given that we have defined c++-compile-current-file, the following LISP function compiles against it:

(defun c++-compile-current ()
(let ((compile-command
(concat c++-compile-current-file (buffer-file-name))))

It'd be cool if I had a Perl script to generate the required LISP based on the contents of a buildlog.htm. I haven't done that yet, though.

Status compared to Visual Studio: A bit of a bitch to get working, but once it works, you're there. Compiling a single file isn't recommended for small projects, as it's a bit of an effort to get working, but you wouldn't need the speed gains on a small project anyway. Considering Visual Studio does this out of the box, there is no contest as to which I'd prefer. But, let's face it, you're taking a chunk of logic usually reserved for IDEs, and making it execute through Emacs. Not bad, considering.

Starting the Debug Executable

After you build a binary, you're going to want to run it, right? I simply execute a shell script which sets up the current working directory properly, and runs the debug executable. Consider the following:

(defun shell-run-debug ()
(shell-command "sh rundebug.sh"))

You may also need to set the environment properly here.

Status compared to Visual Studio: Visual Studio 7 rearranges your windows, sometimes needlessly, when you enter debug mode. In this case, you are waiting for a crash before you are taken into the Visual Studio debugger. In practice, the executable starts up slightly faster. I am annoyed less, but ymmv. Both get the job done.

Class Browser

Visual Studio has the class/file/definition browser. Emacs has the speedbar. It's installed by default. Fire up a file in your project once you have your tags loaded (see above for tags tips), and type M-x speedbar.

I haven't had much experience with the speedbar, but it seems pretty usable so far. But then, I don't care for Visual Studio's class browser 90% of the time. I have it off.

Status compared to Visual Studio: The Visual Studio browser seems to be a bit more snappy. I don't appreciate having to double click a file to open it, or the flickery nature of the highlight in speedbar. This may be fixable - like I said, I'm not a big speedbar user in the first place. Speedbar gets points for it's use in all different languages. I still prefer Visual Studio's functionality here. Best interface in town.

Indentation and Code Style Compatibility

There is a small army of coders who dislike some aspect of then default indentation style in Emacs' C/C++ modes. I myself, have been hassled by respectable programmers for using it.

Braces cause a double indentation:~the braces are indented once, and then whatever is past the braces is indented again. This is not a bug, or an oversight - it is the GNU coding style at work. In addition, Visual Studio displays the tabs generated by Emacs by default incorrectly. If you are working with people who have not discovered The One True Editor, you will want to convert your tabs to spaces. In addition, I will throw in a line that shows how to reduce the number of spaces per tab stop in case your code project requires it, and a line that automatically places your cursor at the required indent level instead of the far left of your buffer where you will be needing to press TAB anyhow.

(setq-default tab-width 2) ; Tab width set to 2 spaces
(setq-default indent-tabs-mode nil) ; Indentation cannot insert tabs
(add-hook 'c++-mode-hook '(lambda () (local-set-key "\C-m" 'c-context-line-break)))
(add-hook 'c++-mode-hook '(lambda () (c-set-offset 'substatement-open '0)))

Status compared to Visual Studio: Emacs does precisely what I want here. I didn't even mention anything about electric braces or anything of that nature, since the object of this document is to help with the jealousy Emacs users feel against Visual Studio 7. Taking Emacs beyond Visual Studio 7's featureset is an exercise left to the reader.

Project-Centric Functionality

The concept of projects and solutions in Visual Studio is central to it's operation. Emacs is not an IDE, but it does play one on TV. I can make Emacs do enough to satisfy my requirements. There is a session management tool for Emacs out there, but I don't really need that. I take a more simple route, of setting a few states within Emacs whenever I approach working on a project. Observe the following code which opens a source file in one of the projects, fires up the speedbar, starts a tags table definition and sets up the environment for compiling a single file in the project:

(defun project-foo ()
(find-file "c:\\foo\\bar.cpp")
(find-file "c:\\foo\\bar.h")
(visit-tags-table "c:\\foo\\TAGS")
(setq compile-command "perl compile.pl")
(setq c++-compile-current-file "cl.exe /Od ")
(setenv "INCLUDE" "c:\\foo\\bar\\include;")


Status compared to Visual Studio: Emacs does what I want it to. Visual Studio wins because it's an IDE that works for a single compiler, and there is a ton of raw functionality behind the idea of projects and solutions.


By default in Emacs, when you scroll, you are given what amounts to half a page down when your cursor reaches the end of the screen. If you prefer the smooth scrolling of Visual Studio, you can get it:

(setq scroll-step 1)
(setq scroll-conservatively 50)

Sadly, in Emacs, your cursor always has to be in the screen, to my knowledge. In Visual Studio, you can mouse wheel scroll away from the current editing position, and when you get back to it, your cursor will be where you left it. Emacs waits until your cursor is at the edge of the screen, then it reluctantly drags it along. You are given a choice, however. The following line will make the cursor start scrolling right away:

(setq scroll-preserve-screen-position nil)

Status compared to Visual Studio: Overall, I like the scrolling features in Emacs more, despite the gripe I have above. I like the idea of scroll-margin which allows me to "look before I leap".

What I Haven't Touched On

Visual Studio 7 still excels over Emacs in a number of ways I haven't touched on here. One of the biggest issues in the list is debugging. The idea of stepping through the code, making changes and linking into the running code (a feature that has been there since Visual Studio 6) is something that is best done from the IDE.

Visual Studio also has the Intellisense feature. I am told that this feature can be compared to the functionality of the speedbar, coupled with Emacs packages EIEIO and the Semantic Bovinator. I am okay with the way things are currently, but will definitely be checking these packages out once I become familiar with my current working environment. You can click here to jump ahead of me and learn how this works for yourself, already.

MSDN help. The ability to jump around the MSDN help is better in Visual Studio. I don't use MSDN help in my day to day life. I would be interested to hear what others are doing.

"Reverse" integration, because it's not out there (yet?). There is a plugin for Visual Studio that lets you use Emacs in lieu of the in-IDE editor. You click on a file in the IDE, and Emacs pops up instead of the Visual Studio 6 editor. Here is a link to VisEmacs. It's got nothing to do with Visual Studio 7. The last release was in 2000. And yes, I have tried to see if I could get it to work, and I fell short of success.

Visual Source Safe. I use CVS.

Additional reading based on editorial comments posted to this article:


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o out there
o here
o Here
o EBrowse
o Alternativ e method of completing variables
o Also by sludge

Display: Sort:
Making Emacs Stand Up To Visual Studio 7 | 115 comments (98 topical, 17 editorial, 0 hidden)
Great article (1.00 / 1) (#3)
by A Proud American on Tue Apr 01, 2003 at 09:34:03 PM EST

Would it possibly be even simpler to just customize Visual Studio .NET to support whatever keystrokes you use in Emacs?

The weak are killed and eaten...

Yup (none / 0) (#4)
by sludge on Tue Apr 01, 2003 at 09:42:43 PM EST

Probably would be simpler. But, it's not as extensible or portable as Emacs, and that'll never change. I hear the macro system is quite nice, though.
Hiring in the Vancouver, British Columbia area
[ Parent ]
Well, probably nope... (none / 0) (#87)
by ucblockhead on Wed Apr 02, 2003 at 03:54:06 PM EST

With Visual Studio.NET, Microsoft removed some of their old keybinding support, to the extent that it no longer can emulate the old DOS "Brief" editor. (A pity, because that was a damn fine editor.) It also could never emulate vi. I have no idea whether it could do Emacs, but I suspect not. The editor is lacking some key features. (The ability to yank columns is one annoying one.)
This is k5. We're all tools - duxup
[ Parent ]
Completely offtopic, but regarding that sig... (4.00 / 4) (#73)
by Merc on Wed Apr 02, 2003 at 12:24:17 PM EST

If war ended fascism, what kind of government runs Iraq? If that isn't a fascist government, then the definition really is a little too narrow.

If war ended communism, why is it that the biggest country on the planet is officially communist? What wars were fought against communism anyhow? The only two I can think of are the Korean war and Vietnam. North Korea is still a communist state, as is Vietnam. It looks like those wars did not end communism. The only place communism was ended was in the USSR, and that's the one place where war wasn't fought.

Now I'll give you that war ended nazism as a political system, but really that was just the end of a certain government, and war has overthrown plenty of governments.

Finally, slavery. While the US civil war did put the final nail in the coffin for slavery in the US, most of the rest of the world had already stopped slavery without resorting to war. Saying the civil war was the deciding factor in ending the practice of slavery is a little narrowminded.

[ Parent ]
Indeed... (none / 0) (#107)
by bigchris on Thu Apr 03, 2003 at 08:31:01 AM EST

All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?

I Hate Jesus: -1: Bible thumper
kpaul: YAAT. YHL. HAND. btw, YAHWEH wins ;) [mt]
[ Parent ]
really? (none / 0) (#110)
by han on Fri Apr 04, 2003 at 03:49:21 AM EST

I haven't used Visual Studio except briefly a year or two back, but as far as I know it has only a fraction of the text-editing functions of emacs. Thus it wouldn't make much sense to try and rebind its keystrokes. Or am I mistaken?

[ Parent ]
two comments (4.66 / 3) (#11)
by Delirium on Tue Apr 01, 2003 at 10:11:59 PM EST

  1. If all you dislike about the GNU coding style is the halfway-indented braces, then your solution fixes that just fine. However, you can also just switch to one of the many other built in C/C++ indentation styles. M-x c-set-style (you can set it to default to one in your .emacs if you'd like as well). The available ones by default are bsd, ellemtel, gnu, java, k&r, linux, python, stroustrup, and whitesmith.
  2. Other than the lack of a class browser (which you've addressed here), the other thing I miss about Visual Studio when using Emacs is semantic-sensitive prompting and autocompletion. In Visual Studio, if you type sqrt( a popup comes up listing the parameters it takes (if the function's overloaded, up/down arrow scrolls through them). Avoids having to lookup library functions in manpages or the order of arguments in member functions. In addition, it autocompletes class members; if you type blah-> and blah is of type SomeClass*, it'll show you the members of SomeClass, and if you type the first few chars (enough to disambiguate) you can then autocomplete with spacebar. Emacs has neither of these features, and as far as I know, there is no way for the end user to easily emulate them, as it'd require Emacs to parse C grammar enough to know the members of all classes (in real-time, no less -- when you add a new member, it shows up in the autocomplete list instantly) and furthermore the types of all identifiers.
In any case, I mainly use emacs, but feature #2 would really be nice.

Since the time you posted this (5.00 / 1) (#17)
by sludge on Tue Apr 01, 2003 at 10:54:36 PM EST

I have added the following link to the article. It's not a perfect answer, but it may shed some light on the issue for you.

[ Parent ]

on semantic (none / 0) (#29)
by martingale on Wed Apr 02, 2003 at 12:40:33 AM EST

I remember trying the intellisense stuff about six months ago, and it wasn't quite useable then (haven't tested since, so it might have evolved quite a bit for the better). Creating the semantic database took ages and had a big impact on cursor navigation IIRC. So I just use hippie-expand now with selected completion functions.

Pity your article is already in voting, because you could have mentioned ECB. I really hate having the speedbar in a separate frame, but ECB imbeds it in a window instead.

[ Parent ]

code browser and completion (none / 0) (#52)
by bloat on Wed Apr 02, 2003 at 08:16:36 AM EST

I use the excellent Xrefactory for all my Java source browsing needs. Don't think it works for C++ though.

So good I even paid for it!

There are no PanAsian supermarkets down in Hell, so you can't buy Golden Boy peanuts there.
[ Parent ]
Elisp -- The biggest problem with emacs (4.85 / 7) (#12)
by GGardner on Tue Apr 01, 2003 at 10:20:52 PM EST

The biggest problem with emacs today is elisp. No, not because it is a lisp variant, but because elisp isn't a good enough lisp. The primary problem with Elisp is that it is dynamically-scoped. Although there are ways to get around this, substantially all the emacs-lisp code uses dynamically scoped variables.

Why is dynamic scope bad? It is bad not just because it is slow in the current emacs interpreter implementation, it also means that JIT compiling elisp down to native code (as many other lisp implementations do) can't buy you a big speedup. This is because most variable references can't be easily assigned to machine registers, like a lexically scoped language, but you need to call out to a function every time you want to look up a variable.

A lexically scoped elisp with a decent JIT compiler would supercharge emacs. For example, emacs calc program is just about the best online calculator on the planet. Unfortantely, because it is executed on slow elisp, it falls down for big calculations. A jit-compiled calc.el would win huge.

A jit-compiled elisp would speed up all kinds of day-to-day activities and enable developer tools to be built which blow away Visual Studio.

Unfortaneatly, due to the huge amount of legacy .el code which depends on elisp, this sort of change will probably never happen. And that's a huge pity -- if emacs had a fast extension language, netscape could have been written in emacs, and that would have been an amazing program.

Dyanmic Scoping error prone too (none / 0) (#13)
by HidingMyName on Tue Apr 01, 2003 at 10:33:42 PM EST

I find it hard to debug software in a dynamic scope environment, and I suspect many others find that difficult too.

[ Parent ]
It makes code reuse hard, too (none / 0) (#27)
by GGardner on Wed Apr 02, 2003 at 12:24:53 AM EST

I tried to reuse some code in the emacs calendar once, but it was well-nigh impossible. The code depended on dynamic scope -- some functions I wanted to call depended on a bunch of variables being predefined in an outer scope. These weren't documented, so you just had to hack away until you got them all defined. Of course, if the code took a path you weren't expecting, you might need to repeat the process.

I believe that most every computer language designer today understands dynamic scope to be wrong. I can't think of any modern language that uses dynamic scope.

[ Parent ]

two comments in one: Python and Emacs (none / 0) (#102)
by jovlinger on Wed Apr 02, 2003 at 11:14:30 PM EST

Python's scoping rules are sufficently arcane that you can attribute them to any number of styles.

Lack of nested scopes helps avoid the nasty edge cases, but I think you can argue that globals in python have dynamic scope, but AFAIK, limited to the module the procedure was defined in...

yuck! I hate that language. If it weren't so damn productive, I'd never write another python program again.


As for elisp being hard to grok, try adding after advice to the mix. I tried to understand how mime mode for MH-E worked, and was tearing out my hair until I invoked the debugger and found that mime mode was side-effecting the definitions in MH mode. ARGH! who would do such a thing!?

incidentally, I research aspect-oriented programming, which is basically the same thing. Funny old world

[ Parent ]

the reason (4.00 / 1) (#38)
by kubalaa on Wed Apr 02, 2003 at 02:35:07 AM EST

it's the same reason global variables are bad -- it introduces "hidden" parameters to functions.

[ Parent ]
the other bad thing about dynamic scoping (none / 0) (#14)
by Delirium on Tue Apr 01, 2003 at 10:36:49 PM EST

It's completely counter-intuitive, and leads to all sorts of weird bugs. RMS is one of the few people who's tried to argue it's a good thing, pointing out some example of temporarily rebinding keystrokes, where dynamic scoping means they're rebound in all subsequent function calls, but automatically unbound after the current function ends. That's not a very convincing example imo.

It's also rumored that the first version of Lisp was dynamically scoped by accident; if you've programmed a simple interpreter in an undergraduate class, a dynamically scoped one is fairly easy to come up with by accident (the creator of Lisp claims he did it on purpose though).

[ Parent ]

Fluids (none / 0) (#70)
by unknownlamer on Wed Apr 02, 2003 at 10:56:04 AM EST

It's completely counter-intuitive, and leads to all sorts of weird bugs. RMS is one of the few people who's tried to argue it's a good thing, pointing out some example of temporarily rebinding keystrokes, where dynamic scoping means they're rebound in all subsequent function calls, but automatically unbound after the current function ends. That's not a very convincing example imo.

Fluid variables (i.e. dynamically scoped variables) can be used in a statically scoped language to do everything a dynamically scoped language can, but in a more generally safe manner. In Guile you create a fluid with make-fluid and reference its value with fluid-ref (making the usage of a dynamically scoped variable explicit). When Emacs is ported to Guile, all varaibles from Elisp will be fluids...dynamic scoping does have its uses (e.g. temporaribly rebinding keystrokes) so you don't want to eliminate the ability to use dynamically scoped variables entirely. So the example RMS gave is a good one supporting dynamically scoped variables, just not an entirely dynamically scoped language.

<vladl> I am reading the making of the atomic bong - modern science
[ Parent ]
Interestingly ... (none / 0) (#83)
by Simon Kinahan on Wed Apr 02, 2003 at 03:00:45 PM EST

... Smalltalk went through a similar evolution. Modern Smalltalk environments treat blocks as closures, whereas in older ones they were dynamically scoped, which produced many wierd and unpredictable effects.

I always suspected the original Smalltalk VM was that way just because it was easier to implement, as it was not even clearly documented in the books describing the system.


If you disagree, post, don't moderate
[ Parent ]

Eventually Going to be Changed (5.00 / 1) (#15)
by unknownlamer on Tue Apr 01, 2003 at 10:40:19 PM EST

Guile will eventually (give it a few years; maybe emacs 23 or 24) replace the native Elisp stuff. All this means is that the guts of emacs will be reimplemented to use Guile Scheme and the existing Elisp stuff will be implemented on top of Guile so you will be able to use Guile and Elisp. That is one of the goals of the Guile project (to support the translation of different languages into Scheme). There is a semi-working version of Emacs 20 implemented on top of Guile named gemacs.

Right now Guile is slower than Elisp, but in the current CVS tree the macro-expander has been separated from the compiler so it is much easier to support different compilation methods. The GC was also mostly re-written giving a large speed boost (that was entirely destroyed by the separated macro-expansion/memoizer/compilation phases). I am planning to try and port Guile to Parrot once Parrot becomes useable enough (and I have free time, working 38 hours a week at a sub shop and going to school for 36 hours a week is not fun).

<vladl> I am reading the making of the atomic bong - modern science
[ Parent ]
Is RMS on board with this? (none / 0) (#26)
by GGardner on Wed Apr 02, 2003 at 12:20:25 AM EST

Are the emacs maintainers planning to switch from elisp to guile, or is this just the guile folks' master plan?

[ Parent ]
He mentioned this (none / 0) (#43)
by obsidian head on Wed Apr 02, 2003 at 03:26:26 AM EST

I recall on c.l.lisp, someone questioned him why the Emacs maintainers were moving to Scheme (Guile) instead of Common Lisp.  His answer:  Common Lisp is huge!

[ Parent ]
Common Lisp (none / 0) (#65)
by OneEyedApe on Wed Apr 02, 2003 at 10:01:05 AM EST

They could do what Maxima did: use gcl, clisp, or cmucl as a common lisp backend.

[ Parent ]
Common Lisp not huge nowadays (none / 0) (#68)
by GGardner on Wed Apr 02, 2003 at 10:24:26 AM EST

Common Lisp started the modern movement that Java, C# and perl have continued -- have a relatively small core language, and a large library that supports it. Common Lisp may have been huge in the VAX 11/780 days, but it really isn't that big now. The standard libraries are no bigger than the modules that perl ships with, and much smaller than the set of perc modules from CPAN which usually get installed on my machine.

Now, CL is getting a little old in the tooth, and language design (even lisp language design) has progressed in the years since the standard came out. Maybe Paul Graham's ARC will be a better implementation?

[ Parent ]

CL (none / 0) (#76)
by OneEyedApe on Wed Apr 02, 2003 at 12:51:14 PM EST

I agree that CL might not be that popularand a bit old, but it does have some features that make it well suited for some tasks. And CMUCL can incorporate C object files and libraries, in addition to a built in interface to X11. I figure use what will get the job done best, not what's most popular.

And ARC looks interesting. Thanks for pointing it out.

[ Parent ]
Greenspun's Tenth Rule (none / 0) (#77)
by OneEyedApe on Wed Apr 02, 2003 at 12:56:08 PM EST

As a side note, something I found on Mr. Graham's website:

"Greenspun's Tenth Rule of Programming: any
sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp."

- Phil Greenspun

"Including Common Lisp."

- Robert Morris

[ Parent ]
It is the Emacs Plan (none / 0) (#69)
by unknownlamer on Wed Apr 02, 2003 at 10:48:23 AM EST

Guile was started to be the extension language used by all GNU programs (that make sense to be extended). Guile means GNU Ubiqitous Intelligent Language for Extension after all. The official GNU stance is that all new programs should use Guile for an extension language or no extension language at all and old programs should eventually ditch their own extension languages and use Guile. This isn't so bad really; it is fairly easy to implement most scripting languages on top of libguile (GNU Octave was/[is?] doing this). Guile is reasonably mature but still lacks speed. Once the speed is there Emacs should be rewritten to use Guile instead of Elisp. So, yes, the Emacs team is on board with the Elisp->Guile conversion, but it won't happen for a few years.

<vladl> I am reading the making of the atomic bong - modern science
[ Parent ]
Scheme a bad choice for emacs extension language (none / 0) (#78)
by GGardner on Wed Apr 02, 2003 at 01:15:50 PM EST

Scheme is a bad choice for an extension language, because it is very difficult to generate good code for it. The next emacs extension language should be JIT compiled, and fast enough that there is no reason to go down to C. I want fast regexps, fast syntax-higlighting, and the ability to build real programs in emacs. For example, I'd love to have Macsyma (or a clone) within emacs. This requires a jit-compiled lisp extension language.

Just one example why this will be hard to do: You say that you'd like to compile guile to parrot bytecode. How are you going to implement call/cc in parrot?

[ Parent ]

What? (none / 0) (#94)
by unknownlamer on Wed Apr 02, 2003 at 06:04:36 PM EST

Just one example why this will be hard to do: You say that you'd like to compile guile to parrot bytecode. How are you going to implement call/cc in parrot?

I doubt it will be difficult seeing how parrot has support for full fledged continuations. Just few bytecode instructions to create and use the continuation. I don't see how Guile Scheme couldn't be quickly and efficiently compiled. There is really nothing keeping it from being compiled into native code other than the usual stuff for Lisps. Bigloo seems to have been able to write a fast compiler for Scheme.

<vladl> I am reading the making of the atomic bong - modern science
[ Parent ]
scheme hard to compile? (none / 0) (#101)
by jovlinger on Wed Apr 02, 2003 at 10:59:28 PM EST

Scheme is a bad choice for an extension language, because it is very difficult to generate good code for it.
This sounds like one of those truisms that everyone knows is true, but few people ever verify. Could you perhaps back it up with some details?

Only patholgical scheme programs are anything but largely first order, and few programs use continuations (for a change, a complicated language feature helps the compiler...). Hence they compile very nicely, thank you.

Of course, the necessary runtime checks will cost you some, so you won't be competing with straightline C code, but I would be suprised if even naively compiled scheme wouldn't run circles around byte-compiled elisp code. Most scheme programs are very ammenable to analysis and program transformations, allowing a clever compiler to do a lot of fun optimisations.

Remember that regardless of the speed of the extension language, the heavy lifting will be done by hand tuned primitives for regexps and text munging, so all the extension language has to do is be fast enough to not get in the way. Which elisp largely is... apart from not being multithreaded, which is a REAL downer: scanning a 7000 msg inbox with mh locks up emacs for upto a minute.

[ Parent ]

Why not use C ? (none / 0) (#112)
by mickey mouse on Fri Apr 04, 2003 at 09:55:40 AM EST

Why not use C instead instead of an archaic language  like elisp or even the newer variant guile/scheme ? It is more commonly known to even non software engineers and should be lightening fast. Admittedly C does not have very good support for regexp but I am sure, there must be some extension which does it.

I love (X)emacs and use it for almost all my work, but since I am not very good at elisp, I spend a huge amount of time to customize something to my taste. What I say here may not make absolutely any sense, but then I am not a software engineer.


[ Parent ]

Other option (none / 0) (#18)
by Anonymous 242 on Tue Apr 01, 2003 at 11:06:22 PM EST

Use Sun's Workshop Pro. It has XEmacs embedded into the product.

I abstain because (2.50 / 6) (#19)
by exile1974 on Tue Apr 01, 2003 at 11:10:54 PM EST

I hate emacintoss and visual stupid. I am a vi kinda guy. Somebody else kill this puppy as I am biased.

"A sucking chest wound is Nature's way of telling you to stay out of a firefight." --Mary Gentle

Preach it, brother! [nt] (5.00 / 1) (#55)
by bakuretsu on Wed Apr 02, 2003 at 08:35:21 AM EST

-- Airborne
    aka Bakuretsu
    The Bailiwick -- DESIGNHUB 2004
[ Parent ]
+1: Funny (4.50 / 2) (#22)
by jabber on Tue Apr 01, 2003 at 11:39:57 PM EST

but this is what works for me without looking too fruity:

(font-lock-add-keywords 'c++-mode '(
;; Currently support for []|&!.+-%,()<>{}
\&]\|-\|\\|\%\|\\|,\|(\|)\|>\ |<\|{\|}\)" 1 font-lock-operator-face )
; End of c++ statement ("\(;\)" 1 font-lock-end-statement ) ))

That statement alone brought appropriate closure to my otherwise unremarkable 4/1. Vote to section.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Notepad.EXE (3.50 / 10) (#23)
by Armada on Tue Apr 01, 2003 at 11:42:09 PM EST

I found this nifty little utility the other day. It's like a GUI interface to EDIT.COM. For those of us that have been big fans of EDIT, I'd have to say that this is a pretty big step up. I've been impressed so far and would recommend it to anyone that has to do any serious coding.

TextPad (none / 0) (#45)
by Kruador on Wed Apr 02, 2003 at 04:45:23 AM EST

I'll admit to not using Emacs at work, or indeed at home. I never could get my head round C-M-S-x etc. I used it for a while on Solaris when at university but only until I learned how to use vi/vim.

However, we've found a pretty good alternate editor - for when you don't need the weight of Visual C++ - in TextPad [http://www.textpad.com]. It has syntax colouring (which can be configured via syntax files, for which many are available).

I'll note here that currently all my development is on Windows, and mostly for Windows or Windows CE (with a little DOS thrown in now and again). Most is in C++ using VC++ 6.0 or Embedded Visual C++ 3.0 (for CE), or Visual C++ 1.52 for DOS development. TextPad is a much better editor than VC 1.52.

By default, TextPad has its own keymap, but if you're used to VC++'s keys, you can use those by going to Configure > Preferences > Editor category and changing Keystroke Compatibility to Microsoft Applications.

I haven't used the VS7 IDE much yet, and only for VB7 code. However, it's a dramatic improvement over VB6.

I'll tend to edit the code I'm working on mostly in the IDE (unless it's VC 1.52, in which case I use TextPad) but read code from other projects in TextPad.


[ Parent ]

Seconded (none / 0) (#71)
by Jman1 on Wed Apr 02, 2003 at 11:29:58 AM EST

I do most of my coding now in TextPad. Nice and lightweight, good syntax coloring and pretty much everything else I'd want except for a debugger, compiler, and that sort of thing. So, great for coding, not so great maybe for hard-core development.

[ Parent ]
A similiar tool (none / 0) (#90)
by X3nocide on Wed Apr 02, 2003 at 04:15:17 PM EST

Goes by the name of Programmer's File Editor. Works pretty nicely but not nessecarily an IDE. But it does have an output capture function, for those using windows without a piping system.

[ Parent ]
I am happy with Emacs as it is (2.80 / 5) (#24)
by tftp on Tue Apr 01, 2003 at 11:43:45 PM EST

Emacs works fine for me, and I need no changes whatsoever, besides my personal .emacs file with some fonts, colors and couple of hot key assignments.

The editor's importance is probably 0.032%, and the code itself - structure, classes, algorithms, semaphores etc. - is the remaining 99.968% ...

Also, I do not use VC++ IDE even when I have to compile stuff on Windows. It generates a whole lot of gibberish files (including the makefile, in MSVC6) which is also mostly junk.) I use qmake (and Qt). Highly recommend. Emacs and make/qmake are the only tools I need. Qmake is free, IIRC - use it.

Related Emacs tips (4.66 / 3) (#30)
by cooldev on Wed Apr 02, 2003 at 12:43:27 AM EST

0) I sent this guy (VisEmacs) the source for a *very ugly* hack that allows you to run emacs as an editor in VS.NET in a ToolWindow. It wasn't pretty, but it worked and even had minimal integration with class browser, etc. (also a hack). You can't use it as the debugger. If you want this I can be persuaded to dig it up; he doesn't seem to be doing anything with it. (It would need some work if you wanted to really use it.)

1) Instead of jumping through hoops with devenv, projects, cl.exe, and perl, just compile through makefiles. It's not that hard to build them yourself. If you have a project that spans multiple directories, setup a proper hierarchical makefile system and try something like this to compile from just the current or selected directory:

(defun nmake (BUILDDIR)
  (interactive "Dnmake from Directory: ")
  (compile "nmake")
  (if (buffer-file-name)
      (cd (file-name-directory (buffer-file-name)))))

2) For the kind of searching I do in code I've been happier with NT's findstr than grep:

(setq grep-program "findstr")
(setq grep-find-command "/N /I /S ")

3) Short fragment that I use for project managment. Allows me to list a set of dirs I work in frequently so I can find and open those files easily:

(setq proj-dirs '("."

(defun proj-flatten-list (lst nxt)
  (let (a d l)
    (setq l lst)
    (while lst
      (setq a (car lst) d (cdr lst))
      (cond ((consp a)
             (proj-flatten-list a (or d nxt))
             (setcar lst (car a))
             (setcdr lst (cdr a)))
            ((null d)
             (setcdr lst nxt)))
      (setq lst d))

(defun proj-directory-files (dir)
  (directory-files dir nil "[^.].*"))

(defun proj-build-file-list ()
  (mapcar 'list (proj-flatten-list (mapcar 'proj-directory-files proj-dirs) nil)))

(defun proj-open (filename)
  (if filename
      (let ((dirs proj-dirs))
        (while dirs
          (if (file-exists-p (concat (car dirs) "/" filename))
             &n bsp;  (find-file (concat (car dirs) "/" filename))
             &n bsp;  (setq dirs nil)))
          (setq dirs (cdr dirs))))))

(defun proj-find-file ()
  "Kind of like find-file but completes all filenames in proj-dirs"
  (proj-open (completing-read "Project find file: " (proj-build-file-list))))

I think I could go on and on.. That's all for now.

Disclaimers: No GPL code was knowingly viewed or harmed in the making of all of my hacks. Also, don't laugh at my elisp. I usually just bang it out until it works and then append it to my massive .emacs file never to be seen or refined again. ;-)

M-x gid (none / 0) (#32)
by martingale on Wed Apr 02, 2003 at 12:57:56 AM EST

There's a much better tool than grep if you're just looking for identifiers scattered in your source files. I use the GNU id-utils package, which comes with a nice id-utils.el interface. It works on the same principle as etags. In the directory where your source files reside, just type mkid to build the database. What I do is regenerate the database as part of the Makefile, so it's always up to date.

Then, you can place your cursor on an identifier in your code and type M-x gid RET, which opens a window with all the source lines which use that identifier. It's great when refactoring.

[ Parent ]

Yeah (none / 0) (#35)
by cooldev on Wed Apr 02, 2003 at 01:49:25 AM EST

Any symbol/identifier searching (etags, this, etc.) is a godsend and should be one of the first things toget working in any editor environment. I rely on a non-redistributable tool to do this, which is why I didn't post the elisp I used to integrate it.

[ Parent ]
Proper Hierarchical Makefile not proper at all (none / 0) (#33)
by GGardner on Wed Apr 02, 2003 at 01:12:39 AM EST

See Recursive Make considered harmful

[ Parent ]
Well (none / 0) (#34)
by cooldev on Wed Apr 02, 2003 at 01:35:53 AM EST

Whatever. The snippets I posted are what I find useful for projects broken out in a hierarchical fashion. Sometimes you want to build the world, but more often you want to build just the current directory and subdirectores. Sometimes you want to build in a directory one up or one down from the file you're looking at - this is a super easy way to do that.

Whether it's laid out in an inefficient fashion like the article critized is up to you, but any big projects will have subdirs/subprojects. A slight derivative of what I posted works well for me in practice when I'm compiling within emacs, and I work on a pretty big project.

[ Parent ]
One other suggestion (4.50 / 2) (#36)
by cooldev on Wed Apr 02, 2003 at 01:53:20 AM EST

Sort of off topic, but if you're using emacs on Windows and you have an emacs or unix background you've gotta try eshell.

Delphi (5.00 / 1) (#39)
by alfadir on Wed Apr 02, 2003 at 03:04:38 AM EST

Emacs is not an IDE, but it does play one on TV.

I agree with the quirks that Emacs have, but I have not used it under Windows, and therefor not made any GUI programs, with it. Emacs is good for normal linux projects. The big problem is that you have to become a .emacs programmer before you can start coding. dotfiles.org might help.

It has been a while, but I have used Delphi, C++ Builder and VC++. Delphi and C++ Builder was much better IDEs than VC++.

They have the debug, compile environment that VC++ has since they are built as IDEs, not just got shoehorned into a IDE on TV.

You could select between several syntax highlighting schemes or define your own. Very easy. I used Twilight IIRC.

What I liked about Delphi back then was the autofilling of arguments to routines you were calling. Object.method(argument1, argument2) each part with a kind of tabcompleation. Often you know what you want to do, but you don't want to start the help to get the exact definition, order of arguments etc.

The latest Delhpi I used was version 3 so the IDE may have improved or gotten worse since then. It blew VC++ (version 6 IIRC) out of the water back then though. It would be interesting to see a Delphi/VStudio comparison by someone who uses the IDEs actively.

Visual Assist (none / 0) (#84)
by sien on Wed Apr 02, 2003 at 03:06:04 PM EST

Visual Assist does the autofilling of arguments for Visual Studio.

[ Parent ]
I have but one comment (3.83 / 6) (#41)
by fink on Wed Apr 02, 2003 at 03:12:27 AM EST

and I say this in fear of invoking the wrath of Stick or Joh3n:
Thankyou for your attention. I'll now climb back into my crater where I belong, and wait for the modding to begin...


oh, and... (5.00 / 1) (#42)
by fink on Wed Apr 02, 2003 at 03:14:45 AM EST

+1, Section, by the way. Great article; finally something that doesn't mention Ir*q or other common themes here.

[ Parent ]

vim (5.00 / 1) (#62)
by OneEyedApe on Wed Apr 02, 2003 at 09:48:26 AM EST

I happen to like vim too. But I also use GNU Emacs. Different editors for different projects. What's so wrong with that?

[ Parent ]
Nothing. (none / 0) (#85)
by fink on Wed Apr 02, 2003 at 03:33:26 PM EST


(there's a running "war" between joh3n and myself (and joh3n and stick) with regards to the usefulness of various editors. for the purpose of this argument, and to make it believable, I've stuck to vim. IRL, I use vim, jEdit, or whatever's available)

[ Parent ]

Eclipse (5.00 / 2) (#44)
by ComradeFork on Wed Apr 02, 2003 at 04:29:11 AM EST

I'd just like to add that Eclipse is also a wonderful IDE for programming in Java. People who haven't used Java and Eclipse often will pick on it, but its really quite good.

Lets hope someone writes a good IDE for Python, Lua, or Scheme...

Yes ... (3.00 / 2) (#47)
by Simon Kinahan on Wed Apr 02, 2003 at 05:36:12 AM EST

... but IntelliJ IDEA is better, if more (infinitely times more) expensive.


If you disagree, post, don't moderate
[ Parent ]
IntelliJ (none / 0) (#48)
by ComradeFork on Wed Apr 02, 2003 at 05:46:48 AM EST

Thanks for the tip! However I am a poor student. What advantages does it have over eclipse?

[ Parent ]
Here are a few (none / 0) (#51)
by Simon Kinahan on Wed Apr 02, 2003 at 07:57:30 AM EST

1. More refactorings, and more flexibility about how they're deployed.
2. Very nicely polished UI. Its Swing rather than SWT, but not slow on a modern machine. I find Eclipse's UI a bit clunky to use.
3.Its completely operable from the keyboard, and the keyboard focus is always in the right place, which I've found not to be true of Eclipse.
4. Transparent saving, with a local version control system to avoid clobbering stuff.
5. The syntax/semantic checking is vastly better. Eclipse's makes all kinds of goofy errors.

Download the eval and try it. The elegance of the user interface is hard to convey in words.


If you disagree, post, don't moderate
[ Parent ]

Maybe Eclipse is worth a second look? (5.00 / 1) (#58)
by DDS3 on Wed Apr 02, 2003 at 09:14:27 AM EST

First, let me say I'm NOT a Java developer, however, I did recently read an article about the latest Eclipse release. From what I read, most of your comments have been addressed. Speed is supposed to be somewhat improved, refactoring is supposed to be significantly better, syntax checking is supposed to be more accurate and faster, etc, etc, etc... Again, not really being in tune with your comments, I can't argue the merit of yours or the latest Eclipse release. Having said that, in the same review I did see several comments stating that Eclipse is finally nipping at the toes of your preferred solution. Perhaps Eclipse is worth a second look? Long story short, if it really is only a couple of minor notches down from your ideal, for the money it's certainly going to be hard to beat.

[ Parent ]
I'm using Eclipse in my present job (none / 0) (#66)
by Simon Kinahan on Wed Apr 02, 2003 at 10:03:42 AM EST

Although it is not the latest version. Currently in startup mode == no money. I'll upgrade when I get back to Java, since I'm working on C++ at present.


If you disagree, post, don't moderate
[ Parent ]
Thought you might want the link (5.00 / 1) (#75)
by DDS3 on Wed Apr 02, 2003 at 12:46:44 PM EST

New in 2.1 Release of Eclipse. Since I had the link handy, I thought I might share it.

I would be curious to hear what your take is on the various improvements and changes. Please, share.

[ Parent ]
Looks good (5.00 / 1) (#82)
by Simon Kinahan on Wed Apr 02, 2003 at 02:06:53 PM EST

The refactoring support looks to have passed where IDEA was last time I used it, with the addition of "Move Instance Method" (yeah ! at last !).

Some of the editor changes look good. Obviously heavily IntelliJ influenced, which is good. I'm still worried about the syntax checking, which seemed not to notice changes in other files last time I used it, and isn't mentioned.


If you disagree, post, don't moderate
[ Parent ]

Speed (none / 0) (#100)
by Siddhi on Wed Apr 02, 2003 at 10:57:35 PM EST

The last time I used eclipse, it was crawling on my computer. Granted, I ran it on an old machine (800 mhz), but it was completely unusable. 2 seconds to open a menu !

I hope they have speeded it up appreciably, or else its back to vim :)

[ Parent ]

IntelliJ - the one true IDE (none / 0) (#103)
by swagr on Wed Apr 02, 2003 at 11:24:57 PM EST

Out of every development tool I have ever tried (including Microsoft tools to vim and emacs and every Java IDE I know of) I will say without hesitation that IntelliJ Idea is by far the best tool to edit [Java] code.

I was a part of the EAP (Early Access Program) and witnessed for a year how IntelliJ was developed based on what developers requested through a democratic system.

The result is an IDE that removes ALL forms of coding gruntwork while staying completely out of your way. It actually borders on being psychic in many cases.

To Eclipse's credit, it's playing catch-up as fast as it can. If you can wait a year...

[ Parent ]

ECB might be an option (5.00 / 3) (#46)
by jschwarz on Wed Apr 02, 2003 at 04:56:18 AM EST

Anyone using Emacs for development should checkout ECB (http://ecb.sourceforge.net/). It makes for a nice IDE-like environment.

Why not gvim? (4.50 / 2) (#49)
by stormysky on Wed Apr 02, 2003 at 07:17:13 AM EST

Personally, I love using gvim with this little patch so that I can have my cutsey background while I code. Typically, I have about 20 gvim windows, most with multiple files open in them, and an old copy of win32.hlp, when I do windows brewing. Erm, coding, sorry, the mead article's on my mind. Anyway, I believe it's relatively easy to substitute gvim as the default editor in VC, (at least, version 6) and it supports all the features you'd expect in a modern editor, like syntax highlighting, without the extreme memory footprint emacs boasts; gvim's at least half the bloat... editors shouldn't have to go on diets --- but some of us who use 'em probably do. :)
We can face anything, except for bunnies.
JavaImp.vim (none / 0) (#53)
by The Shrubber on Wed Apr 02, 2003 at 08:21:37 AM EST

... for java, vim users should check out William Lee's excellent JavaImp script: http://www.vim.org/scripts/script.php?script_id=325

Among other things, it'll save you from ever having to write an import statement again.

[ Parent ]

gvim rocks (n/t) (none / 0) (#99)
by Siddhi on Wed Apr 02, 2003 at 10:54:13 PM EST

[ Parent ]
Slashes vs Backslashes (5.00 / 1) (#50)
by Hightc on Wed Apr 02, 2003 at 07:23:56 AM EST

Forward slashes work in path names fine in windoze, always have and always will.  Much easier than escaping backslashes all the time.

Not *always* (none / 0) (#104)
by baba on Thu Apr 03, 2003 at 12:23:11 AM EST

If I recall correctly, this is partly program dependant. As far as I remember, the internal APIs sort of follow the rule of either kind of slash, but try to do a deep subdirectory listing in "command" window (NT or 2000, not sure about elsewhere) using forward slashes, and you'll see an example of this rule not working.

[ Parent ]
For example: (none / 0) (#111)
by Nurgled on Fri Apr 04, 2003 at 09:07:01 AM EST

Try using the cd command built into the Windows NT command interpreter with forward slashes. It assumes forward slashes are DOS-style "switches" and will usually tell you your switch is invalid. Sometimes even more obscure things happen because your path happens to trigger one of the valid switches.

Great fun.

[ Parent ]
Why? (4.00 / 3) (#54)
by lazyll on Wed Apr 02, 2003 at 08:33:02 AM EST

I don't understand why you would want to use emacs over VS? I use emacs, but that's because I run linux on my desktop and I code for a linux platform. I mean, he's working on a windows box, and he compiling VS projects, why does he insist on use emacs?? The whole point of this article is to describle all the crap you have to go through to make emacs almost as good as VS. I don't understand.

I have refrained (4.50 / 2) (#60)
by sludge on Wed Apr 02, 2003 at 09:23:55 AM EST

... from any advocacy in the article. I continue to do so here, except to state the obvious: If I'm willing to put that much effort into Emacs, it must work for me for other reasons which I would be throwing away to use alternative software packages.

[ Parent ]
I stopped reading about here... (4.14 / 7) (#56)
by Silent Chris on Wed Apr 02, 2003 at 08:41:55 AM EST

"Hopefully reading on will fix one or more of your pet peeves with the one true editor, and keep you plugging away on Free Software as much as possible."

You make two incorrect assumptions (actually, one's a mistake).  

  1. VS .NET (7) is not an editor.  If I want an editor, I use emacs, vi, or even notepad -- which I do.  VS is a tool to pull together code, structure and ideas in a nice GUI package.  It's worthless for multiplatform development, it's semi-ok for web development, but there's nothing better for Windows development.
  2. For some reason, some Free Software people think once you've started using commercial tools, you're forever indebted to the dark side.  Not at all.  I work on a number of FS projects using Visual Studio (mostly when there's a port to be done to Windows).  There's nothing in Visual Studio forcing you to use proprietary libraries (in fact, Visual Studio .NET starts you off with a completely blank slate with absolutely no references).  All it takes is referencing the FS code of your choice (which you would have to do anyway in emacs or another editor).
I understand there's aversions to VS.  That's understandable (it ain't perfect).  But I don't understand, when you're given the right tool to do the job, you don't use.  (By the way, if you balk at the cost, try picking up the Academic edition.  I got what's essentially the professional toolkit for under $150).

A lot (4.00 / 1) (#57)
by Kal on Wed Apr 02, 2003 at 08:53:26 AM EST

But I don't understand, when you're given the right tool to do the job, you don't use.

I think a lot of people would disagree that Visual Studio, or any IDE for that matter, is the right tool for the job. Personally, I don't care for them. An editor and a few shells is a far more flexible arrangement.

[ Parent ]
It depends (none / 0) (#63)
by Silent Chris on Wed Apr 02, 2003 at 09:56:59 AM EST

If I'm writing a console app, daemon -- er, service, or anything that doesn't really need a GUI, I totally agree.  Since 99% of my *nix apps are console, emacs suits me fine on that platform.

However, when I absolutely need a GUI, I find it's a lot easier to plunker down a few buttons and assign them code then write things like Button1 = new button(200,150,50,50).  There's too much tactile response that needs to be evaluated, and writing code to do it (especially when the widgets are constantly changing) is a waste of time at best.

[ Parent ]

In that case (none / 0) (#72)
by Kal on Wed Apr 02, 2003 at 12:22:10 PM EST

You just need to pick the right language to write a GUI in. A good one will allow you to do it with just a few lines.

As an example, I just looked at some code I wrote last Friday that'll make a little GUI with a few monitors watching a pair of processes, a filesystem, and a set of files. The GUI elements took up a whole 20 lines. This includes making the window, making the widgets, packing them, and updating the important bits as things change (Little boxes go from green to red, size indicators increase, things like that). In this case the whole application is only 150 lines (it could probably use some refactoring) but even looking at a larger one the GUI elements account for 160-180 lines out of 3000.

Back in college I used to use Glade to make GUIs but now that I've actually had experience with a few more languages I tend to use a TKish language like Tcl/TK, Perl/TK, and I believe Python has a TK option as well. I just find it far easier to write a GUI in those than it would be to do it in an IDE.

[ Parent ]
That depends (4.00 / 1) (#67)
by Simon Kinahan on Wed Apr 02, 2003 at 10:16:07 AM EST

I've yet to find an IDE that is better than Emacs for C/C++, but for other languages, in particular Java, the IDEs are vastly better. Having reliable, context sensitive find (no, not grep, and no etags is not good enough), refactoring tools, and context-sensitive help (when you press ., you get a list of methods) I reckon adds about 25% to my produtivity.

The reason these tools are not avaiable for C/C++ is the inherent difficutly of parsing the language, although I understand that VS.NET is getting there (I haven't used it). There is no inherent reason these things have not been implemented in Emacs, but they haven't been.


If you disagree, post, don't moderate
[ Parent ]

What do you mean by... (none / 0) (#74)
by Kal on Wed Apr 02, 2003 at 12:28:54 PM EST

Context sensitive find? The help bit I understand and have seen before. Personally, I found it to be annoying and usually disabled it if possible.

Someone further down posted something else about refactoring tools but I'm kind of of two minds about their usefulness. On one hand it's cool that you can take a block of code and tell the tool to make a method out of it. On the other hand it seems that doing things that way isn't really refactoring in the sense that I've seen it used, more just moving code around.

I believe the reason these things aren't in Emacs is that no one has bothered. The lack of these features haven't annoyed someone that would add them to Emacs so they just don't get in. If you find that you need them, why don't you put them in? Myself, I don't even use Emacs just a bare bones Vim, and I haven't felt the lack of any features that are present in an IDE.

[ Parent ]
Context sensitive find .. (5.00 / 1) (#81)
by Simon Kinahan on Wed Apr 02, 2003 at 01:54:27 PM EST

... meaning "go to declaration", "find all assignments", "find all references" and so on. Very useful for reverse-engineering, or getting an idea of how someone else's new code works.  

Refactoring tools are immensely useful. They allow you to make simple, but large-scale changes to your code very easily. When making revisions to existing systems, to include new functionality, this really matters. Given the emphasis newer methodologies place on refactoring and maintenance, automated support is almost essential. Refactoring does, essentially, mean "moving code around". Refactorings are changes to the design that do not change the functionality.

I'd suggest the reason people haven't added these features to Emacs is twofold: very few people are competent elisp programmers (and it's not a nice language, even as Lisp dialects go), and most programmers are payed to get their jobs done, not extend an archaic text editor to include features that exist elsewhere. Seriously, Eclipse exists and is free: why extend Emacs ? These are hardly the only deficiencies in Emacs: even the default C-mode syntax highlighting mode is hideously broken. Getting the thing up to the standards already acheived by modern, commercial Java IDEs (can't speak for C++ - I use Emacs for that), would take months of work.

I used to have roughly the same opinion of IDEs you have. I still think 99% of them are crap. JBuilder, for instance, is not worth using. Until sometime in the middle of last year I did my Java development in TextPad. I changed my mind with IntelliJ IDEA 1.2, which got find and refactoring support foor Java up to the level of Smalltalk in 1980. I now consider Eclipse to also usable, albeit not as good as IDEA.


If you disagree, post, don't moderate
[ Parent ]

just wondering (none / 0) (#96)
by martingale on Wed Apr 02, 2003 at 07:14:04 PM EST

I expect you've tried JDEE at some point. What were your gripes? I haven't written Java code in years now but every once in a while, I update the JDEE elisp files to keep emacs up to date, in case I need it on short notice.

[ Parent ]
It's not bad (none / 0) (#105)
by Simon Kinahan on Thu Apr 03, 2003 at 04:08:56 AM EST

I last used it about 3 years ago now. At that time, the speedbar was clunky and I couldn't make the browser work, but the screenshots on that site look as if these things have improved. I preferred it over JBuilder, which was the no 1 Java IDE at that time.


If you disagree, post, don't moderate
[ Parent ]
Making Visual Studio even better (5.00 / 1) (#61)
by sien on Wed Apr 02, 2003 at 09:24:38 AM EST

I have to add a plug for the best plug in I have ever seen - Visual Assist . It has variable name completion which is really impressive. It also extends variable information and other features of Visual Studio.

You can download a free 30 day trial version, it's well worth the time.

Even better.. (5.00 / 1) (#106)
by milksop on Thu Apr 03, 2003 at 04:37:28 AM EST

Is Workspace Whiz. My company bought a site license for VA, so I have worked with both for a while. The "tags" type functionality in VA is terrible.

The best of both worlds is to use both, but you end up with dupe functionality. The main thing that that VA has that WW doesn't is the enhanced syntax highlighting, which is kind of nice. Overall, I definitely choose Workspace Whiz though.

i make games.
[ Parent ]

Bah! (3.62 / 8) (#64)
by Rocky on Wed Apr 02, 2003 at 09:58:49 AM EST

All the editors shall bow before the One True Editor - ed!

ed will crush it's enemies, and hear the lamentations of their women!

If we knew what it was we were doing, it would not be called research, would it?
- Albert Einstein (1879 - 1955)

Not a viitor. Not an emacsitor. (5.00 / 1) (#80)
by ethereal on Wed Apr 02, 2003 at 01:35:27 PM EST

Those aren't even WORDS!

It helps if you imagine the voice of Vizzini from the Princess Bride during this diatribe :)

ed: the one true text editor


Stand up for your right to not believe: Americans United for Separation of Church and State
[ Parent ]

bah, Dom is superior and you know it! (n/t) (5.00 / 1) (#108)
by Belgand on Thu Apr 03, 2003 at 05:44:13 PM EST

[ Parent ]
c-set-style and the auto reform (3.00 / 1) (#79)
by bored on Wed Apr 02, 2003 at 01:33:56 PM EST

When it comes for formatting the default emacs mode (gnu) does suck. But there is a quick solution. M-x c-set-style. Then pick your coding style. Personally I use 'ellmental' with some minor tweaks for switch statements and class methods.

So, stick the following line in your c-mode-common-hook. (c-set-style "ellemental") and everything will be fine.

Personally, I don't like emacs and when I use windows I use the M$ VS IDE, but on linux/solaris/aix etc.. I end up running emacs because the company I work for doesn't buy everyone copies of Visual SlickEdit to run on their platform of choice. Instead I waste probably 10x the price of Visual SlickEdit in hours hosing with my enviroment so that I can press 'F7' and get emacs to compile.

Tip: :> Here is a cool little feature that VS doesn't seem to support (I don't know what the key sequence is). Emacs has a built in reformatter. Simply select your code block and press ESQ, C-\. Wham!

Reformat: Slick Edit vs Emacs (none / 0) (#86)
by Lagged2Death on Wed Apr 02, 2003 at 03:41:32 PM EST

My ancient (2.0c, circa 1997) copy of Slick Edit for Windows includes inclues a "Beautify Source" option under the "Other" menu. It re-formats even very large source files in the blink of an eye, even on my old 200MHz PC. When it's done, the source can be viewed as intended in any editor with the tab stops set up the same.

Emacs, on the other hand, makes me wait 30-40 seconds to re-format (with C-\) just a few thousand lines - even on my new 1GHz machine. When it's done, the indents are done with a bizarre mix of tabs and spaces that renders the code unreadable in anything but Emacs itself.

I want to learn to use Emacs, but this is the kind of thing that keeps making me run off and use something else when I actually have to get some work done.

Starfish automatically creates colorful abstract art for your PC desktop!
[ Parent ]
tabs (none / 0) (#109)
by han on Fri Apr 04, 2003 at 03:43:32 AM EST

By default Emacs treats tab as "advance to the next column divisible by 8", just like God intended. The confusion is caused by all those programs which set the tab width to some other random value, or even let the user adjust it at will. Changing the interpretation of a character in a plain text file simply cannot work because you need an out-of-band means to specify how exactly you should interpret the tab character in each file, and on unix you don't have such a way. Luckily, most text handling programs grok the right tab interpretation fine, so you're exaggerating a bit there...

However, the Emacs C mode can be configured to use plain spaces for indentation (see the variable indent-tabs-mode), if you are in an environment where you can't avoid alternate interpretations of the tab character. That's probably a good idea anyhow, since by now the whole unix world has become such an environment.

As to the slowness of the reformatting, that's caused by the crudeness of the emacs-lisp language, as discussed earlier here. There's not much that can be done about it, except buy a faster computer.

[ Parent ]

VS has autoformatting. (none / 0) (#88)
by cooldev on Wed Apr 02, 2003 at 03:58:35 PM EST

In VS.NET it's C-k C-f, or use Edit / Advanced / Format Selection.

[ Parent ]
VS.net (none / 0) (#89)
by bored on Wed Apr 02, 2003 at 04:15:00 PM EST

Hey, cool.. Thats pretty nice, well there goes my only reason for liking emacs.. :> I guess i'm going to have to upgrade my main development project to use VS.NET rather than VS 6. Except I don't like the way that VS.NET keeps moving my windows around. Nor do I like the new key mapping, I guess i'm going to have to get used to some new stuff! Yes I know about the old keymap mode, but I don't like it either because things don't behave exactly the same. For example in VS6 Alt-tab could be used as a quick little switcher between the help and whatever module i'm editing. Now I have to play around with hitting ctl-tab a couple dozen times because i've switched windows since I last viewed the help system.

[ Parent ]
WHAT YOU SAY???? (2.90 / 11) (#91)
by Bob Abooey on Wed Apr 02, 2003 at 04:18:08 PM EST

Based upon your informative article I ran out to the local MicroCentreTM and bought this fine VisualStudio program but for some reason I can't get it to install on Linux 8.0. Is there a bug fix or a patch I can download for free that will fix this?

Thanks for your quick reply.

Americans will tolerate just about anything as long as you don't stop traffic - Dan Rather

Try SciTe Instead (none / 0) (#92)
by n8f8 on Wed Apr 02, 2003 at 04:25:02 PM EST

Type Scite. It uses the same Text control as Komodo:


Some Features:

Syntax highlighting for every language imaginable
Cross Platform
Optional Tabbed Interface
Open Source


Sig: (This will get posted after your comments)

you people never will really get it, will you (2.38 / 13) (#93)
by turmeric on Wed Apr 02, 2003 at 05:55:19 PM EST

dependencies have to be checked. otherwise what you are doing is not compiling, its guessing at what might be compiled.

now the sane solution to this problem is to analyze the way make works, and optimize the speed of this program so that dependcy checking takes somewhere close to it's theoretical limit, which is like, 1 second or something.

instead you dumbfucks sit around using the same goddamn broken ass shitty crapholian 'make' program for 20 years, researching double blitted hyperspatial transofrmations so you can more fully animate japanese anime porn, and yet you dont give a rats fuck about improving makefiles.... other than buying yourself a new computer with the fat check the man is giving you.

screw the poor! screw those with shit hardware! screw anyone who actually cares about what tools they are using!

computer science is filled to overflowing with absolute moronic stupids who would gladly use a dinner knife as a saw and tell you you were an idiot for criticizing them for it. rather they wold tell you to attach a 300 dollar 5 hp electric motor to the saw, shrug and say 'works for me i dont know what you are bitching about you stupid clueless fuck'.

god i hate computer scine.ce

As much fun as it is to build a hot-rod out of (5.00 / 1) (#95)
by porkchop_d_clown on Wed Apr 02, 2003 at 06:44:52 PM EST

a Model A Ford, there comes a point when it's time to buy a new Mustang, instead....

EMACS was state-of-the-art a quarter of a century ago, the fact that it's lasted as long as it has is a testament to its excellent design. But, for God's sake, stop trying to teach the pig new songs and just buy a new pig!

Note that the depiction of the president as a deranged or Nazi paranoid is coming mostly from people who constantly tell us how passionately they

beancounting (5.00 / 1) (#97)
by martingale on Wed Apr 02, 2003 at 07:28:05 PM EST

Ha! Shows what you know about bean counting... The TCO of Emacs is simply lower than that of competing, especially short lived, pigs. Most of the new pigs require keystroke investments every few years, just to keep them going. Then they forget old foraging grounds and downtrodden coding practices, because there just aren't enough truffles to support the effort.

Switching to a new, clean and polished pig every few years is nice to impress people, but a dirty old hog has a lot more experience, and you simply know it remembers how to do a trick you last wanted to see ten years ago.

[ Parent ]

Yeah, but when some poor farm boy (5.00 / 2) (#98)
by porkchop_d_clown on Wed Apr 02, 2003 at 10:17:58 PM EST

fresh off the turnip truck runs into that ol' hog for the first time, well, it ain't purty!

Note that the depiction of the president as a deranged or Nazi paranoid is coming mostly from people who constantly tell us how passionately they
[ Parent ]

Emacs (none / 0) (#113)
by Dickie Crickets on Fri Apr 04, 2003 at 10:56:10 AM EST

Emacs, Emacs,
With macros writ in lisp.
Baby highlights syntax,
Highlightin' all day loooooooong.

King of Megaphone Crooners
xemacs is only good for sokoban (none / 0) (#114)
by biggs on Fri Apr 04, 2003 at 02:54:18 PM EST

i write java, and i wanted to like xemacs for writin java code, but it just sux compared to a netbeans + ant solution.

"Rockin my 'hell I made it' wetsuit stitch so I can swim in elevators crazy wet through piss" -Cannibal Ox
vim! [nt] (none / 0) (#115)
by 5pectre on Sat Apr 05, 2003 at 11:57:11 AM EST

"Let us kill the English, their concept of individual rights might undermine the power of our beloved tyrants!!" - Lisa Simpson [ -1.50 / -7.74]

Making Emacs Stand Up To Visual Studio 7 | 115 comments (98 topical, 17 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!