> [Opera] has the best CSS support of any browser, hands down.
Opera has, by the standards of today's browsers, quite *good* CSS support, and possibly the best, but I'm not sure it's "hands down". Opera and Gecko support different large subsets of CSS2 and different small subsets of CSS3. (Non-standard extensions to CSS (e.g., -moz-appearance) are another matter, but those are clearly placed in a namespace that will not interfere with future versions of CSS, and they are not intended for use on the web, but for use in constructing the application itself, or extensions thereof.) Opera may have the better and larger subset (I would estimate that it does), but it's not as far ahead as you make out. One area where Opera clearly does lead is in things that are not very useful for screen display but for other media, e.g., pagination-related things for print. As far as I am aware Opera is the only major browser that has made a serious attempt to implement that particular portion of CSS.
OTOH, the grandparent was an ignoramus or a troll, or both, since clearly Opera has *overwhelmingly* better CSS support than IE will have for some time. Improved CSS support has been promised for the next version of MSIE, but currently that is still only a promise. Opera has CSS2 support worth having *already* (and have had for a couple of years).
First, if at *all* possible, get a partner, someone else who wants to learn the language too and will meet with you weekly to quiz each other and go over the next section of grammar. The extra motivation of being "ready" for your weekly meeting will often give you the extra shove to do the studying when otherwise you might just let it ride for another day or two. Another day or two, and then another day or two, rapidly turns into months and years. Regular deadlines help to prevent this.
Second, harness otherwise wasted time by carrying your vocabulary cards with you at all times. Really, I mean carry a pack of vocab cards everywhere you go. This is easiest to do if the cards are small, business-card size or smaller. If you're on a budget, take 3x5 cards and cut them in thirds, resulting in cards about three inches long/tall by an inch and two thirds across the short way. Write each foreign word on the top of the front, then flip the card end-over-end and write three pieces of information on the back: the meaning(s), the part of speech (if that isn't completely obvious from either the form of the word itself or from the meaning), and either the chapter number you're studying in the grammar when you added this word (if you have one main grammar book; or if you are drawing your vocab words from a vocab list book, use the chapter or page number from that book) or the current date (otherwise). Always carry with you a pack of 15-30 of these cards, mostly ones that you've either recently added or have had trouble remembering. When you have wasted time (standing in line, waiting for someone, or whatever), whip out your cards and go over vocab words for a couple of minutes. Try to get through the pack (15-30 cards) at least once or twice each day. When you are confident that you are getting any given word right most of the time, set it aside from the rest of the pack and rotate it out, adding in another card to replace it. Each week take the ones that you set aside, put a slip on them with the date, and leave them out of your regular review pack for at least a week, maybe two. Then get them back out and go through them just once, sorting them; the ones you get right immediately, set aside for longer (perhaps a month or two, then sort them again the same way); the ones you miss, put back into your regular rotation. I used this system for Greek and Hebrew, and it works well, provided you carry the cards everywhere and look at them when you have odd moments each day. Words you have trouble with naturally spend more time in your pack this way, so they get extra repetition until you eventually learn them. In my experience, short words like pronouns and conjunctions and subordinators will tend to spend a lot of time in your pack whereas most substantial words like nouns and verbs are easier, but YMMV.
Today? Not much. In particular, it doesn't make this version a more compelling download, for an end user. What it does do, however, is pave the way for things to come.
> I would rather put 99% of efforts to improve compatibility with MS Office.
You'd have to pinpoint specific points of incompatibility. At this point, I would have said that support for the Word and Excel formats was good enough, and that instead effort should be put into features, or into support for other popular formats (MS Works, AppleWorks, Word Perfect, MS Publisher,...)
> Isn't it the only reason why 99% of people don't switch to OpenOffice?
In a word, no.
I know of three major reasons why people don't use OpenOffice... The most obvious is lack of familiarity: people don't use what they don't know about. Perhaps more important is lack of bundling: it doesn't come pre-installed on computers. I'm pretty sure compatibility with MS Office isn't a major selling point for WordPad, but yet it continues to be used by more people than OpenOffice. Similarly, MS Works has only very marginal compatibility with Office, much worse than what OpenOffice has, but it's used by a lot more people, because a lot of OEMs bundle it. Third, there's the brand name factor: Microsoft in general and Word in particular is currently the big brand name, so people use it for the same reason they use Ziploc bags, although some competing brands are both better and cheaper.
Perceived incompatibility may be a factor for some people, but it is certainly not the only reason and probably not even the primary reason why people don't switch.
> Plus, a new keyboard shortcut permits the user to return to > a saved cursor position.
Sounds like markers in Emacs, especially the way I have them set up (wherein, hitting the key that I have bound to switch to the last saved position takes note of the current position so that it can be used next time, so that I can easily switch back and forth between two positions; it is, or course, still possible to set as many additional markers as desired).
Now, if OpenOffice will just get grouping-symbol matching like in Emacs, and the ability to split the window and easily look at two positions in the same file at the same time, and a more flexible system for customizing keybindings, and a better system for recording keyboard macros,... maybe eventually we could get to the point where it's easier to type up text in OpenOffice directly than to type it in Emacs, then copy and paste into OO for final formatting.
> I think where Wikipedia would probably beat out Britannica would be on > technology-related articles
Yes, especially in terms of coverage. Wikipedia's math coverage is also pretty good. Actually, coverage tends to be overall better in Wikipedia (well, in the English Wikipedia anyhow). OTOH, Britannica has fewer utter-garbage articles. (I'm not saying WP is loaded with them or anything, but they do appear occasionally; I've seen I think three altogether, out of perhaps a couple of thousand articles I've looked at.) Also Britannica is more consistently formal in its grammar and style, which appeals to me. But Wikipedia is in many ways more convenient; the page layout is substantially more convenient for one thing, and allows the main text of the article to use a much larger percentage of the total window width, which makes it easier to read. It's also a good deal easier to navigate, especially because of the pervasive article-to-article hyperlinking. Then too, the search works better. Furthermore, to access Britannica online, I've got to go through OPLIN and type in a fourteen-digit library card number. This particular wrinkle, aside from the inconvenience, also makes Britannica worthless for hyperlinking purposes, and linking to them is a tremendously useful thing to be able to do with encyclopedia articles. Britannica is *slightly* preferable for traditional formal citations, but at that it's still an encyclopedia, fundamentally a tertiary source.
And yeah, for obvious reasons Wikipedia covers very recent topics better.
I do hope Wikipedia's plans to establish approved "stable" versions of articles turns out well; it seems to me that that's headed in the right direction.
> Whilst I agree with you generally, why did you consider the CLI to be 'a cult'? > And to which CLI do you refer? Bash has its deficiencies and irregular syntax, > but I don't know of anything better. Do you?
For an interactive CLI, there's a lot to be said for eshell.
And for writing "shell" scripts, Perl is an obvious choice.
I use a custom layout, on my main workstation at home. It's not a standardized layout like Dvorak, but one of my own invention. My primary reason for switching to a custom layout is because my pinkies were starting to ache constantly from always being overextended to hit keys like shift and ctrl. My custom layout puts left shift and right ctrl on home positions. While I was at it I fixed other minor aggravations; e.g., I moved the "Windows" key to a position where it's harder to hit by mistake, got rid of CAPSLOCK and numlock (making the keypad always for cursor movement; if I want numbers, I use the number keys), put the letter a where k used to be, and a small handful of other changes. My pinkies don't hurt anymore. YMMV.
And no, switching back and forth between my custom layout on my primary system at home versus standard QWERTY elsewhere is not a problem; my hands can feel the difference between my special keyboard and a regular one. I don't have to think about it; I just type and it comes out right.
This *sounds* insightful, if you haven't tried it. In practice, it is a non-issue. You get mildly confused switching back and forth for the first few weeks, while you're still learning the new layout, but once you get past the initial learning phase this problem goes away entirely. I use a custom layout on my main workstation at home, and standard QWERTY everywhere else. My fingers *know* whether they're sitting on my special keyboard or not; I don't even have to think about it; I just sit down and type.
> That's interesting; what state (country?) do you live in?
Ohio.
> I'm in northern Oregon
Ah, yeah, west coast. Obviously you'd see rather more of them than here.
> That's probably because this is tree-hugger central. There's plenty of trees to hug. > We also have a fair number of pure electric cars and lots of bio-diesel VWs and > whatnot cruising around.
We've got tons of trees, but we coexist with them. Trees are taller than buildings, so from a distance trees are pretty much all you see -- not just in satellite photos, but also looking across a valley or down from a hill or whatever. When you actually *get* there, you discover all the houses and stuff, but from a mile away most Ohio cities look mostly like woods (in the summer; in the winter, of course, you can see through between the branches). The most tree-sparse areas (outside of the relatively small central portions of the dozen or so major cities with skylines) are not the cities but the rural areas, where there are lots of wide open fields.
> We also have a fair number of pure electric cars and lots of bio-diesel VWs and whatnot > cruising around. Of course there's a full-size Hummer for every hybrid I see.
Diesel is _relatively_ common around here, though clearly a small minority compared with gasoline vehicles, and I have no idea whether any of them use biodiesel, as opposed to petroleum-derived diesel. As for Hummers, there's one of those fakey new pseudo-Hummers in Galion (it happens to be bright yellow, so there's no missing it), and we see other instances of that model around too (the other day we were over in Ontario doing some shopping and I happened to see a dark green one), but AFAIK the nearest *actual* Hum-Vee is at the national guard base over in Mansfield. There are plenty of unnecessarily-large SUVs, though, a minivan for every subcompact, and probably the most common auto type is the midsize sedan with a high safety rating that gets deplorable mileage for a car (albeit, still rather better than a minivan, to say nothing of an SUV).
Additionally, there are a lot of those new kind of pickup trucks that started appearing in the nineties, that don't actually look like traditional pickup trucks, insofar as they have bright shiny paint jobs (often in colors that pickup trucks never used to come in, although red is also popular), smooth curves, and would look *completely* out of place parked between a combine and a chicken coop. Also they're about twice the size of traditional pickup trucks, especially in terms of height and cabin space. You know the ones I mean. People drive them who you just know have never worn overalls in their lives.
# Of course, this doesn't mean that our articles are # necessarily better; it depends on the severity of the # problems, whether our extra words are actually useful # information or just verbiage/trivia, etcetera. There's # also the question of when, exactly the articles were # reviewed.
This quote is from the same source as the average article lengths, and it's good to see this admission. It's encouraging that the Wikipedians who did this length comparison acknowledge that length isn't necessarily everything.
On the other hand, Brittanica may be deliberately edited for terseness, to reduce costs of things like printing, shipping, warehousing, and so on. Brevity can be a virtue, but on the other hand it also isn't everything.
> it will still be a while before you see many hybrids out of warranty
I don't know about where you live, but around here the "out of warranty" qualifier is superfluous; I've yet to see hide nor hair of a hybrid car IRL, period. Sure do read about them all the time on slashdot, though.
Oh, great, two additional circulating closed systems, as if the oil and water cooling systems in a normal automobile weren't adequate sources of repair bills. I suppose it also adds a second radiator?
> > practically no downside. > Additional moving parts
My thoughts exactly. The idea is interesting, but roughly twice the number of engine parts for only a 15% performance/efficiency improvement sounds to me like a bad trade.
Not that they shouldn't procede with further research, but I wouldn't suggest taking anything to market in the described state.
> If you already have a decent background in c and at least one scripting language, > say php, you should be good to go.
No PHP, and my C is _very_ marginal. However, I'm fluent in elisp and Inform, think in Perl, used to think in QBasic at one time, and have had some exposure to at least a dozen other programming languages. (By "some exposure" I mean enough to handily ace undergrad courses in the language, but not enough to do anything really serious or useful; my knowledge of Python is probably about this level, although I was doing it self-study, having previously graduated.)
Like I said, maybe you just think Guido's Way. Some of us don't.
No more so than five years ago. Emacs development has always been gradual and conservative. The reason it has so many features is because it's been in development since approximately the late bronze age. Emacs in principle is older than any hardware architecture you can still buy new, and the current implementation dates from 1984. It's *old*. So if development isn't as fast as on some newer projects, don't sweat it. It's not like there's a six-month deadline looming for shipping the next version. My first reaction when I saw the Emacs 22 headline was, "Wow, already?"
> 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.
The friction (if it's even still relevant; I think it is mostly in the past at this point, though of course there will always be a few people who hold grudges forever) is of no concern to me, but I stick with Gnu Emacs because I have significant amounts of custom elisp that I don't want to have to port over. Gnu Emacs is the Emacs that I started out with, so it's what I stick with.
> 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;-)
If you are an Emacs user and have never used eshell, you really should give it a try. The really nifty thing about it is that it's not just a bash substitute; it really tries to do things in an Emacs-oriented way. Also, it doesn't have to implement things like macros and commmand-line editing, because you already have those by virtue of the fact that you're in Emacs. One really cool thing about it is that you can mix and match external system commands with lisp functions.
> As far as all the features being available in just about any other editor, you're dreaming!
No, he just doesn't know what features are. He's thinking of mundane things like copy and paste, syntax highlighting, the ability to save, and so forth -- things that really *are* in many editors, things you so take for granted that you don't even consider them to be features. He isn't familiar enough with Emacs to realize that it has *real* features, i.e., advanced features, features little or nothing else has. Things like navigating by sexp do not even occur to users of most other editors, because they don't even *imagine* that a text editor could have that kind of uncanny power.
> I tend to use other applications to do these tasks. they tend to do a much better job.
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.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).
> I heard with the new version it will make you tea
I don't think you need the new version for that. If you have a network-enabled "coffee maker" that can brew tea, I think all you need is coffee.el (which may even be included in Emacs out of the box these days). Unless I am greatly mistaken, people have been brewing beverages from within Emacs at least since version 20, if not before.
> What's so great about it that people insist on using it rather than any other editor?
Quite a lot of things. First off, it's *WAY* more customizeable. Even highly-customizeable editors like vim think about customizeability in terms of "I want the user to be able to do such-and-such", which is a limited approach. Emacs thinks of custumizeability in terms of "under these circumstances, when such-and-such occurs, what is the ideal thing that should happen?" The result is an editor that can be made to actively do the user's work, with only the least amount of prompting. In fact, the user only really has to be prompted at all when there's some question as to what needs to be done, and the user's guidance is therefore needed. Every editor (worth talking about) has macros, but Emacs has a whole nother level of automating repetitive tasks. For instance, I'm involved in a quizzing program, and I write questions. So I whipped up a quick major mode for it (that I call quizques-mode). So now when I edit my questions, and I type the question mark at the end of a question, the mode automatically goes down and inserts the "A:" and the tab character and is ready for my answer. When I'm typing questions from a particular passage, and I'm putting references in parentheses at the ends of the answers, I don't have to type them all out; I just hit : and the verse number, and the rest (book, chapter, and parentheses) are all filled out for me. (And so on; the mode has perhaps a dozen such features, which collectively save about 25% of the time that would otherwise be spent typing questions.) For Perl programmers, cperl-mode is another example of this sort of thing, but that's more standardized; the real value is not in something standardized (as any editor can include standardized helps for editing something as common as Perl code), but in the ability to add your own customizations for anything you happen to be editing. And, unlike if you edited the C source of something like vim to add such features, your additions will still work, generally with no changes, when you upgrade to the next version of Emacs. (That's quite aside from the fact that whipping up something in elisp is *way* easier and faster than changing the C source of the editor.) I have over the course of several years personally accumulated over half a megabyte of custom elisp that implements my various and sundry personal customizations for Emacs. Collectively, these things save me quite a lot of time, in small increments spread out over each day.
There are also some individual features that are highly addictive. The grouping-symbol matching, for instance, is something I sorely miss when I use other applications, such as Firefox and OpenOffice.org, much less the numerous so-called "text editors" that don't have such essential features. Firefox did finally get (a somewhat broken implementation of) incremental search, which is nice. I notice it doesn't have incremental regular-expression search, though...
The built-in nature of the documentation is exceedingly handy, too. And there are many other things. Most are little things, but there are thousands of them, and they add up.
> I just bought my dad an iMac, and was looking around for an emacs build for it.
It's included. Open Finder, click on Applications in the little sidebar on the left, and look for Terminal. Open that, and type emacs at the shell prompt.
The only thing is, this gives you a console/terminal Emacs, so there are no toolbars or scrollbars, and all dialog takes place in the minibuffer, and the menubars by default are not visible unless you invoke them. Also, you're limited to a few colors (16 IIRC), and graphics cannot be displayed. If you want a GUI-enabled version of Emacs, I think you have to download and install the X server from Apple. (Whether the out-of-the-box Emacs will automagically work with X if started from within X, I'm not sure (never tried, and I no longer have regular access to an OS X system); if not, ask again and specify that you want an X11-enabled Emacs for Mac OS X, preferably in an apple.slashdot.org story relates to either X11 or Emacs.)
> Wait, so I can use my Emacs operating system on top my Windows operating system?
Emacs has run directly on Windows (without need for Cygwin) for aeons, at least since Emacs 19, probably before. Through version 20 that release was called NTEmacs, but from 21.0 forward it's no longer really distinct from Emacs on any other platform, except that the variable window-system might be set to a different value, and it might use a different widget set. (Speaking of which, I'm glad to hear version 22 is moving to a decent, modern widget set for X11-based platforms. I don't care precisely *which* decent, modern widget set it uses; Qt for instance would have been fine with me; GTK is also fine; wx would also have been fine, or XUL, or whatever OpenOffice uses... really, any decent, modern widget set would be fine... but Xaw is just absolutely terrible, and I hope to never see one of its thrice-becursed sliderless use-the-right-button-to-scroll-the-other-direction scrollbars again -- not that I very often use the mouse to move around in a text editor anyway, but it's the principle of the thing.)
Emacs also has run just fine on Cygwin for quite some while.
> 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
I think for that we really need to wait for multitasking features in Emacs (and relevant lisp functions, such as lazy-eval and fork), and for significant improvements in the C-to-elisp compiler, so that we can get various needed desktop software running in Emacs. For instance, if you were running Emacs on the bare metal, currently, and you needed to do some photo editing, you'd be up a creek without a ladder, because there's no Gimp port currently for Emacs, nor anything really comparable in terms of native applications. In practice, virtually all Emacs users rely on at least a limited number of external, non-Emacs applications for one thing or another. This needs to change before a bare-metal version of Emacs will be very much practical use.
I was hoping the multitasking stuff would make it into Emacs 22, but I don't see it on the list, so maybe for Emacs 23, hopefully.
Also, before a bare-metal Emacs would be practical, filesystems would need to be implemented; that could be done *mostly* in lisp, I think, but there would have to be some C hooks put in for it, I think, and additionally the code that currently uses the external filesystem would have to be modified to be able to use whatever native Emacs filesystem implementations are available. Also, if Emacs has its own TCP/IP stack, I am not aware of it, so that would be needed -- oh, and also hardware drivers. In short, it's a lot of work, and I don't think we'll see a usable-in-practice bare-metal version before Emacs 25 at the earliest.
Slashdot Mirror
> [Opera] has the best CSS support of any browser, hands down.
Opera has, by the standards of today's browsers, quite *good* CSS support, and possibly the best, but I'm not sure it's "hands down". Opera and Gecko support different large subsets of CSS2 and different small subsets of CSS3. (Non-standard extensions to CSS (e.g., -moz-appearance) are another matter, but those are clearly placed in a namespace that will not interfere with future versions of CSS, and they are not intended for use on the web, but for use in constructing the application itself, or extensions thereof.) Opera may have the better and larger subset (I would estimate that it does), but it's not as far ahead as you make out. One area where Opera clearly does lead is in things that are not very useful for screen display but for other media, e.g., pagination-related things for print. As far as I am aware Opera is the only major browser that has made a serious attempt to implement that particular portion of CSS.
OTOH, the grandparent was an ignoramus or a troll, or both, since clearly Opera has *overwhelmingly* better CSS support than IE will have for some time. Improved CSS support has been promised for the next version of MSIE, but currently that is still only a promise. Opera has CSS2 support worth having *already* (and have had for a couple of years).
First, if at *all* possible, get a partner, someone else who wants to learn the language too and will meet with you weekly to quiz each other and go over the next section of grammar. The extra motivation of being "ready" for your weekly meeting will often give you the extra shove to do the studying when otherwise you might just let it ride for another day or two. Another day or two, and then another day or two, rapidly turns into months and years. Regular deadlines help to prevent this.
Second, harness otherwise wasted time by carrying your vocabulary cards with you at all times. Really, I mean carry a pack of vocab cards everywhere you go. This is easiest to do if the cards are small, business-card size or smaller. If you're on a budget, take 3x5 cards and cut them in thirds, resulting in cards about three inches long/tall by an inch and two thirds across the short way. Write each foreign word on the top of the front, then flip the card end-over-end and write three pieces of information on the back: the meaning(s), the part of speech (if that isn't completely obvious from either the form of the word itself or from the meaning), and either the chapter number you're studying in the grammar when you added this word (if you have one main grammar book; or if you are drawing your vocab words from a vocab list book, use the chapter or page number from that book) or the current date (otherwise). Always carry with you a pack of 15-30 of these cards, mostly ones that you've either recently added or have had trouble remembering. When you have wasted time (standing in line, waiting for someone, or whatever), whip out your cards and go over vocab words for a couple of minutes. Try to get through the pack (15-30 cards) at least once or twice each day. When you are confident that you are getting any given word right most of the time, set it aside from the rest of the pack and rotate it out, adding in another card to replace it. Each week take the ones that you set aside, put a slip on them with the date, and leave them out of your regular review pack for at least a week, maybe two. Then get them back out and go through them just once, sorting them; the ones you get right immediately, set aside for longer (perhaps a month or two, then sort them again the same way); the ones you miss, put back into your regular rotation. I used this system for Greek and Hebrew, and it works well, provided you carry the cards everywhere and look at them when you have odd moments each day. Words you have trouble with naturally spend more time in your pack this way, so they get extra repetition until you eventually learn them. In my experience, short words like pronouns and conjunctions and subordinators will tend to spend a lot of time in your pack whereas most substantial words like nouns and verbs are easier, but YMMV.
> What does this mean for me as an end user?
Today? Not much. In particular, it doesn't make this version a more compelling download, for an end user. What it does do, however, is pave the way for things to come.
> I would rather put 99% of efforts to improve compatibility with MS Office.
...)
You'd have to pinpoint specific points of incompatibility. At this point, I would have said that support for the Word and Excel formats was good enough, and that instead effort should be put into features, or into support for other popular formats (MS Works, AppleWorks, Word Perfect, MS Publisher,
> Isn't it the only reason why 99% of people don't switch to OpenOffice?
In a word, no.
I know of three major reasons why people don't use OpenOffice... The most obvious is lack of familiarity: people don't use what they don't know about. Perhaps more important is lack of bundling: it doesn't come pre-installed on computers. I'm pretty sure compatibility with MS Office isn't a major selling point for WordPad, but yet it continues to be used by more people than OpenOffice. Similarly, MS Works has only very marginal compatibility with Office, much worse than what OpenOffice has, but it's used by a lot more people, because a lot of OEMs bundle it. Third, there's the brand name factor: Microsoft in general and Word in particular is currently the big brand name, so people use it for the same reason they use Ziploc bags, although some competing brands are both better and cheaper.
Perceived incompatibility may be a factor for some people, but it is certainly not the only reason and probably not even the primary reason why people don't switch.
> Plus, a new keyboard shortcut permits the user to return to
... maybe eventually we could get to the point where it's easier to type up text in OpenOffice directly than to type it in Emacs, then copy and paste into OO for final formatting.
> a saved cursor position.
Sounds like markers in Emacs, especially the way I have them set up (wherein, hitting the key that I have bound to switch to the last saved position takes note of the current position so that it can be used next time, so that I can easily switch back and forth between two positions; it is, or course, still possible to set as many additional markers as desired).
Now, if OpenOffice will just get grouping-symbol matching like in Emacs, and the ability to split the window and easily look at two positions in the same file at the same time, and a more flexible system for customizing keybindings, and a better system for recording keyboard macros,
> I think where Wikipedia would probably beat out Britannica would be on
> technology-related articles
Yes, especially in terms of coverage. Wikipedia's math coverage is also pretty good. Actually, coverage tends to be overall better in Wikipedia (well, in the English Wikipedia anyhow). OTOH, Britannica has fewer utter-garbage articles. (I'm not saying WP is loaded with them or anything, but they do appear occasionally; I've seen I think three altogether, out of perhaps a couple of thousand articles I've looked at.) Also Britannica is more consistently formal in its grammar and style, which appeals to me. But Wikipedia is in many ways more convenient; the page layout is substantially more convenient for one thing, and allows the main text of the article to use a much larger percentage of the total window width, which makes it easier to read. It's also a good deal easier to navigate, especially because of the pervasive article-to-article hyperlinking. Then too, the search works better. Furthermore, to access Britannica online, I've got to go through OPLIN and type in a fourteen-digit library card number. This particular wrinkle, aside from the inconvenience, also makes Britannica worthless for hyperlinking purposes, and linking to them is a tremendously useful thing to be able to do with encyclopedia articles. Britannica is *slightly* preferable for traditional formal citations, but at that it's still an encyclopedia, fundamentally a tertiary source.
And yeah, for obvious reasons Wikipedia covers very recent topics better.
I do hope Wikipedia's plans to establish approved "stable" versions of articles turns out well; it seems to me that that's headed in the right direction.
> Whilst I agree with you generally, why did you consider the CLI to be 'a cult'?
> And to which CLI do you refer? Bash has its deficiencies and irregular syntax,
> but I don't know of anything better. Do you?
For an interactive CLI, there's a lot to be said for eshell.
And for writing "shell" scripts, Perl is an obvious choice.
I use a custom layout, on my main workstation at home. It's not a standardized layout like Dvorak, but one of my own invention. My primary reason for switching to a custom layout is because my pinkies were starting to ache constantly from always being overextended to hit keys like shift and ctrl. My custom layout puts left shift and right ctrl on home positions. While I was at it I fixed other minor aggravations; e.g., I moved the "Windows" key to a position where it's harder to hit by mistake, got rid of CAPSLOCK and numlock (making the keypad always for cursor movement; if I want numbers, I use the number keys), put the letter a where k used to be, and a small handful of other changes. My pinkies don't hurt anymore. YMMV.
And no, switching back and forth between my custom layout on my primary system at home versus standard QWERTY elsewhere is not a problem; my hands can feel the difference between my special keyboard and a regular one. I don't have to think about it; I just type and it comes out right.
This *sounds* insightful, if you haven't tried it. In practice, it is a non-issue. You get mildly confused switching back and forth for the first few weeks, while you're still learning the new layout, but once you get past the initial learning phase this problem goes away entirely. I use a custom layout on my main workstation at home, and standard QWERTY everywhere else. My fingers *know* whether they're sitting on my special keyboard or not; I don't even have to think about it; I just sit down and type.
> That's interesting; what state (country?) do you live in?
Ohio.
> I'm in northern Oregon
Ah, yeah, west coast. Obviously you'd see rather more of them than here.
> That's probably because this is tree-hugger central. There's plenty of trees to hug.
> We also have a fair number of pure electric cars and lots of bio-diesel VWs and
> whatnot cruising around.
We've got tons of trees, but we coexist with them. Trees are taller than buildings, so from a distance trees are pretty much all you see -- not just in satellite photos, but also looking across a valley or down from a hill or whatever. When you actually *get* there, you discover all the houses and stuff, but from a mile away most Ohio cities look mostly like woods (in the summer; in the winter, of course, you can see through between the branches). The most tree-sparse areas (outside of the relatively small central portions of the dozen or so major cities with skylines) are not the cities but the rural areas, where there are lots of wide open fields.
> We also have a fair number of pure electric cars and lots of bio-diesel VWs and whatnot
> cruising around. Of course there's a full-size Hummer for every hybrid I see.
Diesel is _relatively_ common around here, though clearly a small minority compared with gasoline vehicles, and I have no idea whether any of them use biodiesel, as opposed to petroleum-derived diesel. As for Hummers, there's one of those fakey new pseudo-Hummers in Galion (it happens to be bright yellow, so there's no missing it), and we see other instances of that model around too (the other day we were over in Ontario doing some shopping and I happened to see a dark green one), but AFAIK the nearest *actual* Hum-Vee is at the national guard base over in Mansfield. There are plenty of unnecessarily-large SUVs, though, a minivan for every subcompact, and probably the most common auto type is the midsize sedan with a high safety rating that gets deplorable mileage for a car (albeit, still rather better than a minivan, to say nothing of an SUV).
Additionally, there are a lot of those new kind of pickup trucks that started appearing in the nineties, that don't actually look like traditional pickup trucks, insofar as they have bright shiny paint jobs (often in colors that pickup trucks never used to come in, although red is also popular), smooth curves, and would look *completely* out of place parked between a combine and a chicken coop. Also they're about twice the size of traditional pickup trucks, especially in terms of height and cabin space. You know the ones I mean. People drive them who you just know have never worn overalls in their lives.
> Where do you live?
Galion (a city of about twelve thousand people in central Ohio).
# Of course, this doesn't mean that our articles are
# necessarily better; it depends on the severity of the
# problems, whether our extra words are actually useful
# information or just verbiage/trivia, etcetera. There's
# also the question of when, exactly the articles were
# reviewed.
This quote is from the same source as the average article lengths, and it's good to see this admission. It's encouraging that the Wikipedians who did this length comparison acknowledge that length isn't necessarily everything.
On the other hand, Brittanica may be deliberately edited for terseness, to reduce costs of things like printing, shipping, warehousing, and so on. Brevity can be a virtue, but on the other hand it also isn't everything.
Still, interesting to see the comparison.
> Will these come with a cow catcher? How about slotted wheels? Dining car?
I don't know about an entire dining car, but I bet they come with cup holders...
> it will still be a while before you see many hybrids out of warranty
I don't know about where you live, but around here the "out of warranty" qualifier is superfluous; I've yet to see hide nor hair of a hybrid car IRL, period. Sure do read about them all the time on slashdot, though.
Oh, great, two additional circulating closed systems, as if the oil and water cooling systems in a normal automobile weren't adequate sources of repair bills. I suppose it also adds a second radiator?
> > practically no downside.
> Additional moving parts
My thoughts exactly. The idea is interesting, but roughly twice the number of engine parts for only a 15% performance/efficiency improvement sounds to me like a bad trade.
Not that they shouldn't procede with further research, but I wouldn't suggest taking anything to market in the described state.
> If you already have a decent background in c and at least one scripting language,
> say php, you should be good to go.
No PHP, and my C is _very_ marginal. However, I'm fluent in elisp and Inform, think in Perl, used to think in QBasic at one time, and have had some exposure to at least a dozen other programming languages. (By "some exposure" I mean enough to handily ace undergrad courses in the language, but not enough to do anything really serious or useful; my knowledge of Python is probably about this level, although I was doing it self-study, having previously graduated.)
Like I said, maybe you just think Guido's Way. Some of us don't.
> Isn't emacs horribly stagnant these days?
No more so than five years ago. Emacs development has always been gradual and conservative. The reason it has so many features is because it's been in development since approximately the late bronze age. Emacs in principle is older than any hardware architecture you can still buy new, and the current implementation dates from 1984. It's *old*. So if development isn't as fast as on some newer projects, don't sweat it. It's not like there's a six-month deadline looming for shipping the next version. My first reaction when I saw the Emacs 22 headline was, "Wow, already?"
> 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.
The friction (if it's even still relevant; I think it is mostly in the past at this point, though of course there will always be a few people who hold grudges forever) is of no concern to me, but I stick with Gnu Emacs because I have significant amounts of custom elisp that I don't want to have to port over. Gnu Emacs is the Emacs that I started out with, so it's what I stick with.
> 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
If you are an Emacs user and have never used eshell, you really should give it a try. The really nifty thing about it is that it's not just a bash substitute; it really tries to do things in an Emacs-oriented way. Also, it doesn't have to implement things like macros and commmand-line editing, because you already have those by virtue of the fact that you're in Emacs. One really cool thing about it is that you can mix and match external system commands with lisp functions.
> As far as all the features being available in just about any other editor, you're dreaming!
No, he just doesn't know what features are. He's thinking of mundane things like copy and paste, syntax highlighting, the ability to save, and so forth -- things that really *are* in many editors, things you so take for granted that you don't even consider them to be features. He isn't familiar enough with Emacs to realize that it has *real* features, i.e., advanced features, features little or nothing else has. Things like navigating by sexp do not even occur to users of most other editors, because they don't even *imagine* that a text editor could have that kind of uncanny power.
> 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
> I heard with the new version it will make you tea
I don't think you need the new version for that. If you have a network-enabled "coffee maker" that can brew tea, I think all you need is coffee.el (which may even be included in Emacs out of the box these days). Unless I am greatly mistaken, people have been brewing beverages from within Emacs at least since version 20, if not before.
> What's so great about it that people insist on using it rather than any other editor?
Quite a lot of things. First off, it's *WAY* more customizeable. Even highly-customizeable editors like vim think about customizeability in terms of "I want the user to be able to do such-and-such", which is a limited approach. Emacs thinks of custumizeability in terms of
"under these circumstances, when such-and-such occurs, what is the ideal thing that should happen?" The result is an editor that can be made to actively do the user's work, with only the least amount of prompting. In fact, the user only really has to be prompted at all when there's some question as to what needs to be done, and the user's guidance is therefore needed. Every editor (worth talking about) has macros, but Emacs has a whole nother level of automating repetitive tasks. For instance, I'm involved in a quizzing program, and I write questions. So I whipped up a quick major mode for it (that I call quizques-mode). So now when I edit my questions, and I type the question mark at the end of a question, the mode automatically goes down and inserts the "A:" and the tab character and is ready for my answer. When I'm typing questions from a particular passage, and I'm putting references in parentheses at the ends of the answers, I don't have to type them all out; I just hit : and the verse number, and the rest (book, chapter, and parentheses) are all filled out for me. (And so on; the mode has perhaps a dozen such features, which collectively save about 25% of the time that would otherwise be spent typing questions.) For Perl programmers, cperl-mode is another example of this sort of thing, but that's more standardized; the real value is not in something standardized (as any editor can include standardized helps for editing something as common as Perl code), but in the ability to add your own customizations for anything you happen to be editing. And, unlike if you edited the C source of something like vim to add such features, your additions will still work, generally with no changes, when you upgrade to the next version of Emacs. (That's quite aside from the fact that whipping up something in elisp is *way* easier and faster than changing the C source of the editor.) I have over the course of several years personally accumulated over half a megabyte of custom elisp that implements my various and sundry personal customizations for Emacs. Collectively, these things save me quite a lot of time, in small increments spread out over each day.
There are also some individual features that are highly addictive. The grouping-symbol matching, for instance, is something I sorely miss when I use other applications, such as Firefox and OpenOffice.org, much less the numerous so-called "text editors" that don't have such essential features. Firefox did finally get (a somewhat broken implementation of) incremental search, which is nice. I notice it doesn't have incremental regular-expression search, though...
The built-in nature of the documentation is exceedingly handy, too. And there are many other things. Most are little things, but there are thousands of them, and they add up.
> I just bought my dad an iMac, and was looking around for an emacs build for it.
It's included. Open Finder, click on Applications in the little sidebar on the left, and look for Terminal. Open that, and type emacs at the shell prompt.
The only thing is, this gives you a console/terminal Emacs, so there are no toolbars or scrollbars, and all dialog takes place in the minibuffer, and the menubars by default are not visible unless you invoke them. Also, you're limited to a few colors (16 IIRC), and graphics cannot be displayed. If you want a GUI-enabled version of Emacs, I think you have to download and install the X server from Apple. (Whether the out-of-the-box Emacs will automagically work with X if started from within X, I'm not sure (never tried, and I no longer have regular access to an OS X system); if not, ask again and specify that you want an X11-enabled Emacs for Mac OS X, preferably in an apple.slashdot.org story relates to either X11 or Emacs.)
> Wait, so I can use my Emacs operating system on top my Windows operating system?
n scrollbars again -- not that I very often use the mouse to move around in a text editor anyway, but it's the principle of the thing.)
Emacs has run directly on Windows (without need for Cygwin) for aeons, at least since Emacs 19, probably before. Through version 20 that release was called NTEmacs, but from 21.0 forward it's no longer really distinct from Emacs on any other platform, except that the variable window-system might be set to a different value, and it might use a different widget set. (Speaking of which, I'm glad to hear version 22 is moving to a decent, modern widget set for X11-based platforms. I don't care precisely *which* decent, modern widget set it uses; Qt for instance would have been fine with me; GTK is also fine; wx would also have been fine, or XUL, or whatever OpenOffice uses... really, any decent, modern widget set would be fine... but Xaw is just absolutely terrible, and I hope to never see one of its thrice-becursed sliderless use-the-right-button-to-scroll-the-other-directio
Emacs also has run just fine on Cygwin for quite some while.
> 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
I think for that we really need to wait for multitasking features in Emacs (and relevant lisp functions, such as lazy-eval and fork), and for significant improvements in the C-to-elisp compiler, so that we can get various needed desktop software running in Emacs. For instance, if you were running Emacs on the bare metal, currently, and you needed to do some photo editing, you'd be up a creek without a ladder, because there's no Gimp port currently for Emacs, nor anything really comparable in terms of native applications. In practice, virtually all Emacs users rely on at least a limited number of external, non-Emacs applications for one thing or another. This needs to change before a bare-metal version of Emacs will be very much practical use.
I was hoping the multitasking stuff would make it into Emacs 22, but I don't see it on the list, so maybe for Emacs 23, hopefully.
Also, before a bare-metal Emacs would be practical, filesystems would need to be implemented; that could be done *mostly* in lisp, I think, but there would have to be some C hooks put in for it, I think, and additionally the code that currently uses the external filesystem would have to be modified to be able to use whatever native Emacs filesystem implementations are available. Also, if Emacs has its own TCP/IP stack, I am not aware of it, so that would be needed -- oh, and also hardware drivers. In short, it's a lot of work, and I don't think we'll see a usable-in-practice bare-metal version before Emacs 25 at the earliest.