Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
NvChad
Blazing fast Neovim config providing solid defaults and a beautiful UI, enhancing your neovim experience.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
doom-nvim
Discontinued A Neovim configuration for the advanced martian hacker [Moved to: https://github.com/doom-neovim/doom-nvim] (by NTBBloodbath)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
> running the community edition of Jetbrains’ IntelliJ IDEA
...
> As much as it hurts me to say this, as a fan of JetBrains and its tools, IntelliJ just seems to have become too heavy to run properly on a laptop that’s not at the very higher end of laptops in the early 2020’s.
IntelliJ does what I want, but only barely. The autocompletion gets it wrong as much as it gets it right and it is a performance hog.
I can deal with that.
The problem for me was JetBrains' privacy policy[0]. It is loosely-worded enough to forbid them practically nothing, and I find that especially appalling in a so-called "community edition".
So I began searching for alternatives. Emacs may serve for OP but I always forget how to exit it so I wanted something with a click close button in the top right.
I am getting a good initial impression from Codelite[1]. I'm sure Codelite doesn't do everything IntelliJ's IDEs do, but it has the functionality I use and it is a breath of fresh air after waiting for IDEA and the like to catch their breath during text editing.
[0] https://www.jetbrains.com/legal/docs/privacy/third-parties/
[1] https://codelite.org/
https://spacevim.org/ is also good alternative , it is basically vim/neovim sensible plugins pre-configured with smaller config file and simpler management.
I suggest that everyone go through this journey before using Neovim: https://www.chrisatmachine.com (so you can understand how and why something works, and also fine-tune your setup).
I disagree. When I am running a compilation (with output being dumped into a visible buffer) + query magit for large commit. Over tramp. Things noticeably freeze. Technically it all is async. Practically, it is implemented as polling things on main thread with some witing happening in non-async fashion.
> For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol.
That's why we have lsp-bridge and lsp-mode emacs fork :) Both of which build some infrastructure to avoid doing communication work with lsp-mode work in main emacs thread. So, heavy emacs users are building some async machinery which wraps another already async and relatively lightweight protocol, because core emacs facilities can't keep up with it. Architecturally it is kind of insane.
I think, lsp-mode fork is doing the right thing (from practical POV; it goes against "emacs is just an elisp interpreter" ideology though) and hope it gets into core at some point. A better solution would have being having first class async and background threads support at the elisp level. Which would never happen due to elisp messiness.
https://github.com/emacs-lsp/emacs
There are many of these distributions and I recommend them to people new to Vim because they can get a good out-of-the-box experience.
However after some time you probably want to configure your own and only include what you truly need. For this a good solution is to just adapt https://github.com/LunarVim/nvim-basic-ide to your liking. This is made by the author(s) of LunarVim.
It sounds a bit like you want „perspective.el“ (1). It allows you to define „virtual workspaces“ of buffers with individual window layouts. On each virtual desktop the standard buffer list is replaced with a shorter showing only buffers belonging to the current context. I use it every day to keep „code“ buffers separate from my „test“ buffers.
(1) https://github.com/nex3/perspective-el
I think Pulsar might be interesting: https://pulsar-edit.dev/
I understand these are some folks trying to keep Atom alive.
> "despite not significantly changing in functionality since Windows 3.11."
Here you can run Win 3.1 in a VM in your browser with a click: https://copy.sh/v86/?profile=windows31 and Calculator is in accessories. Make sure to put it in View -> Scientific mode for a full comparison.
Now launch Windows 10 Calculator, you'll see that it is resizable, Win 3.1 calulator can only be minimised. Win 10 shows Unicode characters like Pi, square root, superscript exponentials, Win 3.1 shows them as "x^y" and the letters "PI".
Win 3.1 has a memory. Win 10 has a history log of calculations done, a scrollable editable copyable history and clicking on the entries brings them back to do again.
Win 3.1 has a bug where (2.01 - 2 == 0), Win 10 has that fixed.
Win 3.1 has normal and scientific mode, Win 10 has normal, scientific, date calculation, multiple unit converters, equation graphing with customisable theme, zoomable scrollable live updating high quality, themeable graph.
Win 10 integrates with the Windows contacts in some way to let you share graphed equations with other people. Currency conversion pulls currencies and live rates from the internet.
Win 10 has Programmer mode which does base conversion, logic gates, bit shifting, bitwise number representation with click-to-toggle-bits for entry and viewing.
Win 3.1 calculator is a binary blob, Win 10 calculator is open source MIT licensed on GitHub https://github.com/Microsoft/calculator
That "99% of standard usage" is the kicker, isn't it? Those greybeards who always opposed multithreading since long ago tend to say that the remaining 1% of use cases is best done in an external process, ideally not even written in Emacs Lisp, so that the rest of the open source community can benefit, like the GNU Global you mention. I suppose if you still want that program to be written with Emacs Lisp, you could use async.el (https://github.com/jwiegley/emacs-async/) and there's finally an use-case for the threads: it'll be relatively safe to run those 16 threads only in the external Emacs-process.
