Huh. This works for both -t and -c in emacsclient, with a vanilla build of pre-24.4. It didn't for ages, so thanks for getting me to check this out again!
I'm not very familiar with OS X, and I've had a lot of trouble finding the magic invocation that'll get an Emacs daemon running with the same behavior to which I'm accustomed on Windows and Linux. This looks like it should do the trick, thanks! Now if only I could get emacsclient to behave sensibly in the dock, I'd really be cooking with fire...
I wish I could muster the energy to figure out how going that particular route is flawed. I just know that it's one of the ones I tried, and I learned the hard way that it's got problems.
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.
;; 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.
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.)
If you're on a Mac (as I am) it leaves an Emacs application running (complete with menu bar and app switcher icon) that you can't interact with. But otherwise, --daemon works great.
I was really impressed by elm, but I strongly prefer working with a library that provides some of the features without transpiling. If anyone else is interested, I'm looking for some help with my project: https://github.com/jlatt/frp.js
Do you have time to explain why bacon is better than Reactive Extensions, and thus the only frp library for JavaScript that you chose to link to? I don't have too much experience with frp in general (primarily just the Reactive Extensions for .NET), and even less with JavaScript implementations, so I'm not really in a position to begin making the comparison.
I do not understand why these metaphorical articles persist. They do not help anyone understand the procedure, which is simple:
- Walk the commit tree backwards to the specified rebase point, writing each commit as a temporary diff file.
- Set the current working space to the rebase target commit/hash/tag like `git reset --hard $commit`.
- Apply each diff file in forwards order (that's the reverse of the way diffs were generated in the first step).
Rebase is just a good shorthand for moving sequences of commits and (potentially interactively) resolving conflicts along the way.
Based on your reaction, I am guessing you have never faced a serious illness like this with tedious, painful treatments. The senseless statistically unlikely occurrence of cancer in a young person is almost guaranteed to produce overwhelming anger. It's natural to express this, especially in the face of doubts.
source: I am 30. I am days from finishing a year of radiation, surgery, and chemo for cancer.
Well, I had similar thoughts to mehwoot's opinions. Doctors generally need to set expectations low. Some might not have the best bedside manner in doing so, but I feel like it's better than overpromising and underdelivering.
source: I am 42, and I had cancer when I was 16 (very similar to Lance Armstrong's prognosis, minus the brain cancer) and again when I was 37.
I agree. I think that this sort of thing is going to produce a "me against the world" mentality, and so I understand why these reactions occur. But although I understand it, I don't think it is right to say "fuck you" to the doctor who treated you, unless there is real cause for it. Their job is already hard enough.