HN user
That's not a good counterexample.
Formal languages are called 'formal' because they have rigorously defined semantics. The 'undefined' parts, if anything, reveal that most of the expressible sentences have clearly defined semantics, rather than lack of them.
In addition, the semantics of 'undefined' behaviors is not 'non-deterministic' in the literal sense, since it is, well, undefined.
Magit introduced me to them in the first place. :-D
From a Lacanian perspective: They do it because the configuration loop itself is the Drive. The 'better working environment' is just the Object a (the carrot on the stick), but the true surplus jouissance is the tinkering itself. It's not about efficiency; it's about the thrill of the chase.
yes and no. you certainly don't have many pre-defined keybindings, but meow tries to not conflict with normal emacs keybindings so you don't need special ones anyway.
Congratulations!
Personally though I've been running the igc branch... ;-)
I agree with giving users control, but unfortunately I cannot agree with the move to c-ts-mode. And I cannot disagree more with associating CC mode with "legacy" when it's objectively better than the other alternative, at least currently. I don't think Emacs developers are doing users a favor in this specific case.
CC Mode is extremely capable. Over the years it has developed to such a maturity that almost all needs can be satisfied, and performance has never been a problem for me. It contains very few, if any, bugs, that affect my use.
On the other hand, the tree-sitter major modes are not at al production-ready to be considered as default. For one thing, the whole highlighting can break for complex macros and ifdefs. (I'd be glad to be enlightened whether it's theoretically possible to fix at all -- can you correctly highlight ifdefs without doing semantic analysis with the help of a compiler?) For another, CC mode has a feature called c-guess that can quickly analyze an existing source buffer and generate a format definition which proves extremely valuable. Alas, c-ts-mode has zero support for it.
I had high hopes for tree-sitter. I turned on tree-sitter modes for all my coding when it was out, and now I have zero enabled. They still have a long way to go and I don't want to spend time debugging emacs code at work. :-)
Tree-sitter is not a panacea. Fast parsing alone is not what makes a good major mode.
Actually, with emacs 29 it should come out of the box.
Open any python file (emacs has a built-in python-mode), M-x eglot, and you are golden.
It's interesting to see African input methods taking inspiration from a Chinese IME, RIME. Would like to know more about this!
I think I'm for Turing-completeness. Let me try to give my reasons...
1. No, using Turing-complete scripts does not prevent information extraction and meaningful automation. You can ask the program to dump useful information, e.g. targets, compiler flags, etc. That's what rizsotto/Bear does for Makefile. CMAKE_EXPORT_COMPILE_COMMANDS is another example.
2. I don't really think you can do anything further with declarative build languages, unless it is a really limited one like JSON or XML. Meson (a relatively advanced one in the space) advocates for non-Turing-completeness, but you still cannot, for example, modify meson build files reliably using an external tool other than a text editor.
3. Complex build configuration usually requires non-trivial computation and/or dynamic dependency graph building. Turing-completeness gives you a possibility and you don't need to wait for build tool upgrades.
Comparing Meson to CMake, I find the niceties of Meson are usually not inherently non-TC. That is, you can theoretically reimplement a nicer CMake with all the niceties of Meson, while still being TC.
It seems you are very ideology-driven, but no, corporations are not moving production out of China because "China bad". It's just because labor costs in China have risen due to its fast development.
The author isn't wrong. Europe is falling behind, and people should not pretend it's a good thing: the current European life style ("more to life than work") depends on excessive interests gained from technological advancements that are not yet replicated elsewhere. The life would be much worse if Europe couldn't keep up.
I kind of agree with you, and (as a hobbyist linguist) I believe a diversity of languages is a beautiful thing, but it creates unnecessary friction for business and about everything. Europe really needs a unified language -- it could be English, French, German, or even Interlingua or Esperanto.
Lingua franca really matters. China, for example, didn't have a unified spoken language until about 100 years ago. However, Mandarin is today universally understood and spoken in the country. And the result? You only to know one language, and you can have access to one of the largest markets in the world. Alas, the same could not be said for Europe.
(In fact, Europe needs a unified language if people are serious about getting rid of English and the Anglo-American hegemony, because each smaller language really cannot fight English now.)
Emacs natively supports copying an online link to the current node. It is bound to `C`.
I also think I'm obliged to share this tip: you can write a function that copies a Markdown-style link [(info "Node")](https://gnu.org/...). ;-)
It's ok to use Discord for pragmatic reasons. But please don't make it the only, or the "official" one.
The whole article reads like an ode to Emacs. :-)
I've been using Starship for quite some time, and it's awesome! Definitely recommend it to anyone who wants a fast, modern, and rich prompt.
Besides the product, the community is pleasantly awesome as well. I've contributed a module to it and the maintainer has done a good job reviewing and testing. Heck, they even have a Discord server for contributors.
This is unethical if (1) the condition was not made clear before the issue is written, and (2) the user cannot delete their report before it is published. (It is not in the current issue template, and I don't know if it was there.)
1. The issue writer will invest time and efforts, and publish their findings. Nobody's time is free: the maintainer's time is precious, and so is a user's.
2. Now, _after_ the issue is published, the maintainer additionally asks for a certain condition (give money or a star) to be satisfied.
What if the issue writer does not want to give that thing? The maintainer is now in an unfair position: they can still read the published issue, improve their software, but is not obliged to give any feedback or even credit the reporter.
It would be fairer if the condition was clearly conveyed to the reporter before they write any words. The system should simply not allow these issues written by the dissents to be created in the first place, and in that case the funny duck would also not appear before our eyes.
I'm not sure if this counts for "robbery", but similar stories happen every day in the FOSS community, usually for very boring reasons, e.g. copyright assignments, or in the author's case, security concerns, presumably.
My first contribution to Emacs is a very similar experience as the author's. I took time to debug a long-standing issue in Emacs, I wrote a patch, I asked other users to test my patch, and I addressed comments on emacs-devel, but eventually it got completely rewritten by a maintainer without any credit for my efforts.
AFAIU this is a discoverability problem, not that emacs isn't featureful ootb. Some of emacs's built-in features (e.g. undo in region) are even not supported at all by other editors.
Funny they haven't copied the full Chinese model yet. In China, the forwarding system can ban any website they don't like, and you have to copy the URL manually to visit it. 5 second delay is a mercy. :-)
Emacs-MacPort is an old port using the Carbon API, which has long been deprecated by Apple.
But to be fair, Emacs-NSPort (the official, Cocoa Emacs) is sorely lacking in maintenance power, and has a lot of problems, including tearing, glitches, crashes... It does not even have an official maintainer! [1]
OTOH, The MacPort has a maintainer, has more Mac-specific features, and is more stable. That being said, I still use the official port (due to various reasons).
[1] Try to look for src/nsterm.m in admin/MAINTAINERS.
This. A mailing-list-driven workflow is not as difficult as it appears, and Magit makes everything a breeze. However, I cannot complete the copyright assignment process, and consequently I am unable to contribute to the Emacs proper beyond a few lines of trivial changes.
It is so discouraging that I stopped working on the Emacs core [1] altogether: your contributions won't be acknowledged at all, even if someone volunteers to rewrite your code from scratch.
[1] I've been hacking some GUI-related features, but I'm not motivated enough to complete them. I also tried to write patches for my bug reports, but alas, my "CA-free" quota is already used up.
This looks like a cute library, but to those who don't know yet: Emacs has a real Japanese input method: type C-x RET C-\ and then select `japanese`.
I'm surprised that nobody here mentioned Atom [1]. IIUC, Atom was designed to be hackable like Emacs.
A successor to Atom is Pulsar [2].
Emacs Lisp is deeply embedded everywhere in Emacs. For example, a character can carry some 'display' properties that contain Lisp code, and the display engine will actually run the code [1]. The same cannot be said for Web engines. Of course, the usefulness of this is quite debatable -- the display of Web elements can be managed by CSS just fine.
[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Di...
You don't give permissions to an arbitrary Android app because you don't trust it, whereas GNU Emacs can be fully trusted, (unless you run untrusted Emacs Lisp code, ofc). I even tend to think it requires too few permissions, e.g. it cannot initiate phone calls.
If you don't trust the F-droid build, you can always build it from the sources.
Atom was intended to be the modern spiritual successor to Emacs. (It claimed to be ultra-hackable.) It failed due to its miserable performance. Visual Studio Code succeeded because of not being one.
It's crazy how Emacs adapts to so many different platforms! Congrats!
I tried switching to project.el, but eventually decided it's too bare-bones for me.
As far as I'm concerned, project.el lacks the following features OOTB:
1. Something like the .projectile file to mark a folder as a project (without VCS).
2. Support for ag, rg and vterm.
3. Register new project types (to customize configure commands, compile commands, etc.)
4. Regenerate tags.
5. The ability to find the "other file" (x.h <-> x.c) across the project.
And this list is incomplete! So if you rely on any of the above, I suggest not migrating to a project.el-only setup.
I use Logseq because it is just a local-first version of Roam Research.
To those who haven't used Roam Research or Logseq or anything similar, you are missing some really good stuff.