Live data from Hacker News

The single most useful Emacs feature

stackoverflow.com

61–70 of 112 posts

Re: The single most useful Emacs feature

#61
post #55

Earlier quoted context omitted.

It takes about five minutes to take a library that isn't packaged and publish it on Marmalade, and then anyone can depend upon it. el-get made lots of sense back in the day when package.el only supported tromey.com, but now that there's a community repository I don't see the point.

OK. My old complaints against package.el were as follows: 1. Packages need to be updated manually by maintainers. I can't use package.el to install the master branch of my favorite project on GitHub, or an old snippet on EmacsWiki. 2. Marmalade (the community repository) has licensing requirements for package inclusion. Are those two assumptions incorrect?

> 1. Packages need to be updated manually by maintainers.

Yes, but considering uploading new versions can be done with M-x marmalade-upload-buffer, generally Marmalade encourages short release cycles. So there's not much reason to ever work from master unless you're hacking on it yourself, in which case you already have it checked out.

> 2. Marmalade (the community repository) has licensing requirements for package inclusion.

This is not specific to Marmalade since Emacs itself has licensing requirements. Every elisp library is a derivative work of Emacs itself, therefore it must be distributed under the same license.

EDIT: Perhaps you're thinking of elpa.gnu.org? That repository requires copyright assignment for libraries to be included, but Marmalade does not.

Re: The single most useful Emacs feature

#62
post #5

hi-lock-mode! Hi-lock lets you specify regexes to highlight anywhere in a file; it's like domain-specific font-lock. It's astoundingly useful in code review. For instance, given a giant blob of J2EE web handler code, I can eyeball one handler, recognize the annotation mapping the method to URL syntax, and then punch in a hi-lock regex to light up similar annotations everywhere in the file, then glance through the who…

Out of curiosity, do you use usually emacs for J2EE code? I am an emacs user, but have been doing some J2EE stuff for the last few months, and have been getting really annoyed by the IDE's lately, and I was wondering if it was a wise choice to go with emacs for Java too.

For Java work, I use Emacs and command line tools.

Re: The single most useful Emacs feature

#63
post #36

Earlier quoted context omitted.

It's not exactly luck. Until today this question hasn't been active since 2009, when opened-ended questions were permitted. Now that it's been bumped it'll be closed shortly.

Closed now. I'm actually surprised that someone hasn't gone through all the older questions looking for stuff to close, given how rigid their mods tend to be.

[deleted]

Re: The single most useful Emacs feature

#66
post #55

Earlier quoted context omitted.

OK. My old complaints against package.el were as follows: 1. Packages need to be updated manually by maintainers. I can't use package.el to install the master branch of my favorite project on GitHub, or an old snippet on EmacsWiki. 2. Marmalade (the community repository) has licensing requirements for package inclusion. Are those two assumptions incorrect?

> 1. Packages need to be updated manually by maintainers. Yes, but considering uploading new versions can be done with M-x marmalade-upload-buffer, generally Marmalade encourages short release cycles. So there's not much reason to ever work from master unless you're hacking on it yourself, in which case you already have it checked out. > 2. Marmalade (the community repository) has licensing requirements for package i…

OK. I was wrong about licensing requirements.

I think you're slightly confused about el-get's purpose: it isn't to replace package.el. el-get supplements package.el and provides options for people who want to run the latest and greatest versions of libraries, or who can't be bothered to monitor the odd elisp snippet and update Marmalade every time it changes.

Personally, I find el-get recipes so easy to install and create that I never use package.el at all, but that isn't the goal of el-get developers.

Here is an example recipe for el-get. I haven't tried creating uploading anything to Marmalade yet, so I can't compare the ease of use.

https://github.com/dimitri/el-get/blob/master/recipes/evil.r...

One last note: You may find that el-get lowers the barrier for contributing to libraries. If you find the odd bug in a mode you use, the source code is always checked out in ~/.emacs.d/el-get and it would be practically criminal to not fix it. With package.el, you have to reinstall the library first.

Re: The single most useful Emacs feature

#67
post #56

The kill ring. I would marry the kill ring and have its babies. Why have other editors not adopted this? Have they?

I've had success with http://jumpcut.sourceforge.net/ before. I just have been using emacs for almost everything so have not tried this with Lion.

Re: The single most useful Emacs feature

#68
post #66

Earlier quoted context omitted.

> 1. Packages need to be updated manually by maintainers. Yes, but considering uploading new versions can be done with M-x marmalade-upload-buffer, generally Marmalade encourages short release cycles. So there's not much reason to ever work from master unless you're hacking on it yourself, in which case you already have it checked out. > 2. Marmalade (the community repository) has licensing requirements for package i…

OK. I was wrong about licensing requirements. I think you're slightly confused about el-get's purpose: it isn't to replace package.el. el-get supplements package.el and provides options for people who want to run the latest and greatest versions of libraries, or who can't be bothered to monitor the odd elisp snippet and update Marmalade every time it changes. Personally, I find el-get recipes so easy to install and c…

> Personally, I find el-get recipes so easy to install and create that I never use package.el at all, but that isn't the goal of el-get developers.

That's my main objection. If you write an el-get recipe, it benefits el-get users. If you use package.el, all users (of Emacs 24+) benefit.

Re: The single most useful Emacs feature

#69
post #66

Earlier quoted context omitted.

OK. I was wrong about licensing requirements. I think you're slightly confused about el-get's purpose: it isn't to replace package.el. el-get supplements package.el and provides options for people who want to run the latest and greatest versions of libraries, or who can't be bothered to monitor the odd elisp snippet and update Marmalade every time it changes. Personally, I find el-get recipes so easy to install and c…

> Personally, I find el-get recipes so easy to install and create that I never use package.el at all, but that isn't the goal of el-get developers. That's my main objection. If you write an el-get recipe, it benefits el-get users. If you use package.el, all users (of Emacs 24+) benefit.

You made me laugh :)

You're right, of course, but only because the Emacs community chose an inferior solution to begin with. Let the better package manager win. Don't tell people not to use el-get because it is so convenient that they wont use package.el anymore.

Re: The single most useful Emacs feature

#70
`C-u SPC` which pops the mark. This allows you to go back to different places in your buffer quickly. For example, if you are editing a program and need to add an import statement, you could do it like this: `C-SPC M-If you are using transient-mark-mode, you can use `C-SPC C-SPC` to active and deactive the highlighted region. That'll still leave a mark.
Post reply on HN