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

How to open a file in Emacs: a story about Lisp, technology, and human progress

murilopereira.com

Post reply on HN
Print view View original

51–60 of 97 posts

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#51

Post by tom_ »

nn3 wrote: post #36
bjeds wrote: post #6

Earlier quoted context omitted.

In no way do I want to come off as rude with this comment, but to me what you are saying is not at all different from "when I was young I used to work out and eat healthy... a couple of decades later, I just fund it all so exhausting". Customizing your computer environment is good. Eating healthy is good. None of those need to end up in a "rabbit hole". Everyone can be tired of life and give up due to exhaustion, but…

A super customized system is more like a pet. A mostly standard system with very limited tweaks is more cattle. Like the OP I used to be in the having "pets" category (including gigantic ~/.emacs), but these days I prefer cattle (defaults as much as possible)

Put your Emacs config in a git repo, and this problem goes away.

You don’t even have to stop there. I have a repo for my Emacs config, a repo for my Windows bin folder, a repo for my Unix shell stuff, and a repo for a bunch of cross-platform Python scripts I’ve written. Every computer I use regularly is super customised in exactly the same way as all the others. Takes about 10 minutes to get up and running.

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#52

Post by forrestthewoods »

PaulDavisThe1st wrote: post #50
macintux wrote: post #34

Earlier quoted context omitted.

That seems an ungenerous and quite broad interpretation of a fairly simple assertion. Even as much as I love Emacs, I would never fault someone for choosing a more productive tool now even if there’s a non-zero risk of something breaking in the future...because there’s always something that will break on any platform. Time spent being productive now is usually worth that risk.

The counter-point to that is that the world benefits more by someone choosing to actually fix whatever was wrong, rather than just switching platforms (or never choosing it in the first place because they came across the post on HN). The claim in the comment I was responding to appeared to me to be "hmm, Emacs has a problem, VSCode probably doesn't, I would rather use VSCode". It didn't seem to me to be written with…

> the world benefits more by someone choosing to actually fix whatever was wrong

Maybe.

I imagine at some point someone wrote ffap-guess-file-name-at-point to fix a problem. And the blog author solved a problem by disabling it without knowing what problem it maybe solved.

Problems eventually become complicated enough it’s not a binary fixed/broken, but rather a matter of trade-offs.

Open source and shared solutions are great. But they aren’t a silver bullet either.

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#53

Post by brundolf »

humanistbot wrote: post #4

When I was first getting into programming and computer science as a student, I was so into these kinds of super-customizable rabbit holes. My whole life pretty much centered around the keyboard and terminal. I was all in on knowing everything about the entire stack and making it do whatever it was I wanted. I'd spend hours to save a few keystrokes. That wasn't so much about the productivity trade-off as it was about…

I've gone through a similar transition with technology. I think the key is to separate the yak-shaving you do for fun, from the yak-shaving you actually need to do for productivity. Minimize the latter, and admit that the former really is just for fun, and don't do any more of it than you actually feel like doing (which can be zero).

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#54

Post by klodolph »

dan-robertson wrote: post #13
bjeds wrote: post #6

Earlier quoted context omitted.

In no way do I want to come off as rude with this comment, but to me what you are saying is not at all different from "when I was young I used to work out and eat healthy... a couple of decades later, I just fund it all so exhausting". Customizing your computer environment is good. Eating healthy is good. None of those need to end up in a "rabbit hole". Everyone can be tired of life and give up due to exhaustion, but…

A lot of emacs customisation ought to be unnecessary. And I think the yak shaving on one’s config isn’t really a great use of time (if you want it as a hobby then I guess that’s fine). Some examples of unnecessary customisation is the fact that the defaults of emacs so often ought to be changed. E.g. why does M-SPC do just-one-space instead of the strictly more powerful cycle-spacing (answer: probably a combination o…

> A lot of emacs customisation ought to be unnecessary. And I think the yak shaving on one’s config isn’t really a great use of time (if you want it as a hobby then I guess that’s fine).

I totally agree. The only reason I justify my Emacs customization is because I customize it very slowly, over years, and periodically remove things I don’t use any more.

It’s getting harder to justify now that alternatives like VS Code have a bucketload of features and working autocomplete without futzing around too much. It’s just that VS Code is so damn slow. Maybe better language server support will bring me back to Emacs as my daily driver in a couple years, or maybe I’ll be paying for CLion.

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#55

Post by brokenwallet »

brokenwallet wrote: post #41

This is a great post showing effective performance analysis. It's worth noting that Emacs's built-in way to find files (project-find-file) in a project does not suffer these performance issues. Try it, C-x p f. * project-find-file doesn't call expand-file-name for all 70k files (each of which involves a network roundtrip). * project-find-file will use "git ls-files" (see project--vc-list-files) rather than find (or e…

Update: I only just saw Part 2 of the post, which is fantastic too.

I like how it describes different tools by the different values they prioritise. I agree with the post's thoughts in the tradeoffs involved in Emacs's development.

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#56

Post by bmitc »

PaulDavisThe1st wrote: post #50
macintux wrote: post #34

Earlier quoted context omitted.

That seems an ungenerous and quite broad interpretation of a fairly simple assertion. Even as much as I love Emacs, I would never fault someone for choosing a more productive tool now even if there’s a non-zero risk of something breaking in the future...because there’s always something that will break on any platform. Time spent being productive now is usually worth that risk.

The counter-point to that is that the world benefits more by someone choosing to actually fix whatever was wrong, rather than just switching platforms (or never choosing it in the first place because they came across the post on HN). The claim in the comment I was responding to appeared to me to be "hmm, Emacs has a problem, VSCode probably doesn't, I would rather use VSCode". It didn't seem to me to be written with…

You shouldn't make so many assumptions. If you're confused, ask a clarifying question instead of going off of incorrect assumptions.

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#57

Post by Barrin92 »

oblio wrote: post #11
bjeds wrote: post #6

Earlier quoted context omitted.

In no way do I want to come off as rude with this comment, but to me what you are saying is not at all different from "when I was young I used to work out and eat healthy... a couple of decades later, I just fund it all so exhausting". Customizing your computer environment is good. Eating healthy is good. None of those need to end up in a "rabbit hole". Everyone can be tired of life and give up due to exhaustion, but…

Or you can, you know, just use VSCode, have fun coding what you actually want to code and use that spare time: a) learning Spanish to talk to that hot chick/dude b) traveling around the world c) doing whatever else you love to do besides coding

The tools that you use in your profession are a way to express yourself. That's true for guitarists who customise their guitars, truck drivers who customise their truck, tennis players with custom rackets and woodworkers with unique tools that often take countless of hours to make.

What they all have in common is that this level of customisation looks silly to the outside. Of course they could be 98% as good with something they bought off a quality store, but what they do is part of who they are and there arguably is a deeper satisfaction in that then going around hitting on hot dudes on holiday trips.

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#59

Post by bmitc »

PaulDavisThe1st wrote: post #25
bmitc wrote: post #20

Articles like this really trigger the imposter syndrome for me. I just have no patience for these type of things, and seeing others' both ability and patience to power through issues like this one, I just feel like an imposter. But these types of issues are why I've always given up on learning Emacs. When I can just install Visual Studio Code and the Remote - SSH extension and whatever else extension that I want to w…

You appear utterly convinced that VSCode will never demonstrate an obscure bug like the one discussed in TFA, or alternatively that if it does you'll be able to jump ship to some other tool. I don't share your confidence, and would prefer to know that such issues can be fixed with or without vendor participation.

There were two points in my comment. One was of feeling like an imposter, in that even as a software engineer I lack both the patience and skill to pull the debugging off the article showcased. It's both admiration and lament at the same time. The second point was that I personally prefer to altogether avoid issues like this if I can by selecting what I feel is the best available tool at the time. I have tried to use Emacs multiple times, and while this exact issue is not one I have encountered (I did say "these types of issues"), I have come across similar issues, especially with having Emacs talk to another computer or VM. Every time I have tried to get into Emacs, I end up hitting some barrier akin to these things, and so I resign myself to using Visual Studio Code, where then I get off to coding rather than trying to bend the environment to what I'd like. And it always seems that with Visual Studio Code it both does what I'd like and works without a million gotchas.

Visual Studio Code is not perfect, and I have had issues with it and expect more issues. However, they don't hit me as early as they seem to with Emacs, and that's an important distinction. The remoting extension is extremely seamless, and I have not seen an Emacs example of matching anything close to it.

It really comes down to personality. If I was a carpenter and had a broken hammer, I wouldn't go off rebuilding the hammer or designing one from scratch. I'd do my best to find someone else who's already built a hammer that works. That doesn't imply I never expect the hammer to never break.

> would prefer to know that such issues can be fixed with or without vendor participation

Visual Studio Code is open source and well-managed. I'd prefer that a solution be merged into the tool for everyone, rather than being buried in someone's .emacs file.

Re: How to open a file in Emacs: a story about Lisp, technology, and human progress

#60

Post by grzm »

bmitc wrote: post #59
PaulDavisThe1st wrote: post #25

Earlier quoted context omitted.

You appear utterly convinced that VSCode will never demonstrate an obscure bug like the one discussed in TFA, or alternatively that if it does you'll be able to jump ship to some other tool. I don't share your confidence, and would prefer to know that such issues can be fixed with or without vendor participation.

There were two points in my comment. One was of feeling like an imposter, in that even as a software engineer I lack both the patience and skill to pull the debugging off the article showcased. It's both admiration and lament at the same time. The second point was that I personally prefer to altogether avoid issues like this if I can by selecting what I feel is the best available tool at the time. I have tried to use…

> "the use of TFA"

Read it as the fine article or the featured article.

Post reply on HN