Posted
by
Unknown Lamer
on Monday May 21, 2012 @06:56PM
from the ignoring-preexisting-projects-for-fun-and-profit dept.

An anonymous reader writes "Emacsy is 'a Guile library that provides Emacs-like facilities — keymaps, minibuffer, tab completion, recordable macros, and major/minor modes — for applications natively.' However, to my eyes, it looks more like an attempt to revive the development style done on Symbolics Lisp Machines that survives to some extent in Emacs. Might be a boon to Emacs users, but where's a comparable VIM alternative?"
The skeptic in me asks what benefit this would have over just using libguile directly, and how it fits in with efforts to port Emacs itself to Guile and things like Englightenment's pluggable event loop. The example code seems to imply Emacs-like APIs will be used (despite not intending to replace parts of Emacs), even when better alternatives exist. Some of the proposed components seem orthogonal to existing interface toolkits; others seem to compete with components provided by various Free desktop environments.

Why would you use vi bindings in Emacs? Why not just use vim? ViperMode is especially terrible, it doesn't implement the function of vi's "f" or "t" commands, which I use only a million times every day.

Unlike the Linux 3.4 story yesterday, this one would have merited having a gnu picture at the top, as opposed to just a generic software symbol. Although I wonder whether the emacs symbol would have shown up had emacs been the first keyword used?

If they just included a shell - be it bash or any other - then one could just have emacs sitting on top of the kernel (linux, bsd, et al) and make it the sole user environment. Oh, and while at it, build in elinks functionality into it as well, so that it could be used for web browsing.

My personal feeling about emacs is it is very beautiful(yes). Let the point-and-click gui-using critics learn a thing or two about why making everything programmable(in a easy way, unlike eclipse) is an awesome idea.

Let the point-and-click gui-using critics learn a thing or two about why making everything programmable

No-one can really understand this without years of use though. Key bindings (which are widespread) are nice and all but it is as you say, the sheer ease of programability of the thing that makes Emacs so amazingly useful that I still turn to it even these days (though I mostly use integrated text editors now).

Only when emacs becomes really embedded in something modern will other people see the light.

I used microemacs back on the Amiga but the learning curve on it is just so high. Add in that IDEs now do so much more than just editing text and the benefit to time ratio for emacs just isn't their for me.Too bad because I would really like to use it or or vi but their are must not enough hours in the day.

Microemacs is a completely different beast than Emacs. It has all the arcane keybindings with only a fraction of the functionality of Emacs. It really only exists so that Emacs users can have an editor that feels familiar on underpowered platforms that cannot fit a full Emacs installation. I definitely wouldn't recommend it to newbies, and you should in no way judge Emacs based on your experience with microemacs.

You're correct on most counts, except maybe regarding newbies. I started out with a commercial (Unipress) version of Emacs, heavily customized, in the late 1980s. Our overlords (the contractor we were subcontracted to), rather than buying the source, foolishly bought the binary version for Motorola-based Sun workstations, so we were out of luck when we switched to SparcStations. I downloaded the original MicroEmacs, modified some of the code for my own purposes, and heavily customized it. I've used it o

Not really. The hard part is knowing Lisp and I agree that too few younger people bother with it anymore. The actual interface to Emacs for configuring is well documented though with tons of examples. Of course I've been using for 25 years so it's second nature. When I try to use an IDE it is sheer frustration having to click a thousand times to do something simple. I use both Emacs and VI, and I can live without VI easily but would pull my remaining hair out if I couldn't use emacs.

My complaints are threefold:* Not mouse friendly. While keyboard shortcuts are awesome, they're very hard to use without practice. Having every option in a menu, somewhere, means that when I want to do some rare thing like "invert the case of these letters", I can just hit Edit->Characters->Toggle Case instead of checking the manual pages to find that it's Control-Meta-i or whatever. If I use that command often enough, I'll learn the shortc

if you happen to be on a mac, aquamacs does a pretty good job of mixing emacs-style keystrokes with the "normal" ones, cmd-Z, cmd-C, etc.; it also provides pull-down menus. but beyond that, it's still just as ugly, and even after many years i still get the vertigo whenever i have to go into the emacs preferences system.

aquamacs also comes with a lot of nice packages included.

one of the problems with emacs is that it just has way too many commands to fit reasonably in standard menus. aquamacs

I agree with Aquamacs. It's very nice. I went back to XEmacs on my windows machine and it feels a bit clumsy (but then everything on Windows feels clumsy, and FSF Emacs on Windows is even worse). Most of the same stuff they add in Aquamacs can be put into normal Emacs as well as an option, and some are already in Emacs and just need to be switched on.

You can hardly blame Emacs that programs which came years later chose different keyboard commands.

As for not being keyboard-centric rather than mouse-centric, some of us consider that a feature. Being created before mice has something to do with that of course but having to pull your hands off the keyboard to find the mouse is terribly slow. Yes, there's a bit of effort needed to learn enough to make running Emacs comfortable but when you're there you'll find how painful mice are. By the way, C-/ is only

You can hardly blame Emacs that programs which came years later chose different keyboard commands.

But I *can* blame it for not giving up and joining the crowd. The only program I regularly use that doesn't use the "Standard Shortcuts" is bash - and the only commands I need to know are ctrl-a, ctrl-e, ctrl-k, ctrl/alt-f, ctrl/alt-b and ctrl-d

As for not being keyboard-centric rather than mouse-centric, some of us consider that a feature. Being created before mice has something to do with that of course but having to pull your hands off the keyboard to find the mouse is terribly slow. Yes, there's a bit of effort needed to learn enough to make running Emacs comfortable but when you're there you'll find how painful mice are. By the way, C-/ is only harder than C-z if your right hand is stuck over on the mouse.

Given a choice between "take my hand off the keyboard to click some menus" and "open a new terminal window, open the man page, and look up the keys I need", I'll take the former every time. Hell, given a choice between reading the manual *again* and just doing it *ma

Second, they are more efficient than the "standard bindings" if you're a touch typist (you don't have to move your hands to the arrow keys to move around with the keyboard, for example), and they provide far more features than same.

It's a power user tool. If you don't have power user needs, and don't want to deal with the steep learning curve, that's fine - there's nothing wrong with that at all. There are plenty of other tools

You might as well blame everything else for not using Emacs shortcuts, since they were there and used in other software (yes, those bash shortcuts are Emacs shortcuts). I mean really, holding shift to select text? Madness.

As for not being keyboard-centric rather than mouse-centric, some of us consider that a feature.

Being keyboard centric isn't a problem, quite the opposite. Having a god awful GUI on the other side is a problem. A good interface should slowly teach the users about shortcuts and everything and while Emacs actually does a good job at that (if you M-x a function that has a shortcut, it tells you which), the GUI is scarring users away long before they'll ever find that out.

The problem is that Emacs was kind of state of the art some two decades ago, today on the other side it just shows it's age a little to

It's a text editor. Removing your hands from the keyboard is inefficient and slows you down. Until you have become proficient at this, you don't realize just how inefficient your wish to use the mouse for text editing actually is.

Emacs is a power user tool. For a single purpose, editing text, it is the most powerful and fastest tool available. It's admittedly not well suited for people who want a more casual tool, but there are others you can use for that purpose.

It's a text editor. Removing your hands from the keyboard is inefficient and slows you down. Until you have become proficient at this, you don't realize just how inefficient your wish to use the mouse for text editing actually is.

Emacs is a power user tool. For a single purpose, editing text, it is the most powerful and fastest tool available. It's admittedly not well suited for people who want a more casual tool, but there are others you can use for that purpose.

I think he gets this. I know I do. I myself LOVE having keyboard shortcuts. However, when it's something I don't do very often, I much prefer having the OPTION of having a menu that I can go through to find the command that I need. It means I don't have to go through the manual or look online or in some way leave the window I'm in to find the command I want to use. I can just...do it. Sure, it's slower than knowing the shortcut, so if it's something I'll be doing often, I'll learn the shortcut (assumi

If your editor has a menu to toggle case of letters then it must have hundreds of menu entries to have something so infrequent show up there. If you really need it you can add it to an Emacs menu easily enough.

Emacs has very compatible short cuts! It is compatible with editing that existed before PCs and Macs existed! So I'd say the Windows editors are the ones who broke compatibility! And by the way I can use my common Emacs movement keys in Firefox just fine, they work in bash, some of them even work in Outlook.And Ctrl-Z does undo in my emacs.

The interface in Emacs is nice: it's minimal. I don't have 2/3rds of my screen wasted in IDE fluff. I can put three Emacs windows side by side.

Variable width fonts are EVIL. Never use those for programming! If you've got variable width how do you make things line up, and how do you know you haven't exceeded 80 characters? Variable width is for natural language text.

"Toggle case" is actually somewhat common, and not at all hard to find when it exists. I don't have any of my code-editing programs installed (home computer), but LibreOffice has Format->Change Case->tOGGLE cASE, right next to Sentence case, lower case, UPPER CASE, and Capitalize Every Word. Capitalized just like that, even, for ease of use.

Oh, and I'm not opposed to variable-width fonts for writing code - that is, after all, logical. But monospace text on the "where you are in the file" and "what mod

Actually I had arguments ten years ago over the 80 space limit, and the person's response as "why can't you get a modern editor that can have longer lines?" He just didn't get it. Long lines are harder to read, it's that simple. It's a courtesy to other programmers, like any other style rule. This person had 200 character lines, he would literally have a line of code all the way across the screen. None of his peers found this easy to read. It wouldn't fit in printouts. People complained in code revie

Another reason: keeping it at the 80 character limit allows you to open more than one source code window at a time and view them side by side.

I've found people who are opposed to the 80 character norm often do so because they are used to IDEs that take up the whole screen. If you only have one window to write code in, and that window fills up the whole screen no matter what else you do, what's the point of leaving that space blank? Might as well write longer lines.

12 might be overkill. If you have more than one window open at a time, you can reference source code in one terminal while writing in another. This is a common workflow. Typically I find I have two or even three files that I am referencing frequently while writing in a project, but sometimes more.

People who are used to this style of working often have trouble at first when they switch to an IDE. Now with things like auto-complete and Intellisense, it isn't as bad as it used to be, because you don't have

Now with things like auto-complete and Intellisense, it isn't as bad as it used to be, because you don't have to remember the full function name, you can get away with remembering only the class name,

Why would you need to remember functions names or class names to use auto-complete? The whole point of the feature is so that you don't need to do that.

For those of us who know how to use multiple windows, once we get used to Intellisense it isn't as bad, but we always miss the multiple windows.

We seem to be going in circles. As I had already noted, it is not at all a problem to open several windows in a modern IDE, and with a good display you can easily do side-by-side with line width much higher than 80.

Then again, when code is properly modular, I don't see the need for that, either. If I need to know the signature of some function that I'm about

Chrome and recent editions of Firefox badly break the CUA standard (no visible File/Edit menus, F10 does not bring up menu bar, and so on. Unity and Gnome 3 trash its goals of consistent, discoverable interfaces even further. Compared to these, Emacs with its decades-long consistency is a gold standard.

* You can make the menus in emacs display whatever option or function you want. Also, ido-ubiquitious mode will give you a fuzzy search on a meta-x. So if you can't remember the keyboard shortcut, perhaps you can remember (or guess) some part of the name of the function that does what you need, and quickly find it (with tab completion and everything) - probably even more quickly than you would by searching a menu.

The most interesting thing about Emacs isn't even just the programmability, as a lot of apps have that in one way or another, but the fact that it is self-documentation. It takes literally two clicks to go from any function or keyboard shortcut to the exact line in the source code that defines it (first jumps to the documentation, second to the definition). Nothing else in the Free Software world makes source that easy to access, most don't even try. Blender being the only exception, as that at least gives

Next up: Boot to Emacs. We've always known that Emacs is a great OS with a piss-poor text editor. We need these capabilities baked into hardware. Behold... the EmacsBook Pro!

Yeah, add to Emacs a shell such as bash, a windowing system like Wayland, a text web browser like elinks, and you'll have the complete OS. After that, the next big project to have Emacs run directly on HURD, so that the latter needs no other applications.

my escape is next the F1, a bit aside from it, on all my keyboards btw. Not so handy:(
Vi and Emacs should really adapt and change to the capslock. Or even better, keyboard makers should kick the caps to the ctrl place... and ctrl to caps. That would make sense. Gives the trolls rsi and us an economic place for a key we actually use.

Emacs is awesome, but there are some things that more modern IDEs do that are nice. In Eclipse you can get a list of all calls to a function from the spot where it's defined. I haven't been able to find a way to do that with Emacs. etags works great for jumping to the function definition, but not the other way around.

That's not enough to convert me to a pointy/clicky bloated thing for coding just yet, but at some point, it seems like there will be enough features like that that Emacs - even with a lot of customization - just won't be viable.

If I did move to another editor, at least it would be nice to bring the good parts of Emacs along.

I've been using CScope in Emacs for about a year (in fact, I added the entry to ascope.el on that wiki page you linked to), and I've recently switched to Semantic from CEDET [sourceforge.net] and GNU Global.

Sadly, the Emacs Code Browser (ECB [sf.net]) linked to from the CEDET page seems to be broken for recent versions of Emacs and CEDET and unmaintained.

While I dislike Eclipse for bloat and difficult extensibility, I have yet to decide whether Emacs has caught up with it for code browsing.

This is mainly a compiler related features rather than complaining Emacs. There is no magic behind Eclipse but just use a compiler front-end to analyse (sort of compiling) your code on-the-fly. For example Clang already provides function completion features to Emacs: https://llvm.org/svn/llvm-project/cfe/trunk/utils/clang-completion-mode.el . By examing the size of such code you will sooner understand why people stick to it even it lacks a good editor:-).

This comment makes no sense. Either emacs supports the feature or it doesn't. Other IDEs have supported reference lookup for years and in some it's quite mature. To put it bluntly, if your editor does not you are two decades behind the times.

It doesn't matter whether a quick-and-dirty feature could be hacked together faster in Emacs than in Eclipse or Visual Studio. Eclipse and Visual Studio already have it, and it already works better than whatever you were going to write.

But you don't get it. The point is, you shouldn't be building language-specific parsers (do you know how complex parsers are?) into an IDE! MSVS, to their credit, don't - they use a similar compiler architecture to LLVM, where the compiler is made up of various components that can be reused elsewhere.

The point is that the text editor is a really good text editor that can be augmented with scripts and external tools to do the same things as an IDE, but so vastly more flexible it's not even worth comparing th

However, to my eyes, it looks more like an attempt to revive the development style done on Symbolics Lisp Machines that survives to some extent in Emacs. Might be a boon to Emacs user...

Yeah, it's a classic. Oldtimers (or more often, oldtimer fanboys) trying to change the user interface on the rest of the world to work like their old favorite apps, rather than the other way around. It's so...

I don't know a single person who has kept vi(m) or emacs, because they aren't that old. They have, to a man, switched to them, and away from the CUA interfaces that were already near-universally adopted by their time. Yes, I think undue reverence for old unix gurus is the best explanation.

Curiously, those I know that are old enough to have used early 80s text editors extensively as adults (like my father), moved with the times to CUA-style edi

I can program anything in anything. The beauty of emacs is I can quickly create a very complex macro WITHOUT FUCKING PROGRAMMING ANYTHING. It may seem minor but the difference is as vast as a billion trillion oceans.

Admittedly, it doesn't sound like a very enticing feature to me - I'm a programmer, why would I prefer recording over writing a script?

Because it's interactive and immediate. It's much more tedious to write a script to do that, whereas an ad-hoc macro can be recorded in a matter of seconds (half a minute at most), then you can use it a few times and throw it away, just like that. II's the epitome of prototyping. Try looking up some videos on YouTube of people actually using Emacs macros properly. There was a guy who reformatted a Morse code table copied from a web page into a programming language data structure literal to be inserted into

Recording MacrosThe following procedure steps through creating an example of a simple macro.

The keyboard shortcuts used in this example assume the default Visual Studio shortcut key configuration.

To record a macro

Create a new text file by choosing File on the New submenu on the File menu.

Choose Text File in the General category.

In the new text file, type the following:

one two three four

Press HOME to place the cursor at the beginning of the text.

Press CTRL+SHIFT+R or choose Record Temporary Macro on the Macros submenu on the Tools menu to initiate the environment's macro recording mode. The Recording Toolbar appears and a small spinning cassette tape icon in the status bar indicates that you are currently recording.

Press CTRL+SHIFT+RIGHT ARROW to select the word "one" and the space after it, then press DELETE.

Press CTRL+SHIFT+R or click the Stop Recording button in the Recorder Toolbar to stop recording the macro. Notice that the spinning cassette icon in the status bar disappears when macro recording ceases.

At this time, if you open Macro Explorer and expand the MyMacros node, you should see a new entry called "TemporaryMacro" under the RecordingModule node. This is the default name given to newly-recorded macros.

I know that you can record macros in VS. You cannot, however, record macros that do things that GP has enumerated, for example, "record a search and replace based on text you found around the result of another search". You can script that manually, but not record it.

Start a searchuse any functions you please to grab a regex from that line, and put it into a register.Start another search, paste in the register.Do something once there.

"C-x )" ends the macro.

Basically the real power comes into play when you realize you have 26 registers to stick either text or cursor positions in, in the middle of the macro - and that macros also record actions in the control field at the bottom (for switching files or whatever).

F3 and F4 are better keybindings for macros in Emacs. As well as being single keystrokes, they have context sensitive functionality: F3 starts recording a macro, or while recording inserts an auto-incrementing counter. F4 ends recording, or when not recording plays back the last macro.

I'm not trolling, I just wish people could read the damn text before responding.

I said RECORD. As in RECORD. As in not SCRIPT OR PROGRAM OR DEVELOP. As in RECORD.

Like I said, I can record in emacs searching for something, using some value located around the search (say a quick regex on that line), then copy that and go to some pre-saved point in the file to paste the result.

That may sound contrived but I have for example easily created long list of variable names or altered things like comma separated data in partial ways that would have been hard otherwise, simpler even than using sed or the like... all because I could record a simple transformation to occur, then re-run it on command wherever I liked.

Basically I found it incredibly useful and it is the reason I still sometimes go back into emacs when even SCRIPTABLE editors are just too weak to get something done.

I said RECORD. As in RECORD. As in not SCRIPT OR PROGRAM OR DEVELOP. As in RECORD.

And as I told you in my post you CAN DO THIS IN VISUAL STUDIO SINCE THE ABSOLUTE BEGINNING. For example, this [microsoft.com] is the instructions from Visual Studio 6 since that's the earliest version that can be pulled up on MSDN.

If you are coding using macros chances are you are doing it wrong. I am not defending Visual Studios. But if you need macros all the time like you are implying then you are doing your code wrong. You may use macros occasionally as there may be some jobs that may need them to code faster. But for the most part of there is a patern that you can use a macro, you can fix your code so you don't need to and your code will be easier to maintain.

I can see you point but sometimes you use editors on files besides source code. I have had to import data from massive for the day text files that had issues. This was back in the DOS days so my choices where to write a program in Pascal to fix it or write a macro in Sprint. If I was doing it once I would write a macro in Sprint. If I was going to do it on a regular basis I would do it in Pascal.Now today I often just write a program in Perl or Python to deal with it but If I was an Emacs wiz I might use Em