Live data from Hacker News

Bzr is dying; Emacs needs to move

lists.gnu.org

71–80 of 317 posts

Re: Bzr is dying; Emacs needs to move

#71
post #50

Earlier quoted context omitted.

Emacs has a package manager, it works fine. I particularly like that I can script it to install my packages on first run.

works fine = work fine for me after I have spend x hours looking around the net, writing elisp myself. that's the whole problem with lisp. it is not communal, because it does not enforce standards.

M-x package-refresh-contents

M-x package-install

That's with a blank .emacs file on Emacs 24 on a brand new user account I created just to test that for you.

EDIT: (ofc the auto-installing my favourite packages stuff is elisp I wrote)

Re: Bzr is dying; Emacs needs to move

#72
post #50

Earlier quoted context omitted.

Emacs has a package manager, it works fine. I particularly like that I can script it to install my packages on first run.

works fine = work fine for me after I have spend x hours looking around the net, writing elisp myself. that's the whole problem with lisp. it is not communal, because it does not enforce standards.

(package-initialize)

Wow, now you have access to the package manager.

Emacs is meant to be customized heavily by its users and the language to do so is Elisp. If you are afraid of that then I don't know what to tell you.

You are quick to condemn all Lisps with an assertion that doesn't make sense to me.

Re: Bzr is dying; Emacs needs to move

#73
post #37

wow. please, please, you Emacs/LISP gurus out there: make a working modern package manager and integrate the browser like lighttable does. and perhaps rewrite emacs from scratch so that the source code makes sense in today's world not in 1980's world. unfortunately lighttable is staying closed for much too long, but something like it is desperately needed.

I agree - Emacs has to be rewritten on top of a modern rendering engine!

Then do it.

Re: Bzr is dying; Emacs needs to move

#74

wow. please, please, you Emacs/LISP gurus out there: make a working modern package manager and integrate the browser like lighttable does. and perhaps rewrite emacs from scratch so that the source code makes sense in today's world not in 1980's world. unfortunately lighttable is staying closed for much too long, but something like it is desperately needed.

> rewrite emacs from scratch

You obviously have no idea of how huge undertaking would this be. You are free to write your new editor and call it Fnbdt.

Re: Bzr is dying; Emacs needs to move

#75
post #50

Earlier quoted context omitted.

Emacs has a package manager, it works fine. I particularly like that I can script it to install my packages on first run.

works fine = work fine for me after I have spend x hours looking around the net, writing elisp myself. that's the whole problem with lisp. it is not communal, because it does not enforce standards.

I don't understand, what's wrong with package-list-packages? It has concise descriptions, MELPA is kept very well updated, and and installing plugins is a breeze, no elisp configuration is necessary for like 90% of the packages you install.

Re: Bzr is dying; Emacs needs to move

#76
post #37

Earlier quoted context omitted.

I agree - Emacs has to be rewritten on top of a modern rendering engine!

They did. It is called 'Eclipse'.

Just not the same. Adding functionality to Eclipse is a "project". In Emacs, it's just some code and an eval-last-sexp away.

Re: Bzr is dying; Emacs needs to move

#77
post #67
post #24

The important take-away here isn't the relative merits of each DVCS, but that bzr is not used by anybody any more, and it is impeding the uptake of new contributors to Emacs.

Compared to the decision (and ability) to contribute to Emacs, the choice of DVCS seems to be rather unimportant.

Ten (edit: even five!) years ago I'd agree with you. Back then a source control system was a piece of software you used for keeping a versioned history of your work and to enable you to collaborate with coworkers or friends. It was a tool.

Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on?

Re: Bzr is dying; Emacs needs to move

#78

wow. please, please, you Emacs/LISP gurus out there: make a working modern package manager and integrate the browser like lighttable does. and perhaps rewrite emacs from scratch so that the source code makes sense in today's world not in 1980's world. unfortunately lighttable is staying closed for much too long, but something like it is desperately needed.

>make a working modern package manager package.el works great. >integrate the browser That may actually be possible in the future, see http://www.emacswiki.org/emacs/EmacsXWidgets >perhaps rewrite emacs from scratch That is just silly. The current Elisp interpreter might be replaced with an Elisp implementation on top of the Guile VM. That would be quite the big upgrade, technically speaking. >unfortunately lighttabl…

This XWidgets project for Emacs has a rather unfortunate name, given that there is already a well-known GUI toolkit named wxWidgets.

Re: Bzr is dying; Emacs needs to move

#79
post #67
post #24

The important take-away here isn't the relative merits of each DVCS, but that bzr is not used by anybody any more, and it is impeding the uptake of new contributors to Emacs.

Compared to the decision (and ability) to contribute to Emacs, the choice of DVCS seems to be rather unimportant.

The impression I have is that bzr is just another roadblock between a potentially interested novice and a patch accepted into the Emacs source.

(It's not by far the largest one, though, and while I think esr has a point, I also think it'd be of help for some of the current Emacs developers to publish a "How to start hacking Emacs" document, for the benefit of people like me who would love to contribute but who have absolutely no idea where or how to start.)

Re: Bzr is dying; Emacs needs to move

#80

Earlier quoted context omitted.

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Git won due mainly to Linus personnality and the rise of "social coding" via github. Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Bet bitkeeper regretted that decision...

If I recall, the zeitgeist then was that bitkeeper was a necessary evil. My guess is that git would have come into being eventually in any circumstances short of bitkeeper becoming free software, and maybe even then. Distributed change management is such a critical component of the kernel development process (especially for Linus and the other maintainers) that relying on someone else's software seems suboptimal.
Post reply on HN