381–390 of 420 posts
I have stopped using emacs from the last 5 years since I had problems with its key bindings. My left little finger ended up paying the price as that is what I use for control key. I still miss org-mode which I used for more than 10 years. It is one huge reason why I kept coming back to emacs even after all the hurt. From then on, I used sublime and now vscode to do text editing and an IDE like IntelliJ for developmen…
Emacs' fundamental problem is that in text editing, there are many equally good ways to do things. It's equally good for Undo to be on control _ as on control z. It's equally good for scrolling to move the cursor as to not move it. It's equally good to have Lisp as a scripting language as JavaScript. No, really, I mean it. It's not a big deal in the big picture. And Emacs choose perfectly good, perfectly sensible def…
Out of genuinely interest, what claims specifically are you addressing here and why do you think are they wrong?
I've used full Emacs and Emacs style editors (mg, jove, epsilon) for over 40 years and programmed in LISP for longer than that. In the 1990's it was evident that Emacs was in decline. For a couple of years, I used Vi because IBM's lawyers were afraid of the GPL; during that time I found Vi to be a superior text editor than Emacs. Sometime in the late 80's, Emacs and the GPL were accepted by IBM's planners, and I swit…
I was nodding along to your recount until your recommendation for a new extension language. It wasn't your selection of language that rankled so much as the cavalier manner in which you suggest it. Replacing elisp with, say, javascript is tantamount to rewriting nearly all of emacs, a product of 40 years (although presumably fewer man-years).
Emacs out of the box is usable, but not as good as JetBrains tools or VS Code or Vim. Emacs is worth learning because it is an incredibly flexible editor construction kit that can be shaped into the editor one desires, but this, unfortunately, can require the user to write dozens of lines or even thousands of lines of configuration in eLisp.
The young programmers that I know are just not going to bother to learn eLisp to get their mode line to look useful. Spacemacs and Doom are good examples of how far one can push Emacs configurations, but even working with these prebuilt advanced configurations requires some delving into eLisp.
One approach to replacing eLisp would be to write a tool that compiles eLisp into JavaScript. eLisp has enough idiosyncrasies that this will be very challenging, but perhaps this could work. There are so many JavaScript programmers that could help with cleaning up the inevitable broken packages.
Alternatively, like the NeoVim project, most of Emacs internals could be left in place and a JavaScript extension language could be added so that new packages could be written in either eLisp or JavaScript. Someone would have to figure out interoperability between the two—sharing data between two interpreters each with different garbage collectors for example.
LaTeX faced a similar problem. The TeX esoteric macro capability was used to build LaTeX and LaTeX was used to build hundreds of complex packages to be used with LaTeX. The TeX/LaTeX world moves at a snail’s pace compared to Emacs, but they have made gradual progress in modernizing TeX and LaTeX (LuaTeX, LaTeX3, ConTeX, etc.)
Earlier quoted context omitted.
Well, JSON is "just" a serialization format. I'd expect that to be much easier to teach someone than a programming language. That's a rather bizarre comparison. If all you're doing is serializing the configuration, then lisp's s-expressions are just as intuitive as JSON (in the sense that both can be explained in a few minutes).
Yes, it is a bizarre comparison because of that fact. A programming language will never be more intuitive than "just a serialization format". Also, the argument that lisp's s-expressions are just as intuitive as JSON is verifiably false because you can use a simple natural experiment: what is used more for serialization, JSON or s-expressions? It's extremely ironic to try and argue these points on a post that's entir…
Some new thing is intuitive to a certain person, not everyone, if and only if that person has previously developed some intuition --- tacit experience --- that translates to that new thing. So intuitiveness is more a function of the previous experiences of a person than of a thing itself.
Whereas intuitiveness for an average member of the target population of a product is a useful quality of that product, it is by no means the most important quality of that product. Or else the most "intuitive" products should never introduce any changes, shouldn't they?
Earlier quoted context omitted.
> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well? Almost, but not quite. VSC doesn't give you javascript access to the internals of the application, it just provides a fairly broad set of extension APIs. You can see this in how the VSC equivalent of rainbow-delimiters-mode (parentheses and brackets recolored based on their nesting depth) had to be rewritten as part of the…
I'm doing a highly integrated language environment for a research language and faced this decision recently. elisp and javascript are both pretty iffy lisps, but at this point I think I'd prefer javascript. however VSCode presents an API around a specific notion of what a language is and how it interacts with the editor. emacs comes in at lower level and presents a model with just buffers and text. I remember elisp d…
If you're on something as radical as not using source code to describe a program (what are you using then? A DB of some sort?), I don't think either emacs or vscode can be your tool of choice.
We know there's no free lunch, if an extensible development environment was flexible enough to make this sort of thing easier, something else had to be made harder.
As a chemical engineer, my use case is that of being a researcher, programmer, and tinkerer. So, the initial appeal was that of having the ability to version-control, pre-process, and have 'reproducible builds' of my articles or documents (if I add more data, I wanted to be able to update the numbers in the article).
And, most importantly... I was drawn in by the capability of using org-roam to try out the zettelkasten methodology (even more so now that there's org-cite).
My journey has been to first slowly learn Emacs, then org-mode, and finally I'm starting to learn org-roam, and to learn make my own templates for my zettelkasten implementation.
Before all of this, I had tried using Vimwiki and Taskwarrior for productivity and knowledge administration, and I had also used PP and ABP as Markdown preprocessors with Pandoc for documents generation.
I still prefer to use Jabref for reference management (mostly for looking up by DOI or ISBN, and pairing with the PDF and epub), but I might try to eventually learn a way to go do that with some of the bibliography managers on MELPA.
For coding Python, specifically, I'm still fond of Spyder. But I also intend to transition and try out ways to achieve the same things that allow me to produce high-quality code (with rich documentation). I plan to re-learn modern FORTRAN on Emacs, however.
Anyhow, my experience of Emacs onboarding has been that of slowly learning what can or can't be done by searching for random snippets of init file configurations, and reading the Emacs and org-mode user manual. Also, by watching System Crafters' videos, as well as videos from other very talented coders and researchers that have shown how to use org-babel to create reproducible research.
Finally, I wanted to add that one of the best-selling points for org-mode and Emacs, is the ability to do so many awesome things just from plain text files, with very low memory and disk footprint (in stark contrast to VSC).
One thing I forgot to add is that I'm thankful for all the hard work that has been done in creating a cool ecosystem of software that has resulted from developers scratching their own itch. I have donated once, and will donate again... but I also intend to contribute and help keep free software alive.
I have realized recently that a value that is gaining a lot of importance for me is the stability of my cognitive investments, in terms of tooling, across a time frame that goes beyond my "current project", and more into the "my entire career" territory. In that sense, I feel more and more that the choice of learning and owning Emacs, more than 20 years ago, while in school, has paid off tremendously, in the sense th…
That sounds good in theory. But if you're working with a more-than-30-year-old tool, you're either: 1. Missing out on "new innovations" (and using older gui/etc paradigms which don't mesh with anything else you are used to). 2. Finding ways to update your tool to take advantage of "new innovations", which costs time, and often gives you a worse outcome. I was a vim user for 8 years, then used spacemacs for another 2,…
Vim and Emacs are console editors for me. The most significant difference for me is sensible mouse support. I used Emacs just for LaTeX, otherwise I use mostly unhacked vim. It is very useful to be familiar with one of them, but nano is awesome too and I always mention it for new developers.
I believe vscode is successful because it is simple. Just like how JSON was successful compared to XML for simple applications. It isn't better than XML, but most applications are too simple to warrant XML features and resulting complexity.
For C# I prefer VS instead of vscode and I fear vscode tries to be both, a code editor with extended features vs a fully integrated IDE. For some language like JS vscode already has become an IDE with advantages and disadvantages and it is quite often very opinionated here.
Earlier quoted context omitted.
I was nodding along to your recount until your recommendation for a new extension language. It wasn't your selection of language that rankled so much as the cavalier manner in which you suggest it. Replacing elisp with, say, javascript is tantamount to rewriting nearly all of emacs, a product of 40 years (although presumably fewer man-years).
I agree with you that replacing all of the eLisp with say JavaScript would be impractical because there are hundred thousands of lines of eLisp that would have to be replaced, but Emacs is never going to increase its appeal while requiring new users to learn its own, somewhat peculiar, extension language. Emacs out of the box is usable, but not as good as JetBrains tools or VS Code or Vim. Emacs is worth learning bec…
I've been using emacs as my primary editor since 1989. It has for that entire time been a PITA to configure. My first customization was to map backspace to ^H and map the insert key to 'nil. I used to dedicate a couple days every January to investigate new emacs tools. Read about the latest features or new modes, often from my org-mode TODO list where I bookmarked them. I have learned to never update emacs mid-projec…
I wonder if it's possible to move on from elisp. Create a EMACS 2. Maybe with Scheme. Maybe a language neutral extension system/API? (So you can use whatever language you want.)
I have realized recently that a value that is gaining a lot of importance for me is the stability of my cognitive investments, in terms of tooling, across a time frame that goes beyond my "current project", and more into the "my entire career" territory. In that sense, I feel more and more that the choice of learning and owning Emacs, more than 20 years ago, while in school, has paid off tremendously, in the sense th…
That sounds good in theory. But if you're working with a more-than-30-year-old tool, you're either: 1. Missing out on "new innovations" (and using older gui/etc paradigms which don't mesh with anything else you are used to). 2. Finding ways to update your tool to take advantage of "new innovations", which costs time, and often gives you a worse outcome. I was a vim user for 8 years, then used spacemacs for another 2,…