Live data from Hacker News

Emacs is the 2D Command-line Interface

hongchao.me

91–100 of 180 posts

Re: Emacs is the 2D Command-line Interface

#91
post #83
post #36

Earlier quoted context omitted.

VSCode will likely get you to 80% productivity compared to Emacs pretty fast. The question how easy is to get from 80% to 100%. It is like a prototype vs. polished code: you can create something that provides 80% of the result over a weekend and then spend 2 years polishing it, to get remaining desired functionality. For example, I'm sure VSCode does git but does it as well as Magit? Everyday things can be done on mu…

> Every keystroke is a programmable command in Emacs. VSCode is close. VSCode does not even have keyboard macros. Either "every keystroke is a programmable command" is not exactly what is going on in VSCode, or the VSCode users do not exactly understand what this "Open Source" thing is, because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490

> VSCode does not even have keyboard macros.

https://marketplace.visualstudio.com/search?term=macros&targ...

> Either "every keystroke is a programmable command" is not exactly what is going on in VSCode

There are commands (JavaScript-Functions) which one can be bind to keys. But who knows whether all keys have a command behind them? An with a GUI, I wondern whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.

> because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490

Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.

Re: Emacs is the 2D Command-line Interface

#92
post #52

Earlier quoted context omitted.

Emacs has a lot of amazing extensions! Magit is unparalleled for working with Git. The problem is that they break more frequently, in my experience. The very fact that I have to install a 3rd-party DSL to have a sane package management experience is beyond the pale from a usability perspective.

Clunky interface aside (a given with emacs), what's wrong with package-list-packages and customize? It's essentially no different to installing and configuring packages in vscode. Why do you think use-package is necessary?

Tying configurations and customizations to a package, inter-package configurations, etc. are taken care by use-package. Disable a package, its related configuration is also cleanly disabled.

Re: Emacs is the 2D Command-line Interface

#94
post #83

Earlier quoted context omitted.

> Every keystroke is a programmable command in Emacs. VSCode is close. VSCode does not even have keyboard macros. Either "every keystroke is a programmable command" is not exactly what is going on in VSCode, or the VSCode users do not exactly understand what this "Open Source" thing is, because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490

> VSCode does not even have keyboard macros. https://marketplace.visualstudio.com/search?term=macros&targ... > Either "every keystroke is a programmable command" is not exactly what is going on in VSCode There are commands (JavaScript-Functions) which one can be bind to keys. But who knows whether all keys have a command behind them? An with a GUI, I wondern whether all interactions are bindable commands. Mouse-Inter…

Since you were too lazy to check, I did the work, and I can say there is nothing that provides keyboard macros in the search link you posted.

Here is the documentation that explains keyboard macros: https://www.gnu.org/software/emacs/manual/html_node/emacs/Ke...

> But who knows whether all keys have a command behind them?

Yes, they literally do in Emacs. That is the whole point of this discussion.

> An with a GUI, I wondern [sic] whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.

Mouse events result in commands. You can record them as part of keyboard macros, although I have never had a need to do that and cannot think of one.

> Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.

Let me explain how this "Open Source" thing works: you can submit a patch, you don't need to "push hard" on Daddy Microsoft.

Re: Emacs is the 2D Command-line Interface

#95

Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity. Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, o…

Don't get me wrong, a lot of these problems aren't really Emacs's fault. Jetbrains puts a lot of money and effort into its IDEs. If some commercial or nonprofit entity was actually committed to developing and maintaining elisp packages providing superb language support, then Emacs would have it. Maybe language support will get better with LSP; anyone know how that is going in the emacs world?

I use Emacs professionally for Ruby development and LSP (Solargraph) is a huge part of what makes it work smoothly.

I also do a lot of hobby Flutter/Dart development and the same is true there.

Languages that I’ve tried to work with this way but failed include Java, Kotlin, Swift, and C#. But I could see any of them working great if the LSP implementation was robust enough.

Re: Emacs is the 2D Command-line Interface

#96
post #6

I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code, which is vastly more popular. I think what made VSCode popular was the availability of many high-quality extensions for major languages. Unfortunately, my experience with Elisp packages is that they tend to be much less stable. This is changing some with LSP mode, of course, but I think the Emacs community would do well…

This happened all the time at a couple of companies I worked for. The advantage there however was the customer who filed the bug report couldn’t see all the emails bouncing around between teams over who was to blame and who needed to fix the problem.

Re: Emacs is the 2D Command-line Interface

#97

Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity. Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, o…

As usual it boils down to the right tool for the job.

Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed.

Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.

Re: Emacs is the 2D Command-line Interface

#98

Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity. Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, o…

Don't get me wrong, a lot of these problems aren't really Emacs's fault. Jetbrains puts a lot of money and effort into its IDEs. If some commercial or nonprofit entity was actually committed to developing and maintaining elisp packages providing superb language support, then Emacs would have it. Maybe language support will get better with LSP; anyone know how that is going in the emacs world?

I use lsp for python and c++. It's usually good, but lsp will sometimes have the clang seever crash repeatedly, which can usually only be fixed by restarting emacs.

I do debugging with gdb, which is rather nice actually (you can easily set breakpoints and it will show the pointer walking through all the files), but even there there are some rough edges (the in/output buffer will show up on all frames for example, and will pop up, closing the gdb buffer itself)

All in all this is a rather good setup imo, with a little polishing I'd never have to use anything else I think. Maybe I'll try out Doom again, it might be that my config is contributing to the unstableness...

Re: Emacs is the 2D Command-line Interface

#99

Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity. Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, o…

Use Emacs in simpler way like you use other editors and it will always work. Use it in complex way and you will stumble upon plethora of troubles. That is feature, not bug.

Can you clarify this? It makes no sense to me, and I'm a daily emacs user. How is that a good thing?

Re: Emacs is the 2D Command-line Interface

#100

Earlier quoted context omitted.

It does actually sound like things have improved since when I started moving away from primary development in emacs circa 2016-17. It might be time to revisit my config file. I still end up coding in emacs a lot of the time.

Emacs 27 helped a ton with language server performance, I believe because they reworked the JSON parser to be quite a lot faster. There’s also a “native-comp” feature that’s available experimentally in 28, which does native compilation of most of the .el files in emacs. I’ve played with it a bit and it does seem like a significant speed up across the board. Definitely a lot of exciting things happening!

Yup, Emacs switched to Jansson[0] for JSON parsing. Since LSP uses JSON a lot, this means big performance improvements there.

Also seconding "native-comp" branch. It's technically experimental, but in practice it's pretty much stable. I've been running on it daily for the past 6+ months, with zero problems.

The way it works is, it uses GCC (libgccjit) to compile Emacs Lisp down to native (vs. the EL bytecode Emacs normally uses) on the fly, and then replaces the byte-compiled function with its native-compiled version. It does it transparently, across all elisp code you use - built-in and thrid party alike. What you get is a huge performance boost, and occasional messages that something gets compiled, when you run some new elisp for the first time.

--

[0] - https://digip.org/jansson/

Post reply on HN