Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs, naked

bzg.fr

Post reply on HN
Print view View original

121–130 of 201 posts

Re: Emacs, naked

#121

Post by klibertp »

aaronem wrote: post #87
ics wrote: post #78

Earlier quoted context omitted.

If you accidentally quit the Emacs GUI, does it still kill the daemon?

If you run it with --daemon, the server process doesn't create a frame of its own, but only listens for connections from emacsclient instances; IIRC it also rebinds C-x C-c to delete-frame (also available at C-x 5 0), and the daemon process stays alive through everything short of M-x kill-emacs or similar.

I have this:

    ;; schedule starting of Emacs server after everything else is loaded (5 min
    ;; *should* be anough for startup :))
    (run-at-time "5 min" nil 'server-start)
in my .emacs - this way I get both a window and a "daemon" server for use with emacsclient. I think it dies if the first frame is closed, though.

Re: Emacs, naked

#122

Post by technomancy »

bza wrote: post #71
vsbuffalo wrote: post #67

As a long time emacs user (and lover) I wish RMS and other emacs developers would take his quote to heart more in emacs development. Emacs is shipped with too many things. Emacs finally has a really nice package manager, so I'd love to see a version with minimal default packages. Do I really need java-mode if I never, ever will use Java? Calc when I have R? SMTP support? No, I need absolutely none of this.

The current policy (as enunciated by Stefan Monnier, who took over as maintainer from RMS a few years ago) is for new packages to be added to the package archive unless there's a very strong argument for their providing core functionality. (Packages that already ship with Emacs are unlikely to be removed from the core, though.)

I've heard it's actually being considered to move org-mode and eshell into packages, provided the release process can be ammended to generate releases which include packages by default.

Re: Emacs, naked

#123

Post by klibertp »

onedognight wrote: post #113
mercurial wrote: post #25

Earlier quoted context omitted.

I try out emacs every few years. Every time, I get discouraged whenever I attempt to do something simple (change the theme, etc) by the amount of configuration necessary. I may try your repo, since it seems to have a lot of stuff already configured. The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.

> The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim. This just mean you are "doing it wrong". Your .emacs file should not be loading anything, but instead setting things to be loaded when needed using autoload, eval-after-load and auto-mode-alist.

Also make sure all your plugins are byte-compiled, this can shorten loading time significantly. Not a problem for elpa/package.el plugins, but I have quite a few plugins managed manually (I'm still not using el-get, shame on me) and the way I byte compile them all at once is to place a cursor on a directory with them in dired and issuing:

    C-0 M-x byte-recompile-directory
The C-0 prefix arg causes it to recompile everything without asking for confirmation for every file.

Re: Emacs, naked

#124

Post by technomancy »

sdegutis wrote: post #68
dotemacs wrote: post #48

Earlier quoted context omitted.

Are you sure that MELPA has issues? I've been running with it since it started and one thing that I can say about it is that its been a joy to use. Hats off to milkypostman & sanityinc for maintaining it. If you do have an issue, I suggest you open it on MELPA's GitHub issue page and I'm pretty confident that you'll get a quick response. As for tweaking Emacs' config, yea, I have to admit, I've spent time on it too a…

The issue Melpa has is that it builds from HEAD, whereas many package authors treat HEAD as a working state that should not be used directly. Melpa doesn't (or didn't last time I checked) have support for building off tags or non-master branches, which would solve this. And if I remember correctly, when I raised this issue, he disagreed on some philosophical grounds. So it's an inherent problem in Melpa.

On IRC we get a steady stream of confused users (in both the #emacs and #clojure channels) who added melpa because some library recommended it in their readme and they didn't realize it would cause every package they use to also pull from the unstable branch. It is a huge support headache.

However, these days I only very rarely find packages that aren't available on Marmalade. When I do, it's usually enough to ask the maintainer nicely and they start publishing to Marmalade; it's not a difficult process by any means.

Re: Emacs, naked

#125

Post by klibertp »

astrobe_ wrote: post #95
mercurial wrote: post #25

Earlier quoted context omitted.

I try out emacs every few years. Every time, I get discouraged whenever I attempt to do something simple (change the theme, etc) by the amount of configuration necessary. I may try your repo, since it seems to have a lot of stuff already configured. The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.

I switch between Vim and Emacs depending on mood. It's a very hard deal: Emacs is a plateform that can do a lot of things besides editing, but it requires a lot of configuration fiddling, and is a bit too slow on the old machine on which I'm using it (must be a single core Pentium with Mandriva 9). Vim has a lot of things right off the box and is fast, but you have to use other programs to have a comfortable environm…

As for customize-option, if you don't want options to clobber you main init file you can do this:

    (setq custom-file "~/.emacs.d/custom.el")
    (load custom-file)
It's good for version control and for separating manual changes from customizations.

Re: Emacs, naked

#126

Post by TeMPOraL »

aaronem wrote: post #101
TeMPOraL wrote: post #63

Earlier quoted context omitted.

Nyan Cat endorses this plugin! https://dl.dropboxusercontent.com/u/216352/weather.png

Awesome! Mind if I grab a copy of this image, to use with whatever attribution you like, on the repo README? I don't use nyan-mode myself, and it'd be nice to have the screenshot to show people who find the repository.

Sure, go ahead :).

I'll put link to and/or a screenshot of your project somewhere in the Nyan Mode page/readme, as you wrote it was inspired by a comment about Nyan Mode ;).

Re: Emacs, naked

#127

Post by technomancy »

mixedbit wrote: post #107

Are there usability reasons for a dark text on a light background being default in almost all editors?

It depends on the lighting of the room you're in. In a well-lit room or outside (I love hacking outdoors) a light background will reduce eye strain, but when it's darker around it's less suitable. In any case, it's always easier to darken a light screen than to make a dark screen brighter given that you rarely see laptop screens brighter than 300 nits.

Re: Emacs, naked

#128

Post by breadbox »

claudius wrote: post #120
__david__ wrote: post #104

Earlier quoted context omitted.

You don't get as many color choices and you don't get as many key bindings. "C-M-%" is pretty much impossible in the terminal. You have to do "M-x query-replace-regexp", or make some other custom binding.

You can hit Esc before the combination to fill in for M and then it is just C-S-5 for me, which is certainly doable?

In some (most, I thought, but maybe I'm wrong) terminals, you can only use the control key to generate an actual control character -- i.e. one of ASCII 0-31. The ctrl key basically unsets bit 64 from the typed key, so ctrl-A through ctrl-Z generate ASCII 1-26, ctrl-@ generates ASCII 0 (though traditionally ctrl-spc gives this as well), and ctrl with [ \ ] ^ _ generate the remaining ASCII 27-31. Ctrl-? sometimes generates ASCII 127 (pretending that ctrl actually subtracts 64 instead of unsetting the bit), but otherwise there are no remaining ASCII values left for such extensions as ctrl-%.

Re: Emacs, naked

#129

Post by aaronem »

klibertp wrote: post #121
aaronem wrote: post #87

Earlier quoted context omitted.

If you run it with --daemon, the server process doesn't create a frame of its own, but only listens for connections from emacsclient instances; IIRC it also rebinds C-x C-c to delete-frame (also available at C-x 5 0), and the daemon process stays alive through everything short of M-x kill-emacs or similar.

I have this: ;; schedule starting of Emacs server after everything else is loaded (5 min ;; *should* be anough for startup :)) (run-at-time "5 min" nil 'server-start) in my .emacs - this way I get both a window and a "daemon" server for use with emacsclient. I think it dies if the first frame is closed, though.

You can actually just put

    (server-start)
at the end of your init file, and it'll behave more or less as you intend; if you've got a lot of stuff hanging off after-init-hook, you might do well to hang server-start off it as well.

That said, yeah, it will create a window which if killed will shut down Emacs, so I tend to prefer invoking it with the --daemon option instead; that way, I don't have to worry about accidentally killing Emacs if I kill the wrong frame. (I also call server-start in my init file, but I'm not actually sure that is necessary when invoking Emacs with --daemon.)

Re: Emacs, naked

#130

Post by klibertp »

fafner wrote: post #31
anuragramdasan wrote: post #11

Earlier quoted context omitted.

What line numbering plugin is this? Looks very similar to vim numbers. I've been trying to find something like that for emacs for a while now. All I found wasLinum mode, which clutters the UI and doesnt give relative line numbering.

Why do you want line numbers next to your code at all? Aren't they just visual clutter? The current line number is shown in the mode-line anyway.

Relative line numbers are especially useful when you have mis- or not configured moving by paragraphs/defuns/classes/etc. for some particular mode. C-16 C-p will move the point 16 lines up, for example, supposedly exactly where you want it to be. But that's not the use case I need line numbers for - actually, well configured movement commands + isearch + ace-jump + iy-goto-char + occur is a combo which makes relative line numbering completely unnecessary.

I use (non-relative) line numbers quite often though, and it when I need to tell my colleague that there is this function in some file, on line 323, with a some interesting statement between lines 330 and 336. This makes it extremely easy for them to get to where I am and see exactly what I see; and on the other hand I don't need to move point to those three lines to read their numbers or - absolutely nightmarish - to count the positions manually - they are just there, for me to see.

It would be better to show and hide linum with some simple binding, but I'm already used to them, so it's not a big deal for me.

Post reply on HN