Emacs: The Editor for the Next Forty Years [video]
21–30 of 272 posts
Re: Emacs: The Editor for the Next Forty Years [video]
#22Emacs - the editor that STILL doesn't have a simple way to duplicate the current line?
Re: Emacs: The Editor for the Next Forty Years [video]
#23Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…
Spending time on your tools instead of your work is not a sign that you need to change your tools - it's a sign that your work sucks.
As with everything (programming languages, build tools, optimization, etc.) there are people who go much further into the rabbit hole of text editors than you could practically justify in your own work, but 1) they might be doing it for some intrinsic satisfaction rather than out of delusion, and 2) thank goodness for people like that, because they build and improve a lot of the software we benefit from.
Re: Emacs: The Editor for the Next Forty Years [video]
#24Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…
I think this covers work of most programmers. Doesn't matter if time is spent writing editor config or production code...
Re: Emacs: The Editor for the Next Forty Years [video]
#25Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…
Spending time on your tools instead of your work is not a sign that you need to change your tools - it's a sign that your work sucks.
If you wonder why a woodworker hasn't finished the chair, a completely valid answer is "all the edged tools you gave me were dull".
Re: Emacs: The Editor for the Next Forty Years [video]
#26Emacs - the editor that STILL doesn't have a simple way to duplicate the current line?
Different editors have different patterns of usage. I find I roughly speaking never duplicate lines, so why would this be a problem?
Or when debugging, I don't want to change the old code, so I copy the line, comment it out, and work with the duplicated line.
You've never had to do that?
Re: Emacs: The Editor for the Next Forty Years [video]
#27Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…
But I mean, that's not Emacs fault?
Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.
Re: Emacs: The Editor for the Next Forty Years [video]
#28So the slides say... > Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system. Is that really true? I've really enjoyed concurrency in D. http://jordi.inversethought.com/blog/advent-of-d/#day18 How much better can it be? And yes, D's concurrency is also based around types.
Re: Emacs: The Editor for the Next Forty Years [video]
#29(from the slides) >I learned Emacs in September, 1983 >It is now November, 2019 >...that’s over thirty six years! >An amazingly long time. Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it. I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental im…
Re: Emacs: The Editor for the Next Forty Years [video]
#30So the slides say... > Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system. Is that really true? I've really enjoyed concurrency in D. http://jordi.inversethought.com/blog/advent-of-d/#day18 How much better can it be? And yes, D's concurrency is also based around types.
Rust guarantees that a data-race is a compilation error.
D.. does not guarantee anything.. a data-race won't even give you a run-time error..
So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better.
FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g. Java doesn't guarantee that either).