551–560 of 782 posts
Earlier quoted context omitted.
Perhaps adding JavaScript to the list of languages that you can extend Emacs with would be a good start - https://www.emacswiki.org/emacs/CategoryExtensionLanguage
Emacs Lisp is a much better language than JavaScript, and that goes double for extending Emacs. Emacs Lisp is the reason for Emacs being such a cohesive ecosystem. JavaScript would be a major mistake.
Earlier quoted context omitted.
Don't forget: New employee 6 workflow at company X: 1. Install Spacemacs, don't bother fiddling with the config 2. Spend a few hours working through the tutorial or reviewing the excellent docs [1] 3. Work. Become a better developer [2]. [1]: https://www.spacemacs.org/doc/DOCUMENTATION.html [2]: https://blog.osteele.com/2004/11/ides
1. Install Spacemacs. 2. Observe a flurry of errors every time you start emacs. Ignore and hope it works because no idea how to fix any of it. 3. Find, among a million others, the command that seems to do what exactly what you want. Command gives an error. Dunno how to debug. 4. Watch emacs features that should work ootb not work because spacemacs or evil or one of the three bazillion packages did something that brok…
While Spacemacs is an admirable effort, I think it misses the point: Emacs is an editor for power users from another era, so it requires huge effort by the user to become truly productive by todays standards. Trying to create layers upon layers of "friendlines" and eye candy is not going to solve the complexity.
I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.
vim is a similar rabbit hole, maybe less deep.
The real question is: can VS Code make you productive enough in less time?
Earlier quoted context omitted.
I was in your shoes about 2 weeks ago. I also learned vi first and have been using it regularly for a couple of years now but was curious about emacs. At home, I installed spacemacs which uses vi keybindings. For work due to some security stuff I went with vanilla emacs, with evil mode installed (evil also adds vi keybindings). I spent 2 evenings picking it up and getting my dot files in order. I primarily wanted to…
Thanks, I might give that a shot. I just installed vim-orgmode to see if I could get a little emacs goodness in vimland. I usually use a custom markup language and vim syntax definitions to keep track of my notes, so this may get me to convert my notes to org mode. The thing I'm most excited about is shell-mode. For years I've wanted to be able to drop to a shell in vim and visually cut/paste the window. From what I…
NeoVim is 100% compatible and has a pretty decent terminal buffer with full (read-only) Vim controls. Nowadays I prefer running it in a terminal multiplexer though.
Emacs' terminal mode doesn't have ncurses support which leads to pretty much all interactive terminal applications to break.
I agree that aesthetics have importance, but they should complement what emacs is and how its used, not make it pretend to be something else. Emacs is a powerful tool, that isn't going to change-- so it should look like one.
There are already many editors with a "sleek look"! So users that want that are already using one. They won't switch to emacs if emacs adopts a sleek look, especially because emacs' internals won't match the drapery.
Emacs epitomizes the Hole Hawg in Stephenson's excellent "In The Beginning Was The Command Line" (https://steve-parker.org/articles/others/stephenson/holehawg...). It should lean into that. The users it loses from being overly industrial are ones mostly wouldn't stay, but the ones it gathers will stay because there are few alternatives. There is always a role in the world for serious tools.
Earlier quoted context omitted.
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. I've been writing software for ~24 years, and I can understand the need for this in the past. Now, I ju…
Somethings I find more convenient with Emacs than modern IDEs: -Remote file editing with Tramp: This is much better even than using vi/pick over a terminal. -Very flexible kill ring copy paste mechanism: can do complicated text manipulations with easy access to copy paste history. -Easy macro recording and playback. -Very flexible windowing: can show even multiple windows with the same file, even synchronized scrolli…
Earlier quoted context omitted.
Re copyright, what would you prefer? Alternatively, what would you even do with the copyright to your fixes and additions to GNU emacs?
a lot of contributors/developers are bothered by the fact that they have to play ball with copyright laws, at all. it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL. at the end of the day a lot of…
I see why you might go with Apache, or MIT, or even straight public domain licenses. But as a maintainer, I would not accept a contribution which is not properly licensed, or which is licensed in a way not compatible with the project's license. Usually such a contribution is less valuable than the rest of the project, so there's no point to introduce a real legal risk of project's closure for the sake of such a contribution.
Earlier quoted context omitted.
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. I've been writing software for ~24 years, and I can understand the need for this in the past. Now, I ju…
Somethings I find more convenient with Emacs than modern IDEs: -Remote file editing with Tramp: This is much better even than using vi/pick over a terminal. -Very flexible kill ring copy paste mechanism: can do complicated text manipulations with easy access to copy paste history. -Easy macro recording and playback. -Very flexible windowing: can show even multiple windows with the same file, even synchronized scrolli…
I'd also add:
- incredibly ergonomic file-system navigation (helm+projectile)
First thing I notice when I use VS Code is... Do I really have to click and click and click and click to navigate from one file to another? Why does VS Code show pop ups all over the place?
I really like how I can navigate the file system from emacs using fuzzy searches when I need them, and how the same fuzzy-search approach helps me also navigate all my buffers, works remotely over tramp, etc.
I use emacs and have for a really long time. Unfortunately, I don't recommend it to anyone because I think the costs of learning it outweigh the benefits. When I read this article, I was surprised that my gripes don't overlap much with those listed in the article. I do really like the idea of "new user detection", which would take a user through a short configuration process if the .emacs file was missing. I think my…
Choosing an editor like emacs or vi is a major decision which will have long-lasting effects. I love vi, and the homerow movement keys are now hard-wired into my brain, so much so that using 'normal' applications is noticeably frustrating. Sure, I can try to add plugins to everything, but that only goes so far and requires a lot of setup work on every new computer or VM. That said, the old school editors bring plenty…
So it is possible to get Emacs to (mostly) behave like Vim, but it includes installing a couple plugins, spending time to set many additional keyboard shortcuts(especially when you have an extensive .vimrc already) and also completely ripping out and replacing Emacs' automatic indentation functionality because I find its behaviour actively counterproductive.
My two cents are that if you're really comfortable with Vim's or Emacs' approach you may not like the other one, simply because their main difference is that approach to doing the exact same things. And the improvements will certainly not be proportional to the time invested.
New employee 1 workflow at company X: 1. Install VS Code 2. Click extensions and install language specific plugin 3. Work New employee 2 workflow at company X: 1. Install emacs 2. Try to install some source code indexing tool 3. Tool is missing 13 dependencies, so spend 4 hours finding, installing and configuring the dependencies. 4. Spend another couple hours reading non-existent to terrible documentation (documenta…
> The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone. The fact that you don't have one for VS Code shows that any modifications to make it better are too difficult and that you just have to make do with how it comes out of the box.
Edit: downvoting doesn't change reality
Earlier quoted context omitted.
This view is obviously biased against Emacs, but I don't disagree completely with the premise. As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you…
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. I've been writing software for ~24 years, and I can understand the need for this in the past. Now, I ju…
Despite being an expert Emacs user, I'm mostly in VS Code these days because it has syntax highlighting, git support, and linting out of the the box. But I always go back to Emacs when I need to transform a bit of text.
2. Comparing two text snippets, as opposed to files.
There are a small set of use cases where you want to look at every position where something has changed. You can open two buffers in Emacs and use compare-windows to walk through them. Since the IDEs are all file-oriented, they don't work for this case well.