4 ms·
>Emacs continually being changed, any setup that works will eventually stop working Any specific example of Emacs being changed to break your workflow?
by alex_smart 5y ago
>Emacs continually being changed, any setup that works will eventually stop working
Any specific example of Emacs being changed to break your workflow?
- bborud 5y agoGo support is one example. If you set up Emacs to provide decent support for Go at different times between 2015 (when I started using Go) and today, the setup would probably last an average of 18 months or so before you lose something significant and had to sit down and bodge something together to get some replacement for functionality that just died. I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.
- alex_smart 5y agoCould that have to do something with changes in go tooling (something that you alluded to in your original comment) rather than emacs itself? I am sorry I am not familiar with the go ecosystem at all. In my own experience, emacs developers generally have the exact opposite approach and strongly resist any changes that may break existing user workflow. Of course, externally maintained packages might take a different approach because they are developed independently of emacs. Even if you are not yourself interested in emacs development, you can contribute by just making bug reports for these missing features or breaking changes in the packages that you use. That's just being a conscientious open source citizen.
- bborud 5y agoMost certainly. Go tooling and some of the usage has evolved quite a bit since 2015.