5 ms·

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 t

by bmitc 6y ago

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 work remotely and get on with life, it's really hard to justify the time one needs to spend with Emacs to bend it to your will.

PaulDavisThe1st 6y ago
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.
- macintux 6y ago
  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.
  - PaulDavisThe1st 6y ago
    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 much awareness of what the actual problem in TFA really was, nor with any real knowledge that VSCode actually would be more productive. It seemed to me to be more like "Ewww! Emacs has a bug, someone fixed it with a lot of obscure stuff, no thanks, VSCode here I come". I certainly respect that for many, VSCode will be a more productive platform when measured by the metrics that matter to them.
    - forrestthewoods 6y ago
      > 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.
    - bmitc 6y ago
      You shouldn't make so many assumptions. If you're confused, ask a clarifying question instead of going off of incorrect assumptions.
- bmitc 6y ago
  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.
  - grzm 6y ago
    > "the use of TFA" Read it as the fine article or the featured article.
  - PaulDavisThe1st 6y ago
    Your explanation involving containers/VMs makes a lot more sense to me than avoiding specific bugs when using Emacs' equivalent to VSCode's remoting extension. As a purely native developer, I have zero use for such things, but I can certainly appreciate that VSCode may have done a much better (or certainly, shall we say, a less historically indebted) version of this sort of functionality than Emacs. [ Edit: and yes, the featured article ]
grzm 6y ago
I think it's great that we have such a variety of editors and IDEs to choose from and find one that meets best meets our individual needs. Over the years I've used BBEdit, TextMate, IntelliJ, and Emacs for development. For the past couple of years it's been switching between the last two. I'm glad you've found VS Code to be a match for you. I've spent time configuring all of them to aid in development. ust like there's more than one hammer on the market, or more than one drill, each has its strengths and weaknesses. There have definitely been frustrating times configuring Emacs, but one of the reasons it's paid off over the years is that when I run into an issue, I can always dig into it and potentially fix it myself; and when I want to extend it to do sometime it can't do yet, I can do that, too. It's an investment, but it's one that I think has paid off, and will continue to pay off. Emacs has been applicable in more situations and environments than those other tools. (IntelliJ's tooling has been useful, but I've also run into bugs that have impeded my work, which I can't fix on my own because the source isn't open.) I also do a lot of work in Clojure, so Emacs Lisp isn't much of a jump. Admittedly this might not be the case for everyone. I think another big reason I've stuck with Emacs is that the cost of switching editors as they come along (I hear Atom is really nice, and people have been talking positively about Sublime for years) has a cost as well. Emacs is long in the tooth, which is a curse (Emacs Lisp is a really old lisp) and a blessing (it's unlikely to go away any time soon, and that time spent learning Emacs Lisp is going to continue to pay off). Please don't read this as apologia for Emacs or as a criticism of your choice, as it's neither. I'm just trying to add some context to how others may justify the time they've spent customizing Emacs.
- grzm 6y ago
  And I'll add that you don't need to limit yourself to just one. I do most of my text editing and development in Emacs, but when I'm working in Java, I'll use IntelliJ. I miss out on some of the key bindings and workflow I'm used to in Emacs, but for me the other features IntelliJ affords me when working with Java are worth it.
  - bmitc 6y ago
    I actually prefer to use the de facto IDEs for most languages, only deferring to something like Visual Studio Code or Emacs when those don’t exist.
legends2k 6y ago
It isn't as complex as it seems. You can choose to be at any point in the spectrum of yak shaving; keep doing it vs skip it altogether. I did the latter with vanilla Emacs. It works just like a regular GUI text editor e.g. Notepad, gedit, etc. Only when I wanted more power I dropped into customizing my .emacs. I balance myself between doing it often vs not doing it at all. Doing the above for 5 years I've a decent personal .emacs I take with me in a Git repo. Setting up takes less than 10 mins on any new machine.

by bmitc 6y ago

PaulDavisThe1st 6y ago

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.

macintux 6y ago
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.
- PaulDavisThe1st 6y ago
  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 much awareness of what the actual problem in TFA really was, nor with any real knowledge that VSCode actually would be more productive. It seemed to me to be more like "Ewww! Emacs has a bug, someone fixed it with a lot of obscure stuff, no thanks, VSCode here I come". I certainly respect that for many, VSCode will be a more productive platform when measured by the metrics that matter to them.
  - forrestthewoods 6y ago
    > 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.
  - bmitc 6y ago
    You shouldn't make so many assumptions. If you're confused, ask a clarifying question instead of going off of incorrect assumptions.
bmitc 6y ago
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.
- grzm 6y ago
  > "the use of TFA" Read it as the fine article or the featured article.
- PaulDavisThe1st 6y ago
  Your explanation involving containers/VMs makes a lot more sense to me than avoiding specific bugs when using Emacs' equivalent to VSCode's remoting extension. As a purely native developer, I have zero use for such things, but I can certainly appreciate that VSCode may have done a much better (or certainly, shall we say, a less historically indebted) version of this sort of functionality than Emacs. [ Edit: and yes, the featured article ]

grzm 6y ago

I think it's great that we have such a variety of editors and IDEs to choose from and find one that meets best meets our individual needs. Over the years I've used BBEdit, TextMate, IntelliJ, and Emacs for development. For the past couple of years it's been switching between the last two. I'm glad you've found VS Code to be a match for you. I've spent time configuring all of them to aid in development. ust like there's more than one hammer on the market, or more than one drill, each has its strengths and weaknesses. There have definitely been frustrating times configuring Emacs, but one of the reasons it's paid off over the years is that when I run into an issue, I can always dig into it and potentially fix it myself; and when I want to extend it to do sometime it can't do yet, I can do that, too. It's an investment, but it's one that I think has paid off, and will continue to pay off. Emacs has been applicable in more situations and environments than those other tools. (IntelliJ's tooling has been useful, but I've also run into bugs that have impeded my work, which I can't fix on my own because the source isn't open.) I also do a lot of work in Clojure, so Emacs Lisp isn't much of a jump. Admittedly this might not be the case for everyone. I think another big reason I've stuck with Emacs is that the cost of switching editors as they come along (I hear Atom is really nice, and people have been talking positively about Sublime for years) has a cost as well. Emacs is long in the tooth, which is a curse (Emacs Lisp is a really old lisp) and a blessing (it's unlikely to go away any time soon, and that time spent learning Emacs Lisp is going to continue to pay off). Please don't read this as apologia for Emacs or as a criticism of your choice, as it's neither. I'm just trying to add some context to how others may justify the time they've spent customizing Emacs.

grzm 6y ago
And I'll add that you don't need to limit yourself to just one. I do most of my text editing and development in Emacs, but when I'm working in Java, I'll use IntelliJ. I miss out on some of the key bindings and workflow I'm used to in Emacs, but for me the other features IntelliJ affords me when working with Java are worth it.
- bmitc 6y ago
  I actually prefer to use the de facto IDEs for most languages, only deferring to something like Visual Studio Code or Emacs when those don’t exist.

legends2k 6y ago

It isn't as complex as it seems. You can choose to be at any point in the spectrum of yak shaving; keep doing it vs skip it altogether. I did the latter with vanilla Emacs. It works just like a regular GUI text editor e.g. Notepad, gedit, etc. Only when I wanted more power I dropped into customizing my .emacs. I balance myself between doing it often vs not doing it at all. Doing the above for 5 years I've a decent personal .emacs I take with me in a Git repo. Setting up takes less than 10 mins on any new machine.