×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Emacs Needs To Move To GitHub, Says ESR

timothy posted about 3 months ago | from the this-way-to-the-bazaar dept.

GNU is Not Unix 252

hypnosec writes "Eric S. Raymond, co-founder of the Open Source Initiative, has recommended that Emacs should move to another version control system like GitHub, as bzr is dying. In an email, Raymond highlighted the key reasons why he believes that Emacs should move. Raymond said that bzr is moribund; its dev list has flatlined; and most of Canonical's in-house projects have already abandoned bzr and moved to GitHub. ESR believes that bzr's codebase is sufficiently mature to be used as a production tool, but he does mention that continuing to use the revision control system will have 'social and signaling effects damaging to Emacs's prospects.'" Update: 01/06 20:50 GMT by U L : ESR did not suggest Github the proprietary hosting platform for git, but rather git the version control system. Which is actually already available on Savannah (the bazaar repository is automatically synced with the git repository).

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

252 comments

Git, not Github (5, Informative)

codl (1703578) | about 3 months ago | (#45845347)

ESR's original posting [gnu.org] does not mention Github at all.

Re:Git, not Github (2, Insightful)

monzie (729782) | about 3 months ago | (#45845425)

Good catch there. If you read just the summary ( and not the article ) - it's misleading! Git != Github, folks. You may like Git *because* of github but please don't confuse the two.

Re:Git, not Github (5, Informative)

Desler (1608317) | about 3 months ago | (#45845451)

"The article" (the first link which is to hypnosec's spam site) also says Github. ESR's post says merely Git.

Re:Git, not Github (1)

JonahsDad (1332091) | about 3 months ago | (#45845531)

Funny enough, the article now has all "Github" items crossed out and replaced by "git"

Re: Git, not Github (1)

Anonymous Coward | about 3 months ago | (#45845509)

I thought emacs ran on top of git. or was it the other way around ? meh I can never remember ...

What's bzr? (2, Interesting)

Anonymous Coward | about 3 months ago | (#45845353)

Never heard of it.

Re:What's bzr? (0)

Anonymous Coward | about 3 months ago | (#45845419)

Canonical's NIH version of Git.

Re:What's bzr? (3, Informative)

dominux (731134) | about 3 months ago | (#45845673)

it pre-dates git by a year, it was the NiH version of cvs and svn. Bzr was doing useful stuff before anyone realised Git would ever be used for anything other than the Linux kernel source tree. That isn't to say that NiH isn't sometimes a good thing, and that Canonical do daft things from time to time, but bzr wasn't a NiH reaction to Git.

Re:What's bzr? (1)

Desler (1608317) | about 3 months ago | (#45845905)

it pre-dates git by a year

Nope, initial release of bzr only predates the first release of git by 12 days. March 26, 2005 vs April 7, 2005.

Re:What's bzr? (1)

allo (1728082) | about 3 months ago | (#45846079)

Maybe it was an attempt to become the kernel VCS, as the kernel hackers already were angry about bitkeeper at this time.

Re:What's bzr? (0)

Anonymous Coward | about 3 months ago | (#45846209)

kernel hackers

At Canonical?

Re:What's bzr? (3, Informative)

Lemming Mark (849014) | about 3 months ago | (#45846323)

I thought there was a fairly complex history here, since the current bzr was (I thought) bzr-ng originally, an alternative to some original Bazaar tool. And I thought that *that* came from GNU Arch, which (speaking loosely) I gathered wasn't well understood or enjoyable to use. I don't know how much of the current behaviour dates back that far, though, so there may not be too much in common now!

Re:What's bzr? (2)

Rinisari (521266) | about 3 months ago | (#45845533)

Bazaar [canonical.com]. It's a VCS that Canonical developed. Why Switch to Bazaar? [canonical.com]

IMO, the only things that Bazaar has up on Git these days is released, official support for Windows and thus better GUIs all around for all platforms. Git is still technically a pre-release for Windows. Bazaar is also purportedly better for binary files than Git, and allows downloads from any point in the history (instead of Git requiring that you download the whole repository history).

Re:What's bzr? (0)

Anonymous Coward | about 3 months ago | (#45845633)

I wonder how ESR reacted to Canonical's choice of Bazaar as the name of their open source collaboration tool. Flattered? Territorial? I guess neither.

Re:What's bzr? (0)

Anonymous Coward | about 3 months ago | (#45845989)

Git doesn't require you to download the whole history. You can use the "git clone --depth X" to only download X number of revision. It does add some restrictions, so you can't clone/fetch/push from your clone.

Re:What's bzr? (3, Informative)

DrXym (126579) | about 3 months ago | (#45846241)

Git seems to be perpetually in preview on Windows but in practice it works relatively well. There are quite a few front ends for it if you hate the command line.

The biggest issues I have with it are:

  • Line ending conversion is a massive pain in the arse. Windows is CRLF, Linux is LF. Msysgit asks during installation what line ending conversion policy to use. If you get it wrong, you'll see spurious issues with files marked as modified when no difference is visible. The best advice I can give is set core.autocrlf to false when you install msysgit so that line endings are left alone. You can do stuff with a file called .gitattributes to turn off line ending conversion in the repo itself but JGit (the Java pure impl of Git in Eclipse) doesn't actually bother to honour the settings in that file.
  • Performance is a bit poor. You won't notice in small repos but when the repo is 10,000+ files, simple things like "git status" can sit there for minutes. MSYS has an inefficient lstat and performance becomes noticeably in Git as a consequence. An SSD helps a lot, but that's no consolation for devs who can't ask for one.
  • 260 char MAX_PATH imposes restrictions on path length that the fs itself could cope with.

Nothing is a deal breaker. I think Git on Windows works as well as most other source control systems when its up and going and comes with its own advantages that compel its use for software development. I wouldn't use it for document management though - something like Subversion would be better for that.

GNU Savannah supports git (4, Informative)

byolinux (535260) | about 3 months ago | (#45845359)

No need to move to a proprietary hosting service like Github.

I wrote about this previously: http://www.fsf.org/blogs/community/savannah [fsf.org]

Re:GNU Savannah supports git (1)

ThePhilips (752041) | about 3 months ago | (#45845455)

Wow. Support for GNU Arch is really an outstanding feature!

TLA is for all intent and purposes is dead. The .gitignore alone is reason enough to migrate to git.

OK, archives is a very cool feature found literally nowhere else, but it alone isn't enough to sway any decision process in favor of TLA.

Re:GNU Savannah supports git (1, Interesting)

mwvdlee (775178) | about 3 months ago | (#45845473)

Just wondering; why doesn't your article mention Github, which is probably the most popular service right now?

Re:GNU Savannah supports git (1)

Desler (1608317) | about 3 months ago | (#45845493)

Did you not even bother reading the person's first sentence?

No need to move to a proprietary hosting service like Github.

Re:GNU Savannah supports git (1)

mwvdlee (775178) | about 3 months ago | (#45845511)

I did. Why didn't you?

Just wondering; why doesn't your article mention Github, which is probably the most popular service right now?

Re:GNU Savannah supports git (0)

Desler (1608317) | about 3 months ago | (#45845537)

Yes, and the first sentence of his post that you responded to tells you exactly why:

No need to move to a proprietary hosting service like Github.

It's an FSF article. Why would they recommend a proprietary service? Are you ignorant of who and what the FSF are?

Re:GNU Savannah supports git (1)

mwvdlee (775178) | about 3 months ago | (#45845657)

I wondered why the article didn't mention it.
I fully understand why he wouldn't recommend it, which is why I didn't ask about that.
Three other proprietary services are mentioned, but the most popular one was omitted.

Re:GNU Savannah supports git (2)

Desler (1608317) | about 3 months ago | (#45845705)

Because the list was not meant to be exhaustive? Because when the article was written in August 2008, Github was only a couple of months old at the time and had far less users than the other services mentioned?

Re:GNU Savannah supports git (0)

Wootery (1087023) | about 3 months ago | (#45846229)

Because when the article was written in August 2008

I think that was mwvdlee's point. It's hard to take them seriously if they make no mention of GitHub, but do single out other rivals including Google Code.

It's their responsibility to stay up to date with this stuff. Failing to keep your web-site relevant isn't a good sign.

Re:GNU Savannah supports git (1)

just_another_sean (919159) | about 3 months ago | (#45845541)

proprietary hosting service

Re:GNU Savannah supports git (1, Insightful)

Desler (1608317) | about 3 months ago | (#45845581)

Exactly. His question is as dumb as asking "Why doesn't the FSF recommend Windows?".

Re:GNU Savannah supports git (1)

mwvdlee (775178) | about 3 months ago | (#45845745)

Read my comment above.

Imagine Microsoft wrote an article about OS'es, recommending Windows and mentioning only Haiku, ReactOS and FreeDOS as possible open source OS'es, failing to even mention Linux.

This is not about what the article recommends, it's about the article completely ignoring the elephant in the room.

Re:GNU Savannah supports git (1)

Desler (1608317) | about 3 months ago | (#45845769)

This is not about what the article recommends, it's about the article completely ignoring the elephant in the room.

The article was written in August 2008. Github was 4 months old. It was no "elephant in the room". The article also didn't mention Codeplex, Bitbucket, JavaForge, and countless other sites that existed at the time in 2008. So what? His article was not meant to be an exhaustive list. The article merely was about the biggest source code hosts at the time it was written.

Re:GNU Savannah supports git (1)

scubamage (727538) | about 3 months ago | (#45845507)

Most likely because Stallman completely avoids all cloud services because when you use them, you don't really own your data. Git has an actual chance of being used. Github? Unlikely.

Re:GNU Savannah supports git (1)

Desler (1608317) | about 3 months ago | (#45845521)

GNU Savannah is a "cloud service". The difference to someone like Stallman is GNU Savannah is "free software" whilst Github is not.

Re:GNU Savannah supports git (1)

scubamage (727538) | about 3 months ago | (#45845617)

That I did not know. I know he has posted some rants before about avoiding cloud services, but you could very well be right about that being the difference.

Re:GNU Savannah supports git (0)

Anonymous Coward | about 3 months ago | (#45845985)

Stallman is a whackjob and the free software movement would be 10x better off without him.

Re:GNU Savannah supports git (1)

DrXym (126579) | about 3 months ago | (#45846269)

Source code has to be hosted somewhere. Even if the FSF hosts source code on their own servers it's still "in the cloud" as far as people pushing and pulling from it are concerned. Anyway, if it's a big deal, they could set up GitHub as a mirror and host the "master" copy on their server even if in practice most people would be pushing to GitHub and that would be periodically synced to the FSF.

Re:GNU Savannah supports git (1)

devent (1627873) | about 3 months ago | (#45845485)

There are more alternatives. For example Redmine http://www.redmine.org/ [redmine.org]
Redmine offers a full project management suite: bug track, wiki, forum, files and document, version control, GANT chart, and so on.

Git... (5, Informative)

Anonymous Coward | about 3 months ago | (#45845365)

He wants to move emacs to git and not to Github. Journalists...

Re:Git... (3, Informative)

Anonymous Coward | about 3 months ago | (#45845403)

"hypnosec" is not a journalist. It's someone who's spamming his regurgitation blog posts to drive ad impressions.

Re:Git... (0)

Anonymous Coward | about 3 months ago | (#45845429)

The mistake was already in the article by Ravi Mandalia.

Re:Git... (3, Informative)

Desler (1608317) | about 3 months ago | (#45845461)

Ravi Mandalia is "hypnosec".

Re:Git... (5, Informative)

Desler (1608317) | about 3 months ago | (#45845487)

To add, Ravi Mandali's first version of his spam site was called "Hypno Security" which just basically regurgitated a couple of paragraphs of other people's news as "articles" and started spamming it here.

http://www.freelancer.com/u/hypnosec.html [freelancer.com]

Re:Git... (0)

Anonymous Coward | about 3 months ago | (#45845709)

To add, Ravi Mandali's first version of his spam site was called "Hypno Security" which just basically regurgitated a couple of paragraphs of other people's news as "articles"

So like Slashdot?

Re:Git... (3, Funny)

Desler (1608317) | about 3 months ago | (#45845827)

No, actually worse. His grammar and factual accuracy makes the Slashdot editors look top notch.

Re:Git... (1)

monzie (729782) | about 3 months ago | (#45845433)

and Slashdot Editors.. if there are any of them left....

Re:Git... (1)

Desler (1608317) | about 3 months ago | (#45845655)

Having an editor is useless when they are basically functionally illiterate.

Re:Git... (0)

Anonymous Coward | about 3 months ago | (#45845817)

Slashdot "editors" focus on whatever article will generate the most page hits. This month it's obviously all the NSA/Snowden noise; greenlighting essentially the same article three times a day won't change as long as people keep commenting on it.

Re:Git... (0)

Anonymous Coward | about 3 months ago | (#45846013)

Slashdot has never in its entire existence had "editors".

Re:Git... (1)

tgd (2822) | about 3 months ago | (#45846025)

and Slashdot Editors.. if there are any of them left....

If it doesn't reduce ad impressions, why would the editors care?

The criticisms people are leveling against this Ravi Mandali guy are for doing the same crap that DICE has ensured Slashdot does every day.

 

git, not GitHub (5, Informative)

Anonymous Coward | about 3 months ago | (#45845371)

The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?

Re:git, not GitHub (4, Insightful)

fuzzyfuzzyfungus (1223518) | about 3 months ago | (#45845715)

The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?

C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!

Re:git, not GitHub (1)

Medievalist (16032) | about 3 months ago | (#45846121)

The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?

C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!

Said snappily named services discovered through a multicast DNS portal into a Microsoft Active Directory, of course.

Why have a single single vendor dependency when you can stack 'em up like cordwood?

Re:git, not GitHub (1)

fuzzyfuzzyfungus (1223518) | about 3 months ago | (#45846371)

That sounds dangerously like a suggestion that the assorted vendor lock-in products should inter-operate with one another in some sane way... True endarkenment is only achieved when each product has some stupid dependency on the others; but not anything that would actually make the whole mess easier. Making a 'cloud' service dependent on a local MS server/client setup, for instance, is excellent; but having that 'cloud' service capable of authenticating against your AD, rather than it's own half-assed credentials system, totally spoils the effect....

He never mentioned "GitHub" (0)

Anonymous Coward | about 3 months ago | (#45845379)

What? GitHub isn't a version control system, is a proof of concept on how to centralize a distributed technology.

Re:He never mentioned "GitHub" (0)

Anonymous Coward | about 3 months ago | (#45845747)

Haha, well put. And true.

Cathedral and the bazaar (-1)

Anonymous Coward | about 3 months ago | (#45845387)

Remember how some of you people took that navel gazing wishful thinking arrogant pseuophilosophical nonsense seriously? I was at (famous uni) once when esr presented it there. Guy was basically laughed out of the room.. And that was before the linux bubble of the early 2000s.

Surprised (4, Funny)

DaveAtFraud (460127) | about 3 months ago | (#45845501)

I'm surprised that emacs didn't already have a version control system built into. It has everything else.

Cheers,
Dave

Re:Surprised (5, Funny)

Anonymous Coward | about 3 months ago | (#45845629)

It has everything but still lacks decent editor

Re:Surprised (0)

Anonymous Coward | about 3 months ago | (#45846105)

There is evil: http://www.emacswiki.org/emacs/Evil

Re:Surprised (1)

fuzzyfuzzyfungus (1223518) | about 3 months ago | (#45845743)

Given that emacs is Turing-complete, it might be said that it includes all possible features. Some, of course, are available out of the box, while some require considerable configuration (mysteriously, this configuration process takes almost exactly the same amount of time as re-implementing the feature in emacs Lisp...)

Don't leave us hanging (0)

Anonymous Coward | about 3 months ago | (#45845925)

a version control system built into

Built into what?

The only winning move is to laugh at ESR (0)

0xdeadbeef (28836) | about 3 months ago | (#45845527)

Doing anything ESR tells you to do also has social and signaling effects damaging to your prospects.

So, Emacs should just keep on truckin' on.

But how exactly? (0)

nashv (1479253) | about 3 months ago | (#45845561)

Should we take this to mean that Facebook, and Twitter have vulnerabilities that allow a third-party to usurp control of an account?

I thought modern authentication procedures were solid enough that you couldn't just get access to the account typing a few commands. There had to be more.

Pretty sure... (0)

Anonymous Coward | about 3 months ago | (#45845639)

People should just stop using emacs already... :(

Re:Pretty sure... (1)

ebno-10db (1459097) | about 3 months ago | (#45845847)

Heretic, apostate, blasphemer! (I can never remember the differences between the three).

Re:Pretty sure... (3, Informative)

mellon (7048) | about 3 months ago | (#45845977)

A heretic uses XEmacs. An apostate doesn't take the time to install Emacs where it is not available, instead using vi. A blasphemer suggests that emacs and vi are essentially interchangeable, denying emacs' uniqueness and primacy. All three prefer emacs; only pagans and barbarians prefer something else.

Re:Pretty sure... (1)

93 Escort Wagon (326346) | about 3 months ago | (#45846073)

Heretic, apostate, blasphemer! (I can never remember the differences between the three).

The last two were not games released by Id Software.

Insufficient Resources (2, Insightful)

Anonymous Coward | about 3 months ago | (#45845671)

Github doesn't have the resources to host something that bloated.

Re:Insufficient Resources (1)

jmak (409787) | about 3 months ago | (#45845941)

I see what you did there, but Emacs' codebase is actually quite small by today's standards.

annoying (0)

Anonymous Coward | about 3 months ago | (#45845681)

What has he added to the previous discussion they had about version control months ago on emacs-devel? Does he think the fact he's saying it instead of John Wiegley changes things somehow? rms is going to think to himself, "ah, my good friend Eric Raymond, that paragon of reason thinks this way, so maybe it's time to revisit the vcs again?"

What about Mercurial? (5, Insightful)

ebno-10db (1459097) | about 3 months ago | (#45845757)

Since VC wars are almost as much fun as language wars, and I've already donned my Nomex underwear, why not Mercurial? It isn't as popular as git, but it's not going to die either (e.g. Python project uses Hg). It seems that most people or organizations that have actually sat down and evaluated Hg vs. git have chosen Hg. Examples include Google's online repository and Fog Creek's Kiln. Both now also support git, but that's because of demand by users. Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why? For all its visibility and importance, the Linux kernel is but one FOSS project, and the vast majority of FOSS devs don't work on it.

Now for the statement that some will see as flamebait :-) but which is a sincere observation. I think the difference is the fanboi factor; people who think that git is the choice because it's from Linus, the ultimate cool kid. No, I don't think everyone who uses git does so because they're a fanboi. I suspect the main reason is going with that flow, but it's the fanbois who originally pushed that flow so hard. As your mother used to say, if all your friends decided to jump off a cliff, would you jump too? Vociferous debate welcome.

Sincerely,
Don Quixote

Re:What about Mercurial? (1)

cjjjer (530715) | about 3 months ago | (#45845955)

My thoughts exactly, if an OSS project success has more to do with the VC system that houses it than the developers working on it I feel OSS is doomed. This mentality spits in the face of all the OSS projects that don't use git.

Re:What about Mercurial? (2)

Waffle Iron (339739) | about 3 months ago | (#45846205)

Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why?

The network effect explains it. Git probably got an early boost of popularity because of who its author was. This initial momentum was enough to snowball into the most popular distributed RCS. Once it is established, learning curves and database lock-in create a barrier to other alternatives, and they apparently aren't currently "better enough" to prompt people to work through those barriers.

For example, even if Hg has a better CLI than git as you say, I'm sure that just learning and using just the git CLI is easier than filling one's head with both git and Hg knowledge. (In a similar circumstance, I currently have to use both yum and apt. They have similar concepts but different CLIs, and now I have to use a cheat sheet to run almost any command on either one. If I only used one or the other, I could probably keep the common commands straight in my head.)

I doubt that git is going to get knocked out of prominence until someone invents the next major concept in version control. This has happened before: both when Subversion surpassed CVS in buzz factor, and when git surpassed Subversion.

Re:What about Mercurial? (1)

magic maverick (2615475) | about 3 months ago | (#45846237)

Funny, I thought much the same about Bzr. Bzr has at least one GUI (bzr-gtk), is better supported on more than just Linux-based systems, is also written in Python, etc.

Unfortunately, Bzr development has apparently stalled (hence the email from esr suggesting moving off bzr to git -- he notes that he would prefer hg, but that Git has basically won). But, bzr does everything I ask of it. I'll be continuing to use it, so long as it continues to work. When it stops, I guess I'll have to find a tool to convert all my shit to Git or whatever, and find replacements for the various tools that I use (e.g. integration into Gedit).

Re:What about Mercurial? (1)

daveisfera (832409) | about 3 months ago | (#45846301)

The discussed email from ESR states that git has won the mindshare war and that Mercurial is "is not looking real healthy these days". So while I agree with everything you said, it appears that the general opinion does not.

Can't we settle this like geeks? (4, Funny)

fuzzyfuzzyfungus (1223518) | about 3 months ago | (#45845761)

Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?

Given sufficient time, I'm sure we can generalize away any petty disagreements!

Re:Can't we settle this like geeks? (0)

Anonymous Coward | about 3 months ago | (#45846387)

I thought that was the point of bzr already.

(http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html)

The usual ESR self-aggrandizement (4, Interesting)

mvdwege (243851) | about 3 months ago | (#45845839)

Apparently Eric has decided he has been out of the public eye too long, as he posts yet another self-aggrandizing screed on a mailing list.

Seriously, after the kernel configuration debacle and his hysterical rants on the Fedora list, does anyone take this man seriously anymore? Look at how he represents himself: an expert on source control systems, whose highest achievement is moving troff to a git repo. It's kconfig all over again.

emacs on bzr? (1)

csumpi (2258986) | about 3 months ago | (#45845861)

It's baffling that such a large project would use bzr as source control. Bzr doesn't have branching. Before you yell at me, I know, there is a command to create a "branch", but it is essentially a copy of the whole repo. Unusable for any project larger than a couple files. I would not be one bit surprised if it in fact was dying.

This is the result of picking a tool based on "what's trending this hour", "their website looks better", "look, they have an ipad app", "the ceo's son uses this" etc..

Happens way too often. Instead of doing some research. Sleep in the bed you made.

The real question is about Emacs (4, Interesting)

hcs_$reboot (1536101) | about 3 months ago | (#45845899)

Actually, is the dying one being Emacs, instead? That would be sad - but I wonder how younger generations do appreciate Emacs which is quite tricky to get used to - while so convenient and still unequaled in 2014 when it comes to some features (hyper customization thanks to (e)Lisp, M-x features with completion, intra-shell/processes, apropos, ^x-( ), languages modes ...). It seems the major IDE or text editors did not even try to reproduce the main features of Emacs - do they ignore the Emacs logic because they have no knowledge of it, or do they simply feel those features are obsolete? For once, nobody reinvents the wheel, which is going to die eventually. Sad, really.

Re:The real question is about Emacs (2)

Greyfox (87712) | about 3 months ago | (#45846125)

People don't use a lot of the old tools because they're not aware of the old tools. You never see anyone use Lex and Yacc, for example. Slightly more people seem to know about gdb and efence, but only slightly. I've been talking to a relative as he's going through a CS program and most of his work has been either Java/Eclipse or C++ on a Microsoft Visual C++ platform, with not even the cursory look at the UNIX tools that were common back in the '80s.

What prospects of Emacs left to be damaged? (4, Insightful)

Anonymous Coward | about 3 months ago | (#45845979)

Is there still any prospect at all? I left 5 years ago because they stopped improving anything for a decade.

A decade ago it was comparably decent IDE for Java and C++, today it's nothing thanks to incomplete project management UI, incomplete file tab support, and over-reliance on ctags which can't really understand syntax and parse things properly, and their inability to work on on-the-fly static code-analysis, which requires basic threading support that (still) isn't done.

the same could be said for Vim as well. While both remain very efficient text editors, they no longer matter because it's far more important to study and write correct code than to writing code faster, and other IDEs have improved on such parts drastically these years.

Emacs is awesome!! (1, Funny)

Andover Chick (1859494) | about 3 months ago | (#45845993)

Just wanted to say, unrelated to the GitHub discussion, that Emacs is awesome! I've been using it since the mid-80s on 2400 baud modems and have been a big fan of Stallman and the boys. There are things I'd like, for example a GUI object browser. But overall it is f-a-n-t-a-s-t-i-c!

No, it doesnt (1, Troll)

nurb432 (527695) | about 3 months ago | (#45846155)

It needs to move to /dev/null Worthless piece of bloated garbage. Its 2014, it has no place in the modern world.

Emacs is an OS (1)

duckgod (2664193) | about 3 months ago | (#45846167)

Doesn't it have a version control in it? Possible no one has found it yet. Anyways I know mere text editors like VIM can do just fine on Mercurial.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...