Slashdot Mirror
The Future of Emacs
An anonymous reader writes "If you've not heard much about Emacs development in recent years, you might
be surprised to find that it is has been very active. Emacs 22 will have many
new features such as support for Mac OS X and Cygwin; mouse wheel support
and many new modes and packages. It can also be built with Gtk+ widgets and
supports drag and drop for X. The NEWS file details all the changes.
Although its very stable, don't expect to see it released any time shortly because according to
RMS, the Emacs developers haven't been fixing bugs quickly enough. Those
who have followed Emacs for long enough might see a different pattern."
fast as fast can be. you'll never catch me.
Since we're talking about Emacs here, it would be good to clarify whether Emacs will be running under OS X and Cygwin or the other way around.
I too have felt the cold finger of injustice.
i use Vi
It's no wonder so many open source projects never make it as far as a v1 release - emacs is stealing all of the version numbers!
22!!
I'd rather wait for vim 7. :P
If you've not heard much about Emacs development in recent years, you might be surprised to find that it is has been very active.
Wow - I just thought it was full.
I want to drag this out as long as possible. Bring me my protractor.
!q ao sf yc09 3 #% @ #$%! $R$^ &U ^O%(#T R(RU @( (DZUDX(UV EWER
DAMN vi KEYBINDINGS!!!
( to be fair, emacs keybindings aren't easy to learn either)
Emacs 22 will have many new features such as support for Mac OS X and Cygwin
Wait, so I can use my Emacs operating system on top my Windows operating system?
I'm still waiting for them to release an emacs that runs on the metal, without an inferior (read: not written in lisp) OS in the middle.
"Emacs 22 will have many new features such as [...] mouse wheel support and many new modes and packages."
Whoah, steady on there cowboys! That's some cutting edge stuff! =)
mouse-wheel.el has been providing mouse wheel support for years. It's just being added to the core distribution.
Till it has a clippy...
Give me clippy!
Deleted
I don't understand. Mouse wheel support already exists in Emacs : you just have to load the mouse-wheel-mode by default... Is it what the new version will do ? Load this same mode by default ?
I hate all sigs, mine included.
Mouse wheel support works in Emacs 21, at least for me. I run it in an xterm with xterm mouse support enabled, and can happily use the wheel to scroll up and down.
Thing is, I hardly ever use it. Emacs is a keyboard-driven beast. Even in non-xterm mode, one can productively use Emacs for years without touching the mouse. Wheel support is thus not particularly important. It's nice to have, of course, but it's not a vital feature.
-Stephen
Sorry, that is not a real man! This is a machine!
Wow! - mouse wheel support.
I totally agree. There's been support for mouse wheels for a long time in many X-windows apps. But how would someone using "the evil platform" ever take OSS(*) seriously when reading this kind of news?
(*) Oh, since this is GNU Emacs: s/OSS/Free Software/
WE need a poll!
Really, we do!
slashpoll:
1. VI
2. EMACS
3. Cmdr. Taco's notepad
Debian unstable has weekly snapshots of cvs emacs.- snapshot
http://packages.debian.org/unstable/editors/emacs
I have been using it for some time now and it works like a charm.
Even though emacs is a very good editor and development platform that for a long time have filled the purpose of being a swiss army knife for the software developer, I think its days of glory are over.
Sure there will be emacs for many years to come, but I guess that Eclipse will more and more play that role for the generation of developers that grew up with graphical user interfaces. More and more programming languages gets supported by Eclipse, and the support of the existing ones seam to get better and better, and the community around it are getting stronger and stronger.
Even so, its nice to see that old goodies like emacs are still supported and continue to evolve.
God is REAL! Unless explicitly declared INTEGER
"We are already out about more bugs faster than we are fixing them, and the cause is simple: we are not working enough on fixing them."
Or, it could possibly be that they are discovering bugs faster than they can fix them. But it is hard to tell, it could be that they just aren't fixing them. But I am not sure. What was the problem again?
He who knows best knows how little he knows. - Thomas Jefferson
---
(\(\
(-.-) Give me back my damn feet!
Generated by SlashdotRndSig via GreaseMonkey
Why is it that when you believe something it's an opinion, but when I believe something it's a manifesto?
Alright man, it's obvious you're just trying to get a rise out of people but let me assure you that emacs is not the only Linux based editor. You can try vi too
But seriously, I know for a fact that my scroll wheel works in emacs (windows binary even!) so check that out if it's so important to you. You know, some people just want a text editor without a huge memory footprint yet lots of functionality. I think programs like emacs provide exactly that and are what these people are looking for.
You can keep your windows editors
My work here is dung.
...this emacs-thing, is it the same as "the other editor" that i've heard about?
a full mouse support in text mode thru a ssh connection. This summer I had to program on a robot that had emacs installed, thru a ssh connection. Since X wasn't installed (and anyway I didn't want to do X forwarding), I couldn't use the mouse and it sucked. Anybody knows how it could be done ?
I hate all sigs, mine included.
now is 22th century ?
Can I get an Amen brother!
I just bought my dad an iMac, and was looking around for an emacs build for it.
Any ideas on an ETA?
Help! I'm a slashdot refugee.
Why would anybody use Emacs? There are so many good editors with syntaxis hightlight, function parameters popus, etc.
I couldn't possibly use any text editor or word processor without such a friendly user interface...
Deleted
you are meaning Emacs 22 will be done in the 22th century ?
What's so great about it that people insist on using it rather than any other editor? Seems all of the features are available for just about any other editor, and most of themare a lot easier to configure, and more compliant with UI guidelines.
You can keep your windows editors ... wait, how many of them are there? Notepad and wordpad? At least I've got a nice selection with just a basic Linux install.
Not trolling but this works both ways. Install Windows, need to use an editor, so use one. Rather than evaluate which one of X editors I'd prefer to use.
Just to demonstrate why a lack of choice might be a good thing, which is better: vi or emacs?
The current poll has only been up for two weeks! We're not due another poll until January, at the earliest.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
The main problem I see with Emacs is its terrible learning curve. Given the competing IDEs now available, I can't see any future for it unless it radicaly simplify the process needed to master the program. Drag'n'drop and mouse wheel support? That's not enough - I'd even say that they're against the traditional Emacs keyboard-only workflow.
The only future I can see to the Emacs style of working is in projects like Archy or Quicksilver, which completely redefine the particular tasks while keeping its strengths.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Emacs and Vi have both been around for a very long time. Back in the mid-late 80's, I remember taking some computational math and fluid dynamics classes. Part of the projects involved writing FORTRAN code and the professors used Vi. As a result, documentation was readily available so, I used Vi as well. Of course, Emacs was there too but the documentation was not as available. Frankly, just shutting the command line version of Emacs down took some research. Anyway, there was a palpable elitism among the Emacs crowd which I always assumed to be more due to them using the "un-official" and more complex editor. As for myself, I didn't care, the editor was the means to the end, not the end in itself.
Nowadays, Emacs (and XEmacs) have nice GUI's in front of them that greatly simplify their use. I use XEmacs on my Windows box (through Cygwin) at work and Emacs on my Ubuntu and SuSE Linux boxen at home. I still use Vi (Vim nowadays) when I need to quickly pop into the command line and do a config file edit, but I program in (X)Emacs. I know there is some sort of friction between the Emacs and XEmacs camp but that's not my concern. I use them both and I like them both.
It's very bizarre that, 20 some odd years later, the Emacs/Vi war still rages on. For me, the editor is the means to the end and always will be. Heck, with Ubuntu, I'm starting to use gedit more and more.
A goal is a dream with a deadline
In the next 3 - 5+ years I think editors like Emacs will die a natual death. If you want to edit a simple text file in a *nix environment, emacs is overkill. But if you are working on a complex project, the IDE that are available today offer a lot more than Emacs.
I used to be a heavy gvim user, but I find myself using it less and less. On my Mac I use Xcode and Eclipse IDE.
For those who can read Russian here's a discussion about [X]Emacs here: http://rsdn.ru/Forum/?mid=1322168
PS: I'm currently developing my own IDE (called FlexIDE) because _none_ of UNIX IDEs (and this includes Emacs and ViM) is good enough for me...
Real men use three button mice :)
Emacs 22 will have many new features such as support for Mac OS X
I thought all macs came with OS X.
.
.
.
.
.
.
.
.
.
Yes, I'm kidding.
Just another day in Paradise
Not trolling but this works both ways. Install Windows, need to use an editor, so use one.
Let me see... Notepad or wordpad?
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
EMacs is text mode. This means that you can still have a usable editor session even if your alteration of configuration settings have rendered your computer usable, or if you're accessing a system over a dialup line or cell connection. Linux GUI-based word processesors have had wheelmouse support for years. Unlike Windows, Linux developers still realize that we're not always on a highspeed connection, and thus, allow people to be productive remotely.
Marxism is the opiate of dumbasses
drag'n drop support?
Welcome to 1985.
WTF is EMAC?
They just provided mouse-wheel support?! Never mind... I don't care to know.
All the cool script kidies use pico or nano. ;)
.\.\att Clare
It wasn't submitted by Beatles Beatles!
for the win!
-everphilski-
I don't see any line item bugs for "Make Emacs like Eclipse". There should be.
Eclipse kills emacs. Emacs will be relegated to a super niche market if it does not borrow some of the techniques of Eclipse.
Eclipse has many more than the following advantages:
Programming domain issues have been thought out. Code gen follows some patterns, and eclipse makes far better use of them that emacs
-- Such advantages as click on a variable to go to its instantiation.
-- Underlining errors
-- sure you CAN spend hours trawling for the modules to do the same for emacs, but that sucks, and yields variable results.
A unified project space is opened up by default. You can see all your files.
-- It takes a while to work out where Speedbar is under emacs and it sucks. Even if it sucks it should be opened by default, like *scratch*
I'm happy to use Emacs everyday. But the reason I use it is:
I finally have a .emacs I'm happy with
You can run it well over ssh
It has emacs keybindings [duh, but important]
These are not enough reasons to bring new emacs users into the project. What do we do if RMS is hit by a bus or the existing emacsers eventually die of old age? Emacs people need to form and take ownership of sub projects around certain problem domains. e.g. Go HERE for Perl Emacs and HERE for XML editing. At the moment all you have is a loose coalition of Perl.com et alia articles.
[% slash_sig_val.text %]
AS far as I know, Emacs already supports the mouse wheel. I know I've scrolled with the mouse wheel, although it's some obscure option to turn that on. I find that I don't really use the mousewheel that much anyway though, it takes too long to move your hand from the keyboard to the mouse.
I think I'll stick to my Windows editor if that's where Linux editors have got to so far...
Emacs is not a "Linux editor" by any means. I think you mean "GNU editors".
Yeh vi is teh MASTERS of the text eidtor^?^?^?^?^? :recording macro
Are you sure that shouldn't be mouse-whe.el?
Why does emacs still live in the antediluvian world of dynamic scoping, unoptimized tail calls and stop-the-world garbage collection? Why does it include a lisp interpreter when pluggable interpreters are a dime a dozen? They should port the whole thing to common lisp, or to a modern compiling scheme like bigloo or chicken.
Well, I'd like to see another editor with which I can read mail, news, rss-feeds or which builts wikis or which has superior LaTeX support. And this are only my needs.
Which UI guidelines? Text editor UI guidelines? Care to provide a link?
I don't know about Emacs, but XEmacs fits nicely into Windows' GUI. Better than both on Linux.
UnNetHack: NetHack Improved!
... use Emacs. And a hearty colon Q bang to you, too.
Still far from the goal: 42
Think Deeper, Emacs!
May Peace Prevail On Earth
You know, I'm a fan of emacs, but doesn't this everything-and-the-kitchen-sink approach go against the Unix philosophy of making lots of small interoperable tools that do one thing really well?
I wonder when we'll get that on xemacs...
Yeah your right and I didn't even notice before.
Vi is a lot different from emacs. I use vi when I have to modify faster a configuration file from shell but I need emacs when I want to do something more complex. In my opinion the "war" between vi and emacs is a stupid thing. They are both good free software products, choose the one you like more, I like how emacs can be customized and improved with its emacs-lisp and I like vi when I have to edit a simple file. If you want the GTK version of emacs you can compile it by yourself, this is what I did.
vi.
Next question?
But seriously, for you, to edit under Linux I'd suggest just running "wine notepad". You'll be all set with your familiar app, and you won't have to worry about having to evaluate anything new.
I notice that the word "bidi" is conspicuosly absent from the NEWS file. That is bad. From time to time, I find that I need to edit RTL text in an LTR environment. Currently, Emacs doesn't help me with that. Granted, mixing RTL and LTR is a difficult problem (backspace is a different direction depending on where in the text you are, selections that are logically contiguous look real funny on screen etc), but Emacs is seriously behind the curve on bidi support.
was always "vi or emacs?" Since I was interviewing Unix developers, the answer could tell me a lot about them. The people with blank looks who didn't even know you were talking about editor were never asked back.
Genius is one percent inspiration and 99 percent perspiration, which is why engineers sometimes smell really bad.
Just wondering.
Perhaps it's just me, but I love new things. I think that's an important quality for one to have with ever changing new technology. If I have ever heard of a free editor, I have tried it. I love the possibility of infinite posibilities
Call me crazy, but I also like the idea of several people writing programs vying for my use of their program.
I don't know you at all, but I'm guessing we're fundamentally different in this aspect (so no reason to start flaming each other). Especially if you're using Windows and arguing in support of their unchanging editors. I hope you've tried textpad, I personally enjoy that much more than notepad when using Windows.
My work here is dung.
The headline makes it sound like Emacs is in some kind of danger. I think it's probably one of the programs with the least likelihood of going away, ever; almost everybody who uses it is qualified to maintain it and reluctant to stop using it. Emacs will be around as long as keyboards.
I still won't use it, but it'll be around.
You know, I'm a fan of emacs, but doesn't this everything-and-the-kitchen-sink approach go against the Unix philosophy of making lots of small interoperable tools that do one thing really well?
But you see, that is why emacs is so great, because all of these 'features' are not 'built into' emacs, but in fact emacs lisp programs that extend the basic editing functionality. The core emacs abilities are key to editing: supply a place for the text to be displayed (buffers), supply easy ways to switch between multiple files being edited (this may be slight overkill -- perhaps a window manager should be used for this, or some terminal switching type program, but getting the kill ring to come across those would be hard), supply a good arsenal of editing commands at a low level, and supply the ability to change the action mapped to any key. All the rest is on top of this core. A lot of the functionality is even sourced from other commands (like ediff -- uses diff).
I think it was Eric Raymond who said that all the time that went into snazzy interfaces and GUI support in other programs was spent on editing text in emacs. It shows -- if you want to edit text, use a dedicated text editor.
That being said, I think the main reason for Tetris in emacs is "because it's there" -- on some geek level it seems quite cool to me.
Languages aren't inherently fast -- implementations are efficient
Where did you get that IDEa?
Compare Eclipse (an IDE) to Emacs.
(Whoopsie, no comparison....)
Emacs has supported viper-mode (vi bindings) for quite some time now although I still prefer to use vi (or vim) over emacs.
Isn't emacs horribly stagnant these days? Gtk support has been coming for ages...
I'm actually banking on eclipse these days (even for non-Java development), I'm a former emacs "loyalist" (even implemented some elisp tricks and put them on the net) but I'm just getting too old to spend lots of time configuring my environment to behave exactly the way I want it to.
Save your wrists today - switch to Dvorak
I'm voting for VIM. (Just for record: I used vi once on Solaris - it's pain. So please please please all those Linux users do not mess vim with vi. If you have used only Linux that would mean you never really seen horrors of vi - all of OSs of GNU/Linux fame use vim instead of vi.)
I've seen people used to use emacs. But I've never seen anyone who really knows what is going on inside. Or truely understands how some things work. People just got used to Emacs - not understood it. Emacs is like religion - you cannot understand it by definition.
I like VIM. It integrates easily with Unix tools and shell.
In contrast, Emacs integrates with nothing - it has replacement for all the tool normally one would expect to be implemented on OS level.
Emacs is great tool, but learning it with all its modes and buffers could fill one's full-time position.
GNU - GNU's Not Unix, and Emacs is the confirmation. Try (re)configuring VIM and then try to configure Emacs. Emacs's init.el/friends always remind of sendmail.cf.
VIM doesn't have all the bells and whistles - but it does one thing and does it well. Emacs IMHO does many things - but does them averagely. After several years of unsuccecful tries to adopt almighty Emacs, I gave up on it. I know VIM and Bash - and can already do my job. With Emacs, regardless how much you already know Emacs is always ready to provide you with many new problems and obstacles. (Once I have tried to teach Emacs to use tab instead of spaces. It's very long and sad tale with no happy-end.)
VIM is simple and only hard thing to learn there is Insert v. Control mode. Once you got that, you can work already. I do not like it much - but I definitely like it more than cascaded N time nested M character long shortcuts of Emacs. VIM's simple shortcut structure also IMHO friendlier to touch-typists.
From programmer's POV, CC-mode is definitly superior to what VIM has to offer. But on other side, if something in CC mode doesn't fit your needs you might end-up killing two weeks to figuring out how to change that. VIM was hard to learn to use effectively. But once you learned it - due to its easy integration with OS - you find that you can make tasks you did before in shell better/faster/easier. (You can call Perl from VIM - or you can call VIM from Perl - choice is all yours.) It doesn't nullify your experience with Unix - like Emacs does - but rather magnifies it. IMHO.
All hope abandon ye who enter here.
1. It's a philosophy, not a dogma. ;-)
2. Emacs is not really only a text editor. It is a lisp interpreter whose first program was written to emulate a text editor. From there it developed.
3. Vim tries to be only a text editor and look what a monster this thing has grown into!
I think to hold the everything-and-the-kitchen-sink approach against the Emacs family of programs would be like to question Linux because it implements things that are not found in other Unix OS.
UnNetHack: NetHack Improved!
Emacs Lisp is the glue for connecting all those little tools into one cohesive environment in a unified display and input framework centered on text. It interfaces seamlessly with grep, find, ls, shells, locate, make, gcc, even latex and dvips (the preview-latex functionality of AUCTeX offers true WYSIWYG formulas in the source buffer) and major internet protocols.
If anyone here has used a recent version of vim, you might notice scroll wheel support in it. And I mean through a terminal window: not talking about gvim/X11. When vi starts having features emacs doesn't have... :P
Why is emacs development so ponderous? I know that RMS has driven away some competitors with his draconianism (which resulted in Xemacs), but emacs is like the first and favored son of the GNU system, right? I guess the emacs code base is very big, but any thoughts on what gives?
Incidentally, there is already a Carbonized version of emacs for OS X that's pretty nice: nicer that the Carbonized version of gvim. I still generally use vim on OS X (or for that matter, Linux) machines though.
(%i1) factor(777353);
(%o1) 777353
I love Pico. It's much more friendly. It doesnt have as much geekcred but its my editor of choice. Vi and emacs smell of ass nuts.
Despite the trollish title of this post, I'm essentially an emacs fan. I am a writer, not a coder, and prefer the command line over GUI. I am the author of the Woodnotes Guide to Emacs for Writers (HTML) (PDF Version) and a bunch of books and papers..
But I find myself using emacs less and less frequently. My first complaint is getting emacs and my Linux console to work correctly with diacritical marks. I know that's a function not only of emacs but also the packagers of my distribution, plus a deplorable lack of easily-installed console fonts that contain those glyphs. But regardless of whose fault it is, this problem makes it hard for me to get my work done the way I want to.
I also need to program lots of small macros for very specific text editing features while writing a book that requires a silly markup format unique to the industry. Emacs was simply too hard to program for me to be able to implement it. Instead, I found Jedit, which easily facilitated things like switching between soft and hard wrap, keystroke macros, and some features I now find indispensable, like search and replace across all documents in a directory.
It's not that emacs doesn't or can't implement these features, it's that it doesn't do so easily. I wrote up a little page about the macros and jedit features I use most frequently. It would be extremely difficult to publish similar instructions for emacs because of the greater difficult inherent in installing, using, and sharing macros.
I still use emacs, but I use it for emailing, in conjunction with Mutt, the world's best email client. And for writing, I tend to stick to Jedit. Best of luck to emacs, which I still like, but I think for people like me the world has progressed and emacs is of limited use.
If this were Usenet, I'd killfile the lot of you.
I'm feeling trollish, but I have to say it : if you are new to linux, you won't touch emacs (nor vi, nor ed, nor...) you'll probably use a graphical editor which works 'out of the box' (or out of the emerge, or out of the apt-get) which has auto-highlight, the same shortcuts as windows editors. Of course they also have mouse wheel support since many years.
emacs is made to work in text-mode and use a lot of cryptic (let's get real) shortcuts that you just have to know. If you are ready to train a day or two memorizing them, you'll probably be comfortable and productive with it but if you are not, juste use kate, scite, etc... which are editors equivalent of your usual 30$ windows-shareware tool of choice.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
I have never understood the name Emac. iMac, ok; maybe the "i" stands for "interactive," or "internet."
But "e," as in "email" or "e-commerce," means "electronic." So what you've got here is an electronic Mac? Well geez, how do all the other kinds work? Are they a mass of cogs and springs on the inside?
I definately agree. Even both are text editors, they serve very different purposes. On one side, you have the quick and dirty editor that is very effective for a few changes (even if it's for the entire document), and on the other hand, you have the larger, more complete (imo) full featured editor for larger tasks.
/. just likes flamewars.
But then again, I think
Once you've really learned emacs, you'll never need another editory again (unless you use vi for quick&fast edits...but then, I don't use emacs as my shell
As far as all the features being available in just about any other editor, you're dreaming! Show me another editor with Buddha-nature! (Especially one that doesn't need a mouse
--LWM
Emacs supports it. It really does!
FSF Emacs is unusable for one single reason:
Antialiased fonts. XEmacs merged them to MAIN a month ago. FSF Emacs folks aren't working on that stuff.
Well, I'd like to see another editor with which I can read mail, news, rss-feeds or which builts wikis or which has superior LaTeX support. And this are only my needs.
I tend to use other applications to do these tasks. they tend to do a much better job. I have a multitasking OS. What I want is folding, syntax completion, and parenthesis matching that works in both directions.
Which UI guidelines? Text editor UI guidelines? Care to provide a link?
No. Guidelines for the OS. Applications are meant to be consistent. Even different versions of Emacs for windows aren't consistent with each other. Pressing alt should activate drop down menus. Quitting without saving should give a modal dialog asking if you want to save; not a drop down menu. Multiple buffers should be spearated by a split bar. Shortcuts for menus should be listed as Ctrl+X rather than (C_x). No drag and drop for selections... XEmacs sorts out the alt-menu issue, and close dialog, but has a hideous load dialog and assumes I'm using Windows' default colour scheme for the button bar. And the key bindings are totally different from every other windows editor.
Emacs is not a "Linux editor" by any means. I think you mean "GNU editors".
;)
Emacs is not a "Linux editor" by any means. I think you mean "GNU/Linux Editor"
Woohoo, terrific reference to Asimov! Thank you!
The Last Question
by Isaac Asimov
Copyright © 1956 by Columbia Publications, Inc.
The last question was asked for the first time, half in jest, on May 21, 2061, at a time when humanity first stepped into the light. The question came about as a result of a five-dollar bet over highballs, and it happened this way:
Alexander Adell and Bertram Lupov were two of the faithful attendants of Multivac. As well as any human beings could, they knew what lay behind the cold, clicking, flashing face--miles and miles of face--of that giant computer. They had at least a vague notion of the general plan of relays and circuits that had long since grown past the point where any single human could possibly have a firm grasp on the whole.
Multivac was self-adjusting and self-correcting. It had to be, for nothing human could adjust and correct it quickly enough or even adequately enough. --So Adell and Lupov attended the monstrous giant only lightly and superficially, yet as well as any men could. They fed it data, adjusted questions to its needs and translated the answers that were issued. Certainly they, and all others like them, were fully entitled to share in the glory that was Multivac's.
For decades, Multivac had helped design the ships and plot the trajectories that enabled man to reach the Moon, Mars, and Venus, but pas that, Earth's poor resources could not support the ships. Too much energy was needed for the long trips. Earth exploited its coal and uranium with increasing efficiency, but there was only so much of both.
But slowly Multivac learned enough to answer deeper questions more fundamentally, and on May 14, 2061, what had been theory, became fact.
The energy of the sun was stored, converted and utilized directly on a planet-wide scale. All Earth turned off its burning coal, its fissioning uranium, and flipped the switch that connected all of it to a small station, one mile in diameter, circling the Earth at half the distance of the Moon. All Earth ran by invisible beams of sunpower.
Seven days had not sufficed to dim the glory of it and Adell and Lupov finally managed to escape from the public function, and to meet in quiet where no one would think of looking for them, in the deserted underground chambers, where portions of the might buried body of Multivac showed. Unattended, idling, sorting data with contented lazy clickings, Multivac, too, had earned its vacation and the boys appreciated that. They had no intention, originally, of disturbing it.
They had brought a bottle with them, and their only concern at the moment was to relax in the company of each other and the bottle.
"It's amazing when you think of it," said Adell. His broad face had lines of weariness in it, and he stirred his drink slowly with a glass rod, watching the cubes of ice slur clumsily about. "All the energy we can possibly ever use for free. Enough energy, if we wanted to draw on it, to melt all Earth into a big drop of impure liquid iron, and still never miss the energy so used. All the energy we could ever use, forever and forever and forever."
Lupov cocked his head sideways. He had a trick of doing that when he wanted to be contrary, and he wanted to be contrary now, partly because he had had to carry the ice and glassware. "Not forever," he said.
"Oh, hell, just about forever. Till the sun runs down, Bert."
"That's not forever."
"All right, then. Billions and billions of years. Twenty billion, maybe. Are you satisfied?"
Lupov put his fingers through his thinning hair as though to reassure himself that some was still left and sipped gently at his own drink. "Twenty billion years isn't forever."
"Well, it will last our time, won't it?"
"So would the coal and uranium."
"All right, but now we can hook up each individual spaceship to the Solar Station, and it can go to Pluto and back a
To summarize the Lucid/FSF fewed that spawned the fork of XEmacs, Lucid was a commercial company, and they wanted features implemented quickly, in time for product ship dates. FSF wanted features implemented right. They forked. There was a lot of miscommunication for a while. When they started communicating again, they couldn't reconcile, because the architectures diverged too much. Both sides thought the other side was wrong on fundamental architectural issues, and both wanted to use their own codebase as the basis for a merge.
I should start off by saying that up until very recently, Emacs has been my main editor. I work on Mac OS X and Linux primarily, and have used Emacs for quite some time. Emacs has worked on OS X for awhile already (either under the Carbon variants that exist, or via X, or via the terminal), so in that regard the article is somewhat misleading.
What I like most about Emacs is that it has the best support for non-mainstream programming languages of any editor, ever. Period. I program in more than a dozen languages (C, C++, Java, Haskell, OCaml, SML, AliceML, Oz, Erlang, Scala, Scheme, Common LISP, Python, Perl, Ruby, APL, etc.), and many of those languages either have no support in other editors, or very poor support if they do. Emacs is the only editor that has at least *decent* support for all of them, and in a way that allows me to maintain a fairly similar style of usage across different languages. In other words, I get to keep my basic functionality and editor customizations relatively the straightforward and things just work pretty well no matter what task I am currently doing. On top of that, extending Emacs functionality to make certain tasks easier is pretty simple, even if you don't know much in the way of elisp. Most of the time, you can simply dig up a snippet of functionality off emacswiki.org. But adding stuff yourself isn't difficult, and the ability to evaluate elisp code inside of emacs itself speeds up the process of writing more complex functionality.
However, it's not all roses. Despite the power of emacs, the reality is that emacs is arcane and outdated as hell. The ugliest manifestations of this arrive in a few different ways:
1) One of them is the ad-hoc way in which emacs is customizable. Emacs basically just runs elisp scripts at run time, and whatever sort of state changing computations that are contained in those scripts reflect themselves in the editor you are eventually presented with. This is a fine idea on a small scale. On a large scale, it's bad. For one thing, it makes extending the editor in specific fashions, with complex features, much more difficult to do in a maintainable way. Essentially, there's little in the way of structure to help maintain conceptual integrity here. It's easy for things to break when you start to combine complex functionality from different pieces of code (usually manifested as modes or something similar) in ways not forseen by their respective authors beforehand. The other end of this, which falls in line with the maintainability problem, is the fact that this approach makes code reuse more difficult. Extensions to the editor in the form of elisp scripts are usually a one-off affair, and are not typically made to be particularly modular. You see the result of this in major-modes which largely accomplish the same tasks, but never share any of the same code. This is common not only in the modes for different programming languages (say they might all support a REPL, but in a slightly different way), but also with modes for other purposes.
2) Unicode support. Emacs is getting much better here in more recent times, but it's far from perfect. Unicode support is difficult to setup on Emacs in a way that is easy to use and works predictably. I have had more experience here on Mac OS X with emacs, so admittedly it's possible that the situation isn't as bad on other platforms. However, true, well integrated Unicode has been late in coming to Emacs because of the legacy of design in the way Emacs has traditionally handled text manipulation and fonts.
3) Display. Emacs text display is starting to show its age. I don't pretend to understand exactly how text display and font handling works in Emacs, but I understand that it is based on legacy designs. Manipulation of the display in text through emacs, with stuff like region highlighting or font locking, is nowhere near as flexible as what is possible in text views for editors in more modern frameworks that follow a design more akin to presentation through styles (
it was on a VAX system...
A goal is a dream with a deadline
...I tried Emacs, but I didn't seem to have enough fingers.
I know Neal Stephenson said something similar in "In the Beginning Was the Command Line"
It is colossal, and yet it only edits straight ASCII text files, which is to say, no fonts, no boldface, no underlining. In other words, the engineer-hours that, in the case of Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text.
Redundancy is good And also good.
I switched from emacs to nedit three years ago, and have not looked back since. I am not a total power user, so while sure emacs has some nice features like understanding c code indentations etc, I found that the lack of user friendly help was too much of a hassle. Nedit's menu simplicity yet fully functional tools (for my needs) were a welcome change from ctrl-x-ctrl-s-ctrl-c etc. And not to overemphasize nedit's understanding of how a mouse click is supposed to interact with text within windows.
Then there are the idiots who insist on still using vi for doing stuff. Forgive me, but I wasn't even able to figure out how to type a sentence in vi until someone told me about colons. What kind of hopeless user interface is that? "Let's make it as challenging and difficult to use as possible -- that'll attract a wide user base!!"
Past with OPENSTEP Future with GNUstep
Windoze not found: (C)heer, (P)arty or (D)ance
Still, version 23 will have a special mode that will let you see the fnords.
"Are you being weird, or sarcastic?" said Emma. I said I didn't know because I get the two feelings mixed up.
"Although its very stable, don't expect to see it released any time shortly because according to RMS, the Emacs developers haven't been fixing bugs quickly enough."
Yeah, it's really too bad they don't work quite as fast as those Hurd guys.
#DeleteChrome
RMS hated Lucid. Really, really hated Lucid. He saw it as a commercial vampire sucking the life out of the MIT AI Lab. Google around and you'll find his essays on the subject.
When Lucid came to him with Emacs changes, it must have been kinda like if Microsoft started submitting multi-megabyte patch sets for the Linux kernel.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
this may sound stupid to the veterans out there, but emacs needs to address look and feel, or at least the cleaning and polising thereof.
:) i'm well beyond taking them for granted.
GTK widget support is great, but the real meat of emacs is the buffer, and the buffer is not GTK, let alone anti-aliased.
if you google something like:
emacs anti-alias fonts
emacs xft
emacs true type
you basically get:
some pages where some brave souls start a branch and attempt xft support
some emacs developers explain that althought the widgets can be gtk, its very hard to make the buffer xft because of emacs' design
it's been in this state for YEARS
also why are the more than one way to color cells in the buffer? i hate when i'm editing using a color scheme and then open up an xml (nxml) file to have it look like garbage.
i could go on for a while with little examples, but my point is emacs needs to shape up in the looks department. someone who was raised on a phosphor green terminal could give a crap, but i was raised with syntax highlighting, AA, true color, multiple windows and i absolutely need them
everyone knows form over function is the way to go, i'll clue you in:
EMACS HAS FUNCTION, ITS OVER, ON WITH THE FORM!
emacs will never die, but it is losing ground in the unix world to things like eclipse, jedit and other editors that at least attempt to put on some makeup before going out the door.
until then i guess its just "xterm -e 'emacs -nw'" for me, (with a nicely fonted/colored xterm)
I remember vividly the times when we used to say "Eight Megabytes And Constant Swapping".
Now, with a bit more than 8 MB RAM at my hands, this is the past. But still there is a certain difference in size when you compare "e3" or even the full graphical editor "nedit" to emacs or vim.
I wonder where all the code goes...
Your biggest problem seems to be that you are using Windows
Seems to be a pretty good platform for developing windows applications. What happens under X then? Does it suddenly become consistent with whatever environment I'm using?
-nt-
~HTP~ Hug that tux
I usually use -nw so i don't care about the menus. You can still get gnome to use emacs keybindings so that's fairly standard.
When it said that Emacs was going to have support for Mac OS X and Cygwin, I thought that they were going to integrate Mac OS X and Cygwin into Emacs. It made sense at first, but I read it a second time and realized that the project was not as ambitious as I thought it was.
If you don't care enough to make a choice, then any of them will work for you, pick one at random.
I am trolling
If you know enough to mention them in Xemacs you should know enough that they are in GNU emacs CVS since the beginning of the year. Buggy.. yes.. but there.
I can't believe you've used Emacs enough to "earn" a year off due to disability, but you never took the time to learn how to use the editor properly.
I have been using XEmacs 19.14 exclusively for a VERY long time (Let's see... apparently, it was built in September 1996....). I don't think I've *ever* touched the meta key in that entire time.
Hint: tapping esc is equivalent to holding meta.
Hint II: The control key belongs beside the A. If you have a fucked up keyboard that puts it somewhere else (like below the shift key), remap your goddamned keyboard.
Hint III: The esc key belongs beside the 1. If you have a fucked up keyboard that puts it somewhere else (like off by itself to the left of the F1 key), remap your goddamned keyboard.
So, to re-indent code: meta control q translates in to:
- tap esc with ring finger (requires a slight hand stretch; F finger stays where it belongs)
- hold control with pinky (moves only a fraction of an inch)
- tap q with with ring finger (natural position)
I can't believe you got a year off work and not even an hour of EMACS remedial physio.
Do daemons dream of electric sleep()?
Vi? I have never seen anybody spell vi E-M-A-C-S, I always thought it was just V-I? Boy, Im confused now...
BreastPad!
You'd rather be stuck with one lame editor than have a choice of two great ones?
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
In particular:
I know that seems to be begging for flames, but it's really not. I'm honestly curious whether I'm better off where I am, if it'd be worthwhile to switch, or if it even matters at all. Yes, I know there are webpages that discuss this, but that's not nearly as interesting as talking about it with other users.
Dewey, what part of this looks like authorities should be involved?
If it still has so many bugs, then how is it considered "very stable?"
I for one like emacs because it works very well over ssh and and has nice split screen functionality (C-x 2 to split horizontally, C-x 3 to split vertically, C-x o to navigate between). This is very useful for being able to look at your API (.h files) and your code simultaneously.
Also, you can do a great many things in emacs without learning anything more than C-x C-c. As you desire more from emacs (maybe a keyboard shortcut for an action you perform often, highlighting for your programming language, changing the way it indents code: M-x c-set-style, a personal fav), you can do a search for whatever you need and implement it as you choose. Opening emacs for the first time is far less intimidating that opening vi for the first time and just seeing those ~'s. And just so you know where I'm coming from, these days, I generally use vi(m) mostly for lightweight editing of config files and small text files, but emacs for any serious coding.
That is an easy one. The notion of entropy is just our disbalanced point of view, so, given time long enaugh for a given number of elements in a system, you ought to see entropy reversal, eventually. Entropy rise is a reversed bathtub curve, which has one end clearly visible NOW, but other, falling end is beyond our most far reaching predictions of universe's lifetime.
I've used vi for twenty.
First, I can use Emacs without taking my hands from the keyboard, ever. I can compile, debug, run a shell - you name it, I can do it without having to reach for the mouse.
Ditto for vi.
Second, it is customizable in the extreme. Everything from key bindings to highlighting is driven by Elisp and regular expressions. Don't like the way something works? You can quickly and easily change it by rebinding a lisp function; most importantly, you can make these mods on the fly, without having to run a separate compile step, without having to restart the editor.
Try vim.
What I'd like to see is an editor that combines the best of Emacs and Eclipse. You'd never have to take your hands from the keyboard. You'd get the attractive UI of Eclipse without the Visual envy. You'd get an editor that makes you more productive and happy than any other.
Try gVIM.
Nothing for 6-digit uids?
I have been using emacs for just under 20 years, mostly GNU emacs.
The last good release was 19.34b. Unfortunately, that release has not been buildable on Linux for many years.
Every release after 19.34b has been compromised by dumb changes to the default emacs behavior. I seriously question the judgement of the developers who have made those changes *the default*. I agree with improving emacs but not in making so many changes to the default behavior with no reasonably easy way to revert.
Bring back 19.34b!
Anyone know how to get current emacs to appear and behave like that version?
emacs VHDL mode is a work of (mostly) genius. Yes, there are a handful of language features not handled properly by the indent engine, but basically, every other editor just sucks eggs compared with emacs when doing VHDL.
>> Slashdot: The place where old computer jokes go to die.
Well only if you insist.
You know what the acronym emacs stands for?
That's right
Escape
Meta
Alt
Control
Shift
It has been statistically shown that helmets increase the risk of head injury.
That's classic!
Version 22 will reportedly also include the kitchen sink!
mouse wheel support?
Welcome to 1995.
Welcome? I'm still there!
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Heres how you can go about getting it yourself:
export CVS_RSH=ssh
cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/emacs co emacs
cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/emacs up -Pd -r XFT_JHD_BRANCH
cd emacs
make bootstrap
(Wait 19,000 years.)
make
make install
My photolog
When you can write a device driver or any real time system that has to
talk to the metal in LISP then get back to us. In the meantime go
and play with your LISP fiends in the nice cosy high level language
playpen and leave the real coding to people who arn't frightened of memory
addresses and interrupts and the like.
Do daemons dream of electric sleep()?
you have to add a lisp hook in your .emacs to do it. and even then it's a little weird about it.
I don't mean to troll, but vi rocks, particularly gVim 6.4 on Windows. Far better than emacs in my humble opinion
You just got troll'd!
flame on!
Eclipse is great when I want to be productive. When I'm using eclipse, I have to close my mail client and my web browser and all the myriad of other distracting applications. The bloat(understatement) is a feature not a bug.
It has been statistically shown that helmets increase the risk of head injury.
Analogies don't equal equalities, they are merely somewhat analogous.
Kids, to help save your hands, remember that when doing a command like M-q (or even when typing an uppercase letter), hold down the modifier key with one hand and hit the letter with the other hand. IOW, for M-q, hold down the alt key on the right with your right hand, and hit the q with your left hand. This stops a lot of weird twisting of your wrist that is bad news.
I used to have emacs but went to a doctor, he gave me a shot and I'm cured now.
It integrates well with the (built-in) Perl debugger and provides a decent UI for it. And it's free. And I can use it anywhere. Which goes to your UI guideline thing, how can a program be "more compliant with UI guidelines" and be cross platform. Heck, what ARE the Linux UI guidelines?
One of the statements of the X (X Windows) project is "possibility, not policy".
Anyway, there you go. Maybe I should give Eclipse a try though.
http://lkml.org/lkml/2005/8/20/95
Tell me again when I can use emacs to play Global Thermonuclear War.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
> which is to say, no fonts, no boldface, no underlining
as a matter of fact, Emacs does fonts and such, and can even embed images in the text.... but it is not something that the user can mess around with (and if you ever saw a document written by a MSWord newbie, you know what "messing around with styles" means); styles are used for syntax highlighting or web browsing (try the latest AuxTeX for example). This is different concept than other w.p. and I happen to like it more.
C programmers (as opposed to programmers who happen to write C) seem to be under the strange and baseless impression that it's the fastest language out there, and thus the only option for low-level programming. In reality, several languages are faster in many key respects, and many are vastly safer. Given two languages of roughly equal running speeds, I'll take the one that makes my code less susceptible to stupid bugs any time.
Dewey, what part of this looks like authorities should be involved?
Which enviroments guidelines should it follow? Rember that Emacs is not only cross platform, but also predates all modern GUIs.
Windows, KDE, Gnome and Apple. No reason not to have some sort of configuration options to handle the (actually quite minor) differences between them. The latest version was created at a time when modern GUIs were pretty well established.
Then there's the super-powerful search and replace. Want to add a blank line after each paragraph? Surround every line with double quotes? Capitalize all vowels? Place a dollar sign in front of every number in your document unless it's at the end of a sentence? Interactive search-and-replace within all documents in a folder and all subfolders in one shot? No problem.
M-x viper
Eclipse plugins are a pain to write. Eclipse is way to abstract and high level, one needs to write about 10 classes to make a certain word a different colour in an editor. It does not make the life of a plugin writer easier.
From my perspective as an end-user, Unicode and bidirectionality support are the most glaring omissions of both Emacs and XEmacs. Mule development has moved slower than a mule's pace and, frankly, I'm tired of waiting. I think that, by the eve of 2006, there is little excuse for not getting these things done or putting them high on the priority list. Along with CJK and LGC (latin, greek, and cyrillic, Arabic script is one of the three most important script systems in use and in importance.
To be fair, there is only one product at all of which I am aware that gets these three issues right, SCUnipad
http://www.unipad.org/
In particular, its Arabic-script handling (including diacritics) is second to none. But it's not open source, development seems to have stalled (sigh), and it has few basic and no advanced features for coders aside from excellent unicode utilities. If any (X)Emacs developers are reading, I hope they will take a look at Unipad and consider implementing some of its features. I will be happy to consult on Arabic-script issues.
"mouse wheel support"
I'm a tri-platform user (XP SP1, OS X Panther, Gentoo) and this is something I come across very often when I'm working in Gentoo: stuff I take for granted in Windows and Mac OS either isn't supported or is difficult to set up in Gentoo. I know that proprietary bullshit often stands in the way of open source developers, but aren't things like mouse wheels--and quite frankly, mice in general--fairly generic and easy to support by now?
Don't get me wrong, I wouldn't use Linux if it was a useless platform. However, I don't think that, in 2005, mouse wheel support being a new feature speaks very well for the developer nor very well for the open source development model as a whole.
Comments, constructive criticisms welcome.
Okay, this is off-topic here, but it's a genuine question: why is it supposedly so much better to have the control key to the left of the A key?
This may be a naive question, but it doesn't come from lack of experience; I've been using computers since 1977 and certainly have used my share of keyboards that have the control key in its original placement. The thing is, if you're used to touch typing, the reason that we have two shift keys is because we use the one opposite the key we're shifting, and strike the letter key with the same finger we normally would. Capital A is struck with the right shift key, capital I with the left. Given that control and alt/meta are, in effect, also shift keys, isn't it logical to approach them the same way? I know that I use the Emacs-ish ^A, ^E and ^D fairly frequently, and all of these are easier for me to type being able to hit the right control and type normally. If control is where caps lock is, ^A and ^Z are fairly awkward to type.
So, really, why is the left of the A key such an exalted position for the control key? Is there really any testing that's been done to show that this position increases typing speed or accuracy, reduces stress, etc., or is it just the weight of tradition that makes people "know" that's the "correct" placement?
As for history, I started using EMACS in 1979 at about version 134, when it was written in TECO on DEC PDP-10s. When RMS stopped maintaining it to move on to the GNU project he had just started, I took over its maintance for a year or so. One of the things I added in 1981 was M-$ (which I called "correct word spelling") and m-x check buffer spelling (which is a much better name than the present m-x spell-buffer).
If you use XML you should try James Clark's NXML Mode which uses Relax NG schemas. It gives you on-the-fly validation and completion when editing XML. Relax NG is very easy to use, especially in its Compact RNC form, which looks a lot like BNF but is isomorphic to the XML representation of the RNG Schema.
At work, I find it easy to develop Emacs-lisp scripts or even simply keyboard macros to do large refactoring jobs in Emacs. I often find that I'm the only person who can accomplish tasks that cut across programming language boundaries.
I used Emacs for several years to take real-time minutes for various W3C working groups, and made great use of the dabbrev-expand function (which I bound to meta-space). I like to think of it as an approximation to a Hidden Markov Model. In fact, at a Face-to-Face meeting in Cambridge, MA, I was able to type an entire sentence that the person sitting next to me spoke by typing only Meta-Space (and judiciously using only one or two letters to redirect the completions), a feat that lead many to believe that some form of magic was involved...Thereafter when others asked how our group had such complete minutes, people always responded, "Oh, he uses Emacs."
Why on earth anyone would choose to use editors like Emacs and vi in this day and age is beyond my comprehension. The only thing I can figure is that some people must get their jollies being contrary, eccentric, cryptic little freaks. I love using UltraEdit in Windows, and don't mind pico or Kate when using Linux. The only positive thing I can say about Emacs is at least it has a built-in interpreter (Lisp, the last time I checked).
The question is, is the editor as good as vim? is the irc client as good as irssi? is the mail client as good as mutt? is the news and rss readers as good as whatever? (never used news and i don't know if there are any other rss readers for the console, i would guess there is.)
If you run it all inside a screen with many windows it's quite conventient to.
Which Mail/Newsreader is better than Gnus? Which LaTeX-Editor is better than Emacs with enabled AUCTeX, RefTeX and preview-latex?
I have a multitasking OS.I agree, this is an issue, although a minor one for me. It is quite seldom that my XEmacs is blocked so I can't use it for something different. But you can always open a second XEmacs to do something else.
What I want is folding, syntax completion, and parenthesis matching that works in both directions.I think Emacs 22 has generic folding support. For syntax completion there are several possibilities, but if you want IntelliSense, google for CEDET.
I have yet to see a parenthesis matching that is better than what you get with (setq paren-sexp-mode 't)
(setq paren-display-message 'only)
(paren-activate)
and in viper-mode you get the nifty %.
UnNetHack: NetHack Improved!
What the Emacs writers should consider is that a large proportion of people who try to use Emacs come
from the PC world and expect the keyboard to be set up a certain way, e.g. the Del key deletes forward,
Backspace deletes backward, Ctrl-arrow moves you one word to the left or right, and so on. Nobody
really cares what keyboard layout five people at MIT preferred forty years ago. It should be easy for
the typical user to remap the keyboard to his liking without having to learn an obscure programming
language. Moreover, there should be a way to lock the keyboard mappings down so that no mode can come along and change them. Few things are as aggravating as going to a great deal of trouble to get the
Del key to delete forward and then having it revert to its old behavior when you edit a new type of file just because some damned mode overrode your settings. It should be obvious that having the behavior of keys change without warning makes a program difficult and infuriating to use. In this way, modes are much like many "features" of Microsoft programs -- they force unwanted help on you that does more harm than good.
It would be useful (and wouldn't be difficult) for the Emacs group to ship Emacs with a pc.el file
that sets up the keys for those familiar with the standard PC conventions and keeps modes from switching the keyboard layout.
Frankly, I get so irritated with keyboard problems in Emacs that I would dump it in a second if I could find something simpler (without so many useless "features") that just did exactly what I told it
to and didn't have other stupid design flaws, such as vi's damnable insert and edit modes. I only wish I had a Linux version of good, old PC-Write. I'm about ready to say to hell with it all and write my own editor.
a) move your left pinkie to caps lock (now remapped to be ctrl) and
b) move either of your pinkies to the bottom left or right ctrl keys.
Using caps lock as ctrl: No movement of the wrist (not even of the position of your palms resting beneath the alt/alt gr keys).
The CAPS->Ctrl is Civilization
I'm not going to switch to a new OS until it has a decent web browser.
that would only result in mouse-whe.elc. and if you ever had to scrub barnacles off a boat, you'll know why I don't want whelks on my mouse.
-I like my women like I like my tea: green-
You mean that useless POS that doesn't support syntax highlighting, doesn't support UNIX or Mach formatted files, doesn't support auto-indentation, lacks spell check, lacks regular expression support, and has no features for accessibility?
Operating system support of a device has nothing to do with how an application handles that device. Also, Windows 95 introduced mouse support.
XEmacs CVS now has XFT support (yay, anti-aliased fonts everwhere!), and an incremental GC, so no more pauses.
I used to use regular emacs, but with no pause times scrolling around and super-clear fonts, i now use xemacs.
RMS must be spinning in his chair.
postings, so let me add my 2 cents. I use LaTeX on a regular basis and was looking for good TeX file editor, regardless of the platform. Found quite a few written for Windows, but every one of them had some problems, mostly with parsing the file for the proper syntax highlighting. The one with the least problems --- and that's what I've been using for over a year and love it is AUCTEX which is written in LISP and fully integrated into Emacs. AUCTEX has a large following in LaTeX community, so count them as Emacs users.
> At least I've got a nice selection with just a basic Linux install.
I think that's called "bloatware". Why install loads of programs people will never use? Just put on one basic editor that anyone can use - and then if users want a different one, let them install it themselves.
You can tell things are bad when an operating system needs more than one CD to install. Hopefully Windows will never get like this and come with loads of different programs you don't actually want and take 2 hours to install.
The point to remember with emacs is that when a user starts a sentence with "emacs lacks..." what they usually mean is "I haven't found..."
Today's tip:
^h h - how to say hello in many different languages.
Intron: the portion of DNA which expresses nothing useful.
Emacs does not actually belong to the UNIX family tree. It belongs to the "MIT hacker" family tree, along with dead OS's like ITS and the Lisp machines. Emacs itself was originally developed on top of the ITS TECO editor; versions were written for the Lisp machines by other AI Lab hackers. The emphasis of text editing in the AI Lab culture was on "ultimate support for the programmer." E.g., Meta-period to immediately take you to the location where something was defined, "compile this S-expression", "navigate to the next S-expression."
Of course, since RMS was an MIT hacker, Emacs was a requirement for the GNU system. That he chose UNIX as the OS foundation of the GNU system was something of an historical accident.
"True" UNIX text editing basically boils down to ed (the standard text editor!) and the vi visual front end, with the *roff macro packages to support typesetting.
Wikipedia has much more detail on Emacs's historical development.
I use it, because even with a simple telnet login I have all editing features available. Even syntax highlighting works. Just great.
Obviously, if you want optimization you'd use Fortran! :)
If its stupid but it works, its not stupid.
...to thank him for the tip.
What does it matter when the latest version was created--existing users would have to learn their editor again (and some bits again when switching environments), GNOME even has the option to use some Emacs bindings... Either way when people spend much time in one application its not that important to follow the interface guidelines, because such apps tend to be task specific environments of their own. Does Maya follow interface guidelines to the letter?
Analogies don't equal equalities, they are merely somewhat analogous.
All your RAM are belong to us!
Your ctrl-shift-meta-alt key are on the way to destruction!
You have no chance to type make your save.
Ha Ha Ha.
I agree completely; however,
1) many hackers learned to type control keys before the right-hand control key was common, or on platforms where it did not exist.
2) even today, right-hand control keys are not universally available or consistently placed.
3) lots of hackers have not had ergonomically sound typing instruction.
The result is that Control-X is typically typed with the pinkie of the left hand holding control, and some other finger on the left hand pressing the x key. Placing control to the left of the home row lessens the twisting involved in this motion.
(I've been thinking about this recently; Lisp machines actually had lower-left and lower-right control keys, and a rubout (delete) key to the left of A. Which makes me wonder how the original Emacs users learned to type control sequences. I'm toying with the idea of using foot pedals to do control/shift/meta, but would be worried about becoming "that nut who carries his footpedals around from computer to computer.")
Why not turn away from beating off over your lunix cluster (some shit pulled out of a dumpster) and your sex romp anime for paedophile shutins and actually contribute to emacs?
No, no that's too hard, better to make VI jokes and say "Eight Megs and Still Swapping" aha aha a ah a what a funny joke!
Oh what's this? an ancient-as-sand archived email thread explaning emacs and xemacs? OLD WOUNDS REOPENED!!!o horror!
no body cares except you nerds. nooooo body cares
(and yet you claim to be persecuted for your intelligence ha a ah)
> But seriously, for you, to edit under Linux I'd suggest just running "wine notepad". You'll be all set with your familiar app, and you won't have to worry about having to evaluate anything new.
ugh. evim or scite would be a much better recommendation.
Alright, pray tell which ones ?
On the flawed but amusing computer language shootout page the fastest language is plain straight C, followed by SmartEiffel, which actually translates to C, followed by MLton which also translates to C, followed by D which may or may not have its own compiler, I'm not sure.
Anyway, on that particular benchmark suite, C is the champ, no doubt. Then there is the small matter of actual professional benchmarks, like SPEC, which are all in C.
C is very fast because it has hardly any feature over straight assembly. In some particular case it may turn out that missing features such at a good GC might in fact improve performance, but guess what, you can implement those in C. In fact all the languages listed above are, strangely enough, written in C.
In the meantime what you comment as being "strange and baseless" is in fact rather firmly rooted in fact.
Let's hear something different now, I'm listening. Is there a language that can do better than C in a wide series of situations ?
On the other hand, as easy as it would be to make a package to address those changes, no one has bothered to do so. Translation: there seems to be very little interest in coercing Emacs to meet someone else's guidelines.
Dewey, what part of this looks like authorities should be involved?
The mail client, Gnus, is far and away the best mail and news reader I've ever used on any platform. I've migrated to KMail over the last couple of years, but only because it was so integrated with the rest of the KDE desktop, and not because it was particularly better than Gnus in any real way.
Dewey, what part of this looks like authorities should be involved?
The original Emacs user did not run it on a Lisp machine.
Will this release fix the strange unlogical keystrokes involving the meta key bug?
http://saveie6.com/
The Knight keyboard had META, CTRL, and RUB OUT keys in the same relative positions.
Normally you hold down one or the other or both with your left hand and type the key to be shifted with your right index finger.
Yes, but that doesn't really relate to the issue. SPEC is a relative measurement; if it where written in Visual Basic, then MachineA[SPEC-VB]:MachineB[SPEC-VB] would probably be similar to MachineA[SPEC-C]:MachineB[SPEC-C].
Is there a language that can do better than C in a wide series of situations ?
Yes: Fortran. No, I'm not going to advocate it for general programming use (although it can and has been used as a general purpose language). However, it wins hugely over C because its data structures lend themselves to easy parallelization, instead of requiring a huge amount of guesswork and pray-this-works.
If you can formally prove that "A" and "B" do not depend on each other as per the language definition, then you can schedule the two to run inside different processes without fear of unforeseen side effects. On single-CPU systems, that's not much of a big deal. On huge NUMA machines, that's critically important. Ever notice that pretty much all HPC programs are written in Fortran variants? That's why.
Dewey, what part of this looks like authorities should be involved?
Seems I was funny in an unintentional way. Thanks for your gracious corrections.
:)
Obviously, there is a reason I call myself NerdPOSEUR.
The original context (in parent's own post) was "why use a slow language like C for kernel development". Granted that Fortran is better suited to parallelization and therefore faster for things like numerical computation with multiple processors, since when is this relevant to kernel development? Indeed, the very limitations on pointers in Fortran that make it more easily parallelizable should make it unsuitable for kernel code.
Emacs itself calls other lisps "inferior lisp", however, emacs lisp is the inferior and outdated one (bignums or lexical scope anyone?). So if you want to blame someone for that moniker, blame emacs authors. (RMS?)
And emacs is really outdated in some aspects by today standards. Having to hit Alt-p to go to the previous line in the historial in a REPL? And if I edit the line emacs forgets completely where I was in said historial. Why don't use the arrow keys and behave like the shell (wich was written in C!) ? That sea of Ctrl, alt, sorry, meta, and shift keys is really a nightmare.
It's true that using the keyboard is sometimes faster than other methods, but in emacs case, the costs outweight the benefits. Try using emacs over SSH (no useful mouse, sorry) to feel the hell that it is. And the mouse can be used way faster than the keyboard, just use Opera to see how.
Using several files open at the same time should be like in Edit-plus. Not buffers non-sense. And slime should be able to connect to lisps all over the internet, not reading the port from a local file (that's quite a HACK!)
We have good things in emacs. We have good things in Visual-(insert your IDE here). We have good things in pure text oriented editors that beat the hell out of the former ones in some things (I love Editplus). But there is no single solution that covers all needs, and really, it could be, is not that hard. And the current emacs effort is absolutely not help in this regard.
We are Turing O-Machines. The Oracle is out there.
...He can damn well roll up his sleeves and hammer out some code himself.
Otherwise, like any other critic of OSS developers who doesn't actually do any of the development, he can damn well STFU.
Is Capitalism Good for the Poor?
But I've been doing rectangular edits for years in Editplus.
We are Turing O-Machines. The Oracle is out there.
...is the one that automatically fixes all the bugs in your program. I just can't remember the key combination!
Well, that's true. But that's not a good thing either. I want applications to work for me. I don't want to do things their way. That's a 1960's way of looking at things.
I hate those little Emacs. As far as I'm concerned they ruined Return of the Jedi.
The whole thing seems a little odd to me - people mostly brag about how quickly they can work in emacs/vi. When I'm programming the editor is pretty much trivial due to the fact that I spend 90% of my time thinking rather than typing anything. Give me decent syntax highlighting for whatever language I'm working in and I'm happy. What's the big deal?
The thing which always frustrates me the most when trying to use anything other than *macs is the lack of a proper template facility. Yes, I know that Visual Studio and Eclipse have template facilities built-in, but they seem pretty primitive (IIRC, straight keyword substitution only). This is hardly sufficient. Efficient templates combine static text with logic to expand and aggregate that text in the most appropriate and efficient way. To wit:
- Prompted verbatim fill text;
- Prompted parsed fill text;
- Prompted option lists (restricts fill text to known values);
- Automated fill text;
- Automated/conditional inclusion of sub-templates;
- Manipulation of the point;
- Manipulation of the region (selection).
As an example, my method template takes the fully-qualified name of the method (e.g., "Class.NestedClass.method"), parses the various chunks of the name, and fills various fields in the header comment and function body with those parts. It prompts for the argument list, nicely filling it one argument per line, and sets the point just inside the function. If the region is active, it drops that inside the function template as well.
When an IDE can do this, I'll consider using it. To be fair, *macs isn't much better "out of the box," but at least it was pretty easy to implement a proper template manager.
So, can Eclipse do this (seriously, I want to know)?
Can one use EMACS for script writing and its related formatting style? If so, what extra plug-ins or similar do i wish to look for?
"There is always some madness in love. But there is also always some reason in madness."- Friedrich Nietzsche
mouse wheel support? drag and drop? Welcome to the '90s, Emacs.
"neither; I'm a more of a java guy myself"
In what could only be described as arrogance on your part, you actually betrayed your ignorance.
Just so you know, I use both vi and emacs, depending on the nature, size, time, and effort required for the job. For a simple and quick edit, I'd likely use vi. For constant development (Java work included), more likely emacs.
And, just in case you were unaware, emacs would likely excel over any other contraption you can dream up in its ability to handle any text-based language you will come across.
Certainly, Lisp is a better language than Java, in theory. But take a look at the actual Emacs Lisp you're comparing to Java. The Lisp in Emacs is a yucky old loosely nailed together plywood treehouse Erzatz Lisp, with "buffer scoping" thrown in, which makes it totally unlike any standard Lisp implementation, plus it has no native code extension API (plugins or DLL modules). No other Lisp but Emacs Erzatz Lisp stores variables bindings in buffers, such that when you switch buffers, your variable bindings change!
Gnu Emacs wasn't the first Emacs to use a mutant Erzatz Lisp. At least Gnu Emacs Erzatz Lisp was an improvement over Gosling Emacs "MockLisp" (UniPress Emacs). MockLisp resembles Lisp only in the worst possible way (same annoyingly pesky parenthetical syntax, but none of the solid well designed semantics).
MockLisp actually used an ill-conceived form of lazy evaluation, which is lethal when foolishly combined with dynamic scoping (no closures). When you called a MockLisp function, the parameters were't evaluated until the called function decided to fetch the argument with the (arg name prompt) function (which also would prompt the user for the argument if it was missing).
The horrible problem with MockLisp was that the (arg) fetching function evaluated the CALLER's parameter expression in the CALLEE's dynamic scope! Bzzzt! Argument expressions could be passed deep down from function to function, so you had no way of knowing what context any of your arguments would be evaluated in. So thanks to dynamic scoping, you actually had to name ALL of your local variables uniquely across the entire MockLisp program (which causes problems when integrating packages written by different people). The convention was to use a unique prefix for all arguments of each function, cross your fingers, and for God's sake don't get recursive.
MockLisp was so un-lisp-like that it didn't even have basic data types like dictionaries. This MockLisp code (a hypermedia browser authoring tool for HyperTIES) implemented a master index to look up article titles and synonyms, and it had to represent a dictionary as a buffer, and abuse buffer local keyboard abbreviation tables (which were fast because they were implemetned in C) to look up names.
It's astounding how disasterously designed MockLisp was, yet Gnu Emacs Erzatz Lisp still copied some of its ill-conceived ideas like buffer scoping. Emacs implemented with a real Lisp programming language would simply represent buffers as regular data types, and provide sane variable scoping (i.e. an object oriented programming system like CLOS) so that there was no need for "buffer scoping" built into the language. There's nothing so special about buffers that they deserve to be built into the programming language's scoping rules.
MockLisp is to Lisp as JavaScript is to Java. They're both badly designed programming languages that ripped off the names of better designed programming languages, to fool people into believing they didn't suck.
-Don
Take a look and feel free: http://www.PieMenu.com
I have downloaded the CVS for Emacs 22 and have built nice RPMs for Fedora Core 4. You will find them on my home computer.
The whole point of using C for benchmarks like SPEC is to remove the influence of any and all VM, interpreters and the like. It is as close to programming on the bare metal as reasonably possible these days.
Now FORTRAN is indeed used a great deal on supercomputers and is easier to optimize aggressively, this is true, but I've yet to see a modern O/S written in FORTRAN, although I have little doubt that this is possible. I'm sure you could link FORTRAN code into the Linux kernel, but I doubt it would be accepted in the main tree...
Now on the FORTRAN vs. C question if you read the classic "real programmers don't eat quiche" it seems that although the author doesn't think much about Unix he says good things about C. That ought to settle the debate ?
If not C99 is easier to parallelize than C89, and some swear C++ can match or exceed FORTRAN.
We had to use a pair of single-pole, single-throw knife switches to input the bits. And they'd electrocute you sometimes. And you'd die and still have to get the code finished by 6pm.
You tell kids that today...they won't believe you!
"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
Come on, you know it's true.
A blog about stuff.
Yes indeed this supprised me. Even the long standing UNIX competition (VIM) got most of those features allready - including the GTK+ widgets. In fact: you can get qt widgets for VIM as well.
But then EMACS is more an IDE then an editor anyway.
Martin
Turn on a light in that basement. There are no meta keys. They are dinosaurs. Can you move forward with confusing instructions that will lose a newbie in less than 60 seconds? Other editors are easier to master and their documentation does not give you three choices for one key's use.
Java is an inferior language to LISP. It's no wonder that Sun was unable to create hardware-based implementations with any degree of success.
Nevertheless, you were incorrect with regards to your previous statements. Most LISP programmers were developing solutions on what would today be equivalent, hardware-wise, to "embedded systems" before you were even an embryo.
Cyric Zndovzny at your service.
It existed in 21.3 too. And, IIRC, even before that.
> I tend to use other applications to do these tasks. they tend to do a much better job.
.emacs) any bindings they didn't like for any particular mode. The tricky part would be deciding which Emacs-specific functionalities would be most deserving of the few remaining available top-level (i.e., unprefixed) keystrokes, and also where to put the prefix keys that traditionally are ctrl-x and ctrl-c (and maybe also ctrl-h, if it is determined that F1 shouldn't be a prefix but should bring up some kind of (perhaps mode-specific) help directly; these prefix keys would need to be easy to reach on a normal keyboard but not interfere with any industry-standard bindings).
You know, that's funny. *Which* other applications do a better job of reading mail than Gnus? I've tried practically every major mail reader in existence, and I only know of *one* other that even comes *vaguely* close to being *comparable*, in terms of feature-completeness. It's Pegasus Mail, and it's great except for the fact that it only runs on a quite limited range of operating systems. It's not as customizeable as Gnus, but it does have most of the essential features. Nothing else does. I've attempted to use OE, Evolution, Thunderbird, Eudora, Gmail, and assorted others, and they all stack up to Gnus, for the purpose of reading mail, in roughly the same way that Play-Dough stacks up to steel for the purpose for building skyscraper frames. The situation for reading usenet is similar.
I don't know about RSS feeds; they're not something I've ever read on a regular basis, so I won't comment on what's best for reading them.
> What I want is folding, syntax completion, and parenthesis matching that works
> in both directions.
Emacs has had all those things for aeons, of course; I think you knew that, but I'm confused about what point you were trying to make.
> Applications are meant to be consistent.
I actually agree here. I threatened at one point to create an elisp package that systematically rebinds all the Emacs keys in every major mode (that comes with Emacs; add-on modes would not be covered, for obvious reasons) to adhere to all the major conventions that most applications follow, e.g., Ctrl-S for Save, Ctrl-C for Copy, Ctrl-A for select All, Ctrl-Z for undo, Alt-F to pull down the File menu, and so on. I determined that Alt-X (or Meta-X if you actually use something other than Alt as Meta) would not need to change, so it would always remain possible to call functions by name (provided Alt-key combinations remained useable; I think it *would* be necessary to split Esc off from Alt, so people who use Emacs over poor terminal emulation where Alt isn't useable would not want to use this mode; for this reason, and for historical reasons, it should not be the default on most systems, although perhaps it could be the default on Windows). There's no reason this couldn't be done (and, if the Emacs people don't want to include it, distributed separately; I'm sure at least some desktop distributions would pick it up), but when I realized how much work it would be, with all the major modes, I determined that I would never, by myself, be able to complete it. (If nothing else, I would never be able to motivate myself to work on rebinding keys for major modes that I never use.) I tried to interest some other people in the project, but I was unable to convince anyone to work on it with me, so it never happened. I'm still interested, however; if you can find another three or four people who both believe that Emacs should be able to use the same keystrokes as other apps *and* know enough elisp to work on the project, I would be pleased to work with a team of people toward this end.
Such a package would, of course, still allow the user to over-ride (e.g., in
Cut that out, or I will ship you to Norilsk in a box.
sorry, actually, real men don't need to remember files... They just know...
Gravity Sucks