[HN Gopher] Emacs 29.1
___________________________________________________________________
Emacs 29.1
Author : pimeys
Score : 325 points
Date : 2023-07-30 09:47 UTC (13 hours ago)
(HTM) web link (emacsredux.com)
(TXT) w3m dump (emacsredux.com)
| voicedYoda wrote:
| Every single time i open up the tutorials on how to learn emacs,
| a million other priorities come along. I know there are die hard
| fans of it, and I'd love to learn it, but with VSCode, vi, tmux,
| and all the MacOS tools i know, I'm not sure I'll get around to
| learning it before i burn out completely from engineering
| thih9 wrote:
| What does a new release like this mean for popular frameworks
| like spacemacs or doom emacs?
|
| E.g. for lsp support, are the frameworks switching to the native
| one or are they going to rely on their current setup for now? Or
| is there no common approach?
| cutler wrote:
| For Spacemacs remember to use the devel branch, not stable
| which hasn't been updated in ages.
| rhaps0dy wrote:
| In Doom emacs, you can add the +eglot switch to your lsp tool
| to use Eglot (the new setup) instead.
| https://docs.doomemacs.org/latest/modules/tools/lsp/
| pard68 wrote:
| Took a new job and ended up putting emacs aside. Using Google's
| Lit framework is unbearable on emacs. It has some deeply nested
| html/js in template strings and emacs can't keep up with the
| nesting.
| shadowgovt wrote:
| It should be able to. Emacs has good built-in support for
| navigating around substructure as long as you're operating with
| a mode that recognizes the substructure.
| Paul-Craft wrote:
| I'm not familiar with Lit, but if emacs can't grok all the
| nesting, how is it even remotely human comprehensible?
| pard68 wrote:
| With proper syntax highlighting it's fine. But this is why I
| have moved away, it's hard to read without good syntax
| highlighting. I don't know why extensions aren't handling it.
| Web-mode does but only the first level or so of nesting.
| rs_rs_rs_rs_rs wrote:
| Is this with or without Treesitter?
| pard68 wrote:
| Either. The best results I have had was with web-mode which
| has some basic support for it. I also tried using LSP mode
| and the two Lit extensions for the Typescript server but that
| did little to help either.
| [deleted]
| jackcviers3 wrote:
| Probably needs its own extension like in vscode.
| weebull wrote:
| Sounds like a good application for treesitter
| clircle wrote:
| Thank you Eli !!!
| aardvark179 wrote:
| Right, emacs upgrade is now added to the list of things to do on
| my day off tomorrow.
| enbugger wrote:
| First I thought that emacs/vim are about productivity. You
| invest some time to learn its concepts and train muscle memory.
| In the end of it turned out that you have to forget about
| spending weekends away from your PC. Not much time was actually
| saved. My conclusion from all this: this is just another way of
| doing things with no huge benefits but with bigger portion of
| loses (at least because this is not mainstream).
| throwanem wrote:
| Yeah, that couple hours a year is a real killer.
| shadowgovt wrote:
| The main advantage of encountered is that it doesn't go away.
|
| I've been in contexts where I can't use vscode and I've been
| in contexts where I can't use intelliJ and so on. The
| contexts where I can't use emacs (specifically, emacs
| configured to my preferences) are thin on the ground.
|
| It's a space alien user interface and software abstraction
| relative to most out there, but the payoff is I never have to
| put it down.
| MatthiasPortzel wrote:
| In what context can you use Emacs but not another editor?
| shadowgovt wrote:
| When I'm on shell only and can't bring up an X session
| for a GUI.
|
| This scenario is fortunately pretty rare these days,
| especially since vscode supports remote editing, but it
| still happens from time to time and I can still resolve
| the issue by just dropping emacs on the target machine
| and working with it in terminal mode. And vscode is a
| relatively new option here; If I cast the bones, I
| predict it will be around for awhile.
| jks wrote:
| In that scenario you can often use Tramp - run Emacs
| locally and let it use ssh and scp to modify the files on
| the target system. Does the VS Code remote editing
| require some kind of server component on the remote
| system or does it manage it through ssh and shell
| commands?
|
| Thankfully the cases where the only available editor is
| /usr/ucb/vi are starting to get rare.
| shadowgovt wrote:
| I'm well-familiar with Tramp and love it dearly.
|
| It has several does-not-play-well failure modes that
| vscode remote doesn't. My favorite is that if I have an
| ssh out and the session goes down, then (in a way not
| unlike how a terminal ssh'd out will act if the session
| goes dead) emacs will just freeze. But apart from those,
| it's super-great and I do love being able to just treat
| some random data on some random server or user as a
| buffer and bring to bear on it everything you can hit a
| buffer with. That decontextualization, that fitting of
| one abstraction (the buffer) to so many contexts, is one
| of the best things about emacs.
|
| Yes, vscode does what it does by installing a remote on
| the target machine and operating from there.
| rout39574 wrote:
| More like someone who works on their own car. Yeah, they lose
| the occasional weekend to the maintenance, but they love that
| they've had the same car for 35 years.
|
| However with Emacs, there are a few thousand other people
| working on the car too, so despite the fact it's the
| volkswagen beetle you bought in 1972 and your butt shape is
| indelibly formed in the cockpit, it has _also_ got electric
| power train, full self driving and JATOs. :)
| bborud wrote:
| I used Emacs every day for 28 years. Until I got really
| tired of having to put it up on the jacks, as it were, for
| a weekend every now and then. In order to deal with the
| fact that everyone who works on Emacs seems to think
| everyone else is just as enthusiastic as them about
| spending their weekends fiddling with Emacs.
|
| It isn't for me. At least not anymore.
|
| Dealing with Emacs is a lot like dealing with software
| written in Python: probably great if you really like going
| trough long descriptions of how to get something to work.
| Not so great if you are more concerned with using the tools
| rather than fiddling with the tools.
| jackcviers3 wrote:
| Use helm-M-x and which-key, and avoid anything but use-
| package and customize. You don't have to eat the muscle-
| memory elephant all at once.
| Paul-Craft wrote:
| Or just install spacemacs and get a lot of that set up for
| you for free, plus a bunch of other cool stuff.
| vinceguidry wrote:
| Spacemacs hinders your growth with Emacs over the long
| run. It hides Emacs internals from you and jumps through
| a lot of hoops to make Emacs feel modern. But the beauty
| is skin-deep and the second you start wanting something
| off-script, you'll find it getting in your way, with
| online threads and such catering towards vanilla rather
| than frameworks.
| Paul-Craft wrote:
| I disagree 100%. There is literally nothing you can do
| within init.el that you can't do within `.spacemacs`, and
| you will rarely have to venture outside of
| `dotspacemacs/user-config ()` except to add layers or
| packages to the appropriate config variables so they can
| be installed automatically for you.
|
| I've been using emacs for over 10 years and had zero
| issues with making the transition. On the contrary, it's
| simplified my emacs life quite a bit. The only thing I
| have not been able to get working is `eaf`, but that's
| clearly not the fault of spacemacs.
| teddyh wrote:
| NEWS:
| <https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=...>
|
| Official release announcement:
| <https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00008...>
| lmedinas wrote:
| I love Emacs (it was my main editor in the last 20 years) but i
| can't justify anymore to use it due to lack of modern feature,
| ease of use and maintenance of the .emacs files. Maybe i'm
| getting too old to constant exercise my memory or to tinker
| configuration files. Nowadays i just use VSCode and occasionally
| nvim.
| massysett wrote:
| You can use M-x customize to pick configuration options from a
| menu.
| nequo wrote:
| What modern feature is Emacs missing?
| wiz21c wrote:
| - fast loading (vscode loads much faster on my computer;
| specially if I have a lot of open files)
|
| - code "peek" (that little windows is super useful)
|
| - good integration with debugger (again, vscode kills it
| here). For example: how to look a at a numpy array in emacs
| (in vscode there's a data viewer for that)
|
| - robust LSP (for example, when I complete a formatting
| string f"{... on a big file, emacs simply becomes
| unresponsive for a minute or so (it's much quicker ona
| powerful computer though); pylance is simply superior on edge
| cases.
|
| But although I'm a long time emacs user, there's one thngs
| where VSCode is much better, it's discoverability. I've
| learned much of what I need in 2-3 weeks, without ever
| looking at a manual.
|
| Note: I'm a regular emacs user since since about 10 years (I
| came for the freedom, stayed for the community). I'm using
| VSCode since about a year.
|
| I'll be happy to ear a way to make my emacs better.
| goku12 wrote:
| I wonder why everyone's having such long startup time for
| emacs - like 6 to 8 seconds. Mine has a lot of add-on
| packages and it still manages to start up in 2 seconds
| (It's a server. So that happens only once in a session). I
| haven't done much optimization either - unless you count a
| lot of autoloads that you automatically get with use-
| package.
| natrys wrote:
| Doom Emacs loads very fast so theoretically it's possible
| to configure Emacs to be fast too (mine starts in a second,
| cold start is a little slower).
|
| But I think most people don't care about it enough because
| they either never close Emacs and/or use it in server-mode
| where emacsclient is pretty much instantaneous. Can I ask
| why you don't like doing that?
| phforms wrote:
| I use Doom Emacs with the Yamamoto port of Emacs [1] on
| MacOS (M1) and the startup time is quite slow: it takes
| around 6-7 sec. for the editor window to show up. It
| doesn't bother me too much since I usually start it once
| a day and just never close it, as you mentioned.
|
| However, I also have many plugins installed, so it might
| be just that. I wonder if it is possible to install a
| separate instance of Emacs, then I would be able to test
| the performance without all the plugins and
| configuration.
|
| [1]: https://github.com/railwaycat/homebrew-emacsmacport
| wiz21c wrote:
| Because I conserve energy: I turn my PC off at the end of
| each session (so about one/two times a day). And because
| the "sleep" mode is not reliable (I have a 14 years old
| PC, upgraded in RAM and GPU and SDD; and here I conserve
| hardware).
|
| So having things take time on start up is an annoyance to
| me (but I live with it, I was just saying that emacs is
| slower than VSCode)
| PaulDavisThe1st wrote:
| > - fast loading (vscode loads much faster on my computer;
| specially if I have a lot of open files)
|
| who ever does such a thing? Emacs starts up on my machine
| soon after I login. It remains open until I logout. Current
| instance has 123 buffers (files). Loading speed just isn't
| important to me as a full-time native (C++) developer.
|
| > - robust LSP
|
| I tried LSP a bit. Gave up because it just didn't really
| help me with my actual work. Could understand why someone
| with less experience programming would find it helpful, but
| it just wasn't so for me (I use emacs dynamic completion a
| _lot_ )
| dventimi wrote:
| > Could understand why someone with less experience
| programming would find [LSP] helpful
|
| Have you considered the possibility that people with more
| experience programming than you might find it useful?
| PaulDavisThe1st wrote:
| Yes.
| dventimi wrote:
| Then that covers everyone.
| nequo wrote:
| Parent does have quite a bit of experience:
|
| https://en.wikipedia.org/wiki/Paul_Davis_(programmer)
| TheRoque wrote:
| So renaming all the symbols in your whole project with
| just one command is not for you ? Navigating to
| declaration/searching all the usages of a symbol etc. All
| that isn't for you ? And these are the two most basic
| features You make it sound like LSP is a small gimmick
| that appeals to less experienced developer while it's
| actually a huge productivity boost that has literally no
| link to being experienced or not.
| nequo wrote:
| I also think that parent's comment is overly dismissive
| of LSP. But for me, Emacs with lsp-mode does the things
| that you describe.
| PaulDavisThe1st wrote:
| I mean, I wanted to love LSP. Everything I read about it
| suggested that I would. But I tried it out for two weeks,
| working (as normal) on my 600k LOC C++ project, and found
| it somewhere between irritating and not-actually-helpful.
|
| I appreciate that people who started programming with
| such tools probably come to rely on it the way I rely on
| dynamic completion in emacs (which is a lot).
| gumbojuice wrote:
| Emacs on my system is ~8sec load time, vs ~5sec load time
| for Code. I have not optimized either (but I have decided
| on using Straight as package manager on Emacs, which is
| arguably faster than the built-in).
|
| I use LSP a lot (through eglot with Emacs-29). For each
| "mode" in Emacs there are alternatives to LSP, mostly
| what was there before LSP, which may be equally good.
| However, I found that switching to LSP simplified my
| setup, and having the same functionality/keybindings
| between modes is great, e.g. my projects switch me
| between Python, Rust, and Java, earlier that was
| basically three different "IDEs", while today they're
| very similar.
| vinceguidry wrote:
| Run emacs as a server when you start the machine and use
| emacsclient to connect with it. Way faster start times.
| PaulDavisThe1st wrote:
| > Emacs on my system is ~8sec load time, vs ~5sec load
| time for Code
|
| yeah, but i don't give a damn. I do this once every few
| weeks.
|
| ps. also, emacs is < 3 secs on my system, so even if i
| did care ...
| wiz21c wrote:
| What is "dynamic completion" ?
| PaulDavisThe1st wrote:
| I have it bound to Ctrl-\ ... Emacs scans backwards
| through the current buffer, then all other buffers, to
| look for completions for the word at the cursor. Press it
| again (after one completion) and it will cycle through
| other possible completions (and keep doing this as long
| as you keep pressing that).
|
| It's great for completing variable names, but also if you
| writing just regular text, finishing longer words and so
| on.
| craftkiller wrote:
| Emacs has code peek.
|
| With lsp-mode it has that little window: https://emacs-
| lsp.github.io/lsp-ui/#lsp-ui-peek
|
| Personally I use eglot with consult which temporarily
| switches the entire buffer to do the "peek" functionality
| rather than popping up a tiny window:
| https://github.com/minad/consult
| [deleted]
| worthless-trash wrote:
| I feel the comment was bait.
| mm007emko wrote:
| Exactly. I have been using git for my .emacs files and
| there is little I really miss from Emacs for editing files
| and even quite a lot of coding.
| submeta wrote:
| In the same boat. Still like it a lot, but I started using VS
| Code for serious coding. But unpopular opinion here. So expect
| to get downvoted a lot.
|
| Edit:
|
| The unpopular opinion is to say that one has stopped tinkering
| with Emacs for hours and started using a tool like VS Code or
| intelliJ to do actual coding work.
| User23 wrote:
| IntelliJ is lightyears ahead of VS Code or any other LSP
| using editor including Emacs for what it's good at, namely
| working with Java in complex ways.
|
| I will use IntelliJ or Eclipse over Emacs or VS Code for Java
| development any day. But having used both VS Code and Doom
| Emacs for other development, the latter is quicker, more
| featureful, and more discoverable, just as easy to configure,
| and more extensible.
| jeltz wrote:
| VS Code is extremely popular here do I have no idea what you
| are talking about.
| submeta wrote:
| Relax, we're talking about an editor, not someone's
| religion.
| jeltz wrote:
| Is what I should say to you since you were involved in
| the editor war while I was not. I have not even said
| anything on this topic other than that there are tons of
| VS Code users here so the "unpopular opinion" makes zero
| sense and just feels like you were being rude to Emacs
| users (of which I am not one). I downvoted you because
| you were doing editor warring.
| gpderetta wrote:
| Blasphemy! Repent and join the Church of Emacs!
| anta40 wrote:
| I think "tinkering for hours" is overstated. My vim/neovim
| and emacs setup usually take no less than 30 minutes
| (including installing favourite plugins/packages). Then I can
| use them to get my work done.
|
| Well, I'm not that obsessed with tweaking every bits, though.
| When I'm using vim/emacs, I never intend to configure them
| into IntelliJ replacement.
| emacsen2 wrote:
| [dead]
| derekzhouzhen wrote:
| > maintenance of the .emacs files
|
| What maintenance? I have not changed a single line of my .emacs
| file for 3 years.
| rurban wrote:
| I have to admit, I added a couple of lines since 1995. About
| 10 or so
| jks wrote:
| I changed from .emacs to .emacs.d/init.el when it became
| possible, because that seems neater. Some years later I
| decided to see what fancy packages the young folks like,
| and started using vertico, orderless, marginalia, embark,
| and consult. I'm still going to reserve judgment on embark
| and consult, but at least the first three packages are
| certainly great additions.
| lmedinas wrote:
| if your .emacs has 10 LOC it makes it definitely easy. My
| .emacs is +-360 LOC.
| derekzhouzhen wrote:
| My point is: the api of of emacs is fairly stable. And your
| point is?
|
| I have ~80 lines outside the customize variable block added
| by emacs. Nothing too fancy but there are a few hot keys
| and functions that I can't live without.
| gumbojuice wrote:
| [dead]
| rvdginste wrote:
| I am a long-time Emacs user and used to maintain my own config,
| but I switched to Doom Emacs [1] a year ago. Doom Emacs is like
| a pre-packaged/pre-configured emacs distro. You still need to
| configure the features that you want to use, but it's a lot
| easier (and faster) than having to do everything from scratch,
| and definitely if you already have some emacs background
| anyway. For me, it makes the newer, more advanced, features
| more accessible. Since switching, I started to use Emacs more
| again.
|
| [1] https://github.com/doomemacs/doomemacs
| lmedinas wrote:
| i tried Doom Emacs and the first thing that turned me down
| was the VI bindings, which i disabled right after install.
| But yeah it does the whole configuration nightmare more easy
| to maintain.
| jackcviers3 wrote:
| Modern features:
|
| 1. lsp-mode/eglot
|
| 2. package management
|
| 3. treesitter grammars
|
| 4. Portability - win/linux/mac/unix/android
|
| 5. Graphical User Interface - you can browse the web and watch
| YouTube in Emacs. Customize has buttons, forms, menus.
|
| 6. Treemacs/Treeview/speedbar: you know the multipanel view in
| Intellij or the project explorer in Intellij/vscod? Yeah, that.
|
| 7. Actual macros and function definitions, without needing to
| post them as an extension.
|
| 8. Interactive repl.
|
| 9. 5 different terminal emulators built-in.
|
| 10. Automated fuzzy everything with helm-M-x and helm. Exactly
| like Command-p in vscode.
|
| 11. github, gitlab integration with magit.
|
| 12. Copilot, tabnine, and chatGPT integration.
|
| 13. Hundreds of themes.
|
| 14. We've had shareable, secure remote collaboration for over a
| decade with wemux.
|
| 15. Use any ttf.
|
| 16. Mouse editing and command binding.
|
| 17. Use every build tool with projectile-compile-project.
|
| 18. Refactoring with lsp.
|
| 19. Autocompletion and jump to source.
|
| 20. Session save and restoration with desktop-save.
|
| 21. Slack integration.
|
| 22. Debugger with dap-mode.
|
| 23. Individual test only runs with dap and avy-lens.
|
| 24. blame with.magit-blame.
|
| 25. Pixel scrolling.
|
| 25. Transparency with seethru.
|
| 28. Rest client with variables and session storage (like
| postman, but free).
|
| 29. Browse compressed files as if they are normal directories
| and save to them.
|
| 30. Containerized deployment via flatpak.
|
| 31. Docker, docker-compose integration, kubernetes, aws,
| datadog, Azure integrations...
|
| All of this fits in around 500 lones of copy_paste/cloneable
| emacs configuration, most of which is use-package declarations.
| Nary a defun or global-bind-key in sight, and because emacs is
| a full elisp ide, and it is actually executable code, it's
| debuggable on launch, unlike myriads of json files.
|
| I'm trying to think of anything else that can possibly be
| interpreted as 'modern' from a ux standpoint. I certainly can't
| think of a feature that Intellij has that emacs doesn't that is
| core to the ide experience. And most of my emacs tools are
| better than the vscode version of them, at least in terms of
| invasion into the editor buffer or integration with the editor
| ux.
|
| The one thing that's not modern is the standard copy and paste
| commands, but that's super easy to customize. I guess you can't
| drag and drop buffer frame borders in multiple buffer layouts
| if you hide scrollbars, and the message buffer isn't
| resizable...
| shadowgovt wrote:
| But vscode has basically all of it out of the box. Maybe
| after installing one or two extensions, which it recommends
| for you and you can install via a GUI.
|
| As someone who uses emacs most often: VSCode is shaped a lot
| more closely to a modern aesthetic by default. If you've been
| following along with emacs all this time and keep up to date
| with the latest changes, you can easily accrete the
| configuration to make your emacs look like a modern tool, but
| it doesn't start configured that way.
| lelanthran wrote:
| I don't understand why this was downvoted.
|
| Vscode out-the-box _is_ much more complete for coding than
| Emacs out-the-box.
|
| While my Emacs-foo is not that great, I _have_ relied on it
| for a lot over 25 years of programming. Recently, though, I
| gave Vscode a try, and while it 's buggy as hell when you
| load up on the extensions you need, _it 's not that bad!_
|
| Slow? Yes, compared to a Vim or Emacs similarly set up. A
| wee bit bloated? Certainly, compared to my Vim and Emacs
| configuration.
|
| But, really, it's the one I recommend to new developers.
| Not Vim, nor Emacs, even though I use those myself.
| agumonkey wrote:
| vscode has a lot for itself, but i see my colleagues use
| it, it's still too mainstream and enterprisey. the git
| interface adds more confusion and reduces speed..
| shadowgovt wrote:
| No disagreement. I find myself just using terminal
| instead of the vscode git interface almost all the time.
| rout39574 wrote:
| I think you might want to contemplate that "Fashionable" is
| semantically equivalent to 'dated'. You are excited that
| it's dated to 'now'.
|
| I know you see this fashionable UX as an advantage, but
| what I think about is how you're going to have fashionable
| evolution in UX thinking inflicted on you. It feels to me
| like someone coming into my shop and moving all my tools.
|
| Gratuitous example from an adjacent area of nerdliness:
| Were you around when Microsoft decided to drop the UX
| they'd been using for a few decades and change to "The
| Ribbon" ?
| shadowgovt wrote:
| > You are excited that it's dated to 'now'.
|
| Yes, I am. That's very convenient for me.
|
| > Were you around when Microsoft decided to drop the UX
| they'd been using for a few decades and change to "The
| Ribbon" ?
|
| I was, and you're right. Microsoft functionally owns the
| chrome for vscode and it isn't as configurable as far as
| I can tell as emacs at that layer. There's certainly a
| possibility they will make a decision later to mess
| everything up.
|
| But for now, my previous observation stands. I have to do
| less configuration out of the box to get vscode into a
| daily use work configuration than a naked emacs install.
|
| I highlight this because it's not an unsolvable problem
| for emacs. It requires making a recommended default
| configuration that will be more correct for the 95% use
| case and advocating that configuration on the install
| channels for the tool.
| rvdginste wrote:
| > I highlight this because it's not an unsolvable problem
| for emacs. It requires making a recommended default
| configuration that will be more correct for the 95% use
| case and advocating that configuration on the install
| channels for the tool.
|
| For people interested in this, I know about Doom Emacs
| [1] and Spacemacs [2].
|
| [1] https://github.com/doomemacs/doomemacs [2]
| https://github.com/syl20bnr/spacemacs
| bborud wrote:
| Why downvote this guy for essentially just pointing out
| that Emacs isn't terribly useful out of the box if you want
| to develop software? This is objectively true, isn't it?
|
| It is like assembling IKEA furniture if IKEA furniture
| didn't come with a usable manual and there are nine
| different descriptions online of how to assemble your new
| chair. Of which 5 don't actually produce a chair and two
| that are strangely incompatible with how you prefer to
| situate your couch.
|
| Rather than be angry with people for pointing out something
| that is very likely to be true, how about listening to
| _valid_ user criticisms? And perchance see if something can
| be learned from it?
|
| This is valid feedback.
| worthless-trash wrote:
| > But vscode has basically all of it out of the box.
|
| Are you sure ?
| agumonkey wrote:
| postmodern features: [e]lisp metalevel customization
| goku12 wrote:
| One of my favorite aspect of Emacs is its configuration file. I
| use an org-mode file for configuration - which means that we can
| have rich documentation along with the code - all neatly folded
| up. The init.el file is just a stub meant to load the
| configuration from the org-mode file. Even better - the init.el
| itself is written within the org-mode file. The org-mode file can
| be executed like a shell script (actually elisp script) to
| extract the init.el file.
|
| Similar executable org-mode files are used to configure the
| environment (sway) and personal information management (email,
| calendar & contacts). The latter one got so complicated that I
| had to add an integration diagram using the draw.io app.
| metroholografix wrote:
| I've always seen this as an anti-pattern. You can make the
| documentation in an .el file as rich as you want without losing
| all the niceties that Emacs offers for interactively working
| with source code (e.g. find-{function,variable} will jump to
| the ephemeral dynamically generated .el file, not the actual
| origin of the code which is in the .org file).
|
| Why settle for an extra layer of indirection that makes
| interactively working with source code more time consuming?
| goku12 wrote:
| > Why settle for an extra layer of indirection that makes
| interactively working with source code more time consuming?
|
| I understand what you mean. But it never seemed to be a
| problem for me. Anyway, the real reason why I ended up with
| org-mode is that I heavily customize Emacs. The only way to
| be able to handle that much configuration was to split it up
| into a dozen or so elisp files. Org-mode's biggest advantage
| (for me) is that it can manage complexity very well. The org-
| mode configuration file is neatly divided into topics along
| with their documentation. The topics are also folded up - so
| it's very easy to find certain configuration segment.
| BeetleB wrote:
| Matter of preference. As an example, I may have a lot of
| configuration related to package X under one Org node. I
| merely have to "comment" the node headline to ensure none of
| that code gets to the config.
|
| Your comment reveals your bias - that the code is more
| important than the commentary. The counterpoint is:
|
| No. You _can 't_ make the documentation as rich as you want.
| I want inline images. Can I put those in an .el file? Links.
| Tables. Bold, italics, etc. For many, this is more important
| than the code in the config.
| pxc wrote:
| > Your comment reveals your bias - that the code is more
| important than the commentary
|
| Yep! That's the key, imo. I love using Org mode wherever I
| feel that documentation is primary. So right now, most of
| my code that lives in Org files at work is shell snippets
| I've used for managing and configuring software. The
| literate approach is all I need there: I'm keeping track of
| what configuration I've done, not writing a giant,
| complicated program. Then I get the added benefit: the Org
| files form a wiki that I can use to refer colleagues to
| whether they use or care for Emacs or not!
|
| Similarly, tangling shell snippets into scripts lets you
| write tests for your documentation! The examples become
| scripts and then the scripts can be run and verified in CI.
| goku12 wrote:
| > I want inline images. Can I put those in an .el file?
| Links. Tables. Bold, italics, etc. For many, this is more
| important than the code in the config.
|
| Thanks for adding this. Literate programming with org-mode
| is indeed one of my favorite from Emacs.
| pxc wrote:
| > The init.el file is just a stub meant to load the
| configuration from the org-mode file. Even better - the init.el
| itself is written within the org-mode file. The org-mode file
| can be executed like a shell script (actually elisp script) to
| extract the init.el file.
|
| Can I see (an example)? Wondering how much goes into that
| init.el.
| nvy wrote:
| Not OP but here's mine: https://github.com/nathanvy/dotemacs
|
| The .org file gets processed and the source code blocks
| extracted into an elisp-only file which is what actually gets
| executed.
|
| Some people prefer an alternate approach[0] with the "stub"
| init.el that just loads other modules.
|
| [0] https://github.com/cute-
| jumper/.emacs.d/blob/master/init.el
| lockhouse wrote:
| The other great feature of Emacs is that its keybindings are so
| pervasive. Most native MacOS text input widgets and modern
| POSIX shells like bash and zsh use Emacs-style key binds for
| navigation and text editing. Also anything that uses GNU
| readline supports them as well out of the box.
| abhijeetpbodas wrote:
| Bash/readline also has a vi mode :) https://www.gnu.org/softw
| are/bash/manual/html_node/Readline-...
| supazek wrote:
| Native emacs keybindings never ever worked for me. I could
| only use emacs once I got used to evil mode
| OO000oo wrote:
| > _The latter one got so complicated that I had to add an
| integration diagram using the draw.io app._
|
| Amazing that this is offered up as a selling point. If I didn't
| know I was reading a thread full of emacs users, I'd think this
| was a parody of a thread full of emacs users.
| goku12 wrote:
| > I'd think this was a parody of a thread full of emacs
| users.
|
| Haha! Indeed! Let me just clarify what I meant. I have a
| personal information management (email, calendar & contacts)
| where all information is stored locally and offline. The
| advantage is that I will never be locked out of my own data.
| However, this setup has so many components for syncing the
| info online and to interact with it. Quite frankly many of
| those components should be integrated into a single
| application. For example, mbsync can sync mail to a mail
| directory. But it needs go-imapnotify to trigger it when I
| receive a new mail. It's so frustrating that I considered
| writing those applications myself.
|
| In short, Emacs has nothing to do with the complexity.
| Instead, Org-mode and emacs has actually allowed me to manage
| that complicated configuration in one place, with lots of
| documentation. The draw.io diagram was for the information
| flow between different software components for the PIM and
| email setup - not for Emacs itself.
|
| Coming back to the complicated setup for PIM, I see a lot of
| new developments that promises to make it simpler. Hopefully,
| I won't need the org-mode power in the future to rein in the
| complexity.
| anonzzzies wrote:
| Treesitter and eglot are excellent. I am moving from vscode back
| to emacs and do far it's been a great experience. Should've done
| that a long time ago.
|
| Off-topic: what is an emacs quality alternative for docker? It's
| such a piece of garbage for something so pervasive.
| kstrauser wrote:
| I did the same a while back.
|
| I've been enjoying podman.
| anonzzzies wrote:
| Thanks will try.
| cropcirclbureau wrote:
| What aspects of Docker trouble you so?
| maccard wrote:
| I use containers on Mac and Windows for development (and we
| deploy on linux). Docker for Mac is _unusably_ slow in my
| experience. The VM that it runs is a giant resource hog and a
| battery hog, and doesn't support ipv6 [0] Docker Desktop
| itself is (another) resource hog, wildly buggy, and painfully
| slow. It's the epitome of "shitty electron app".
|
| On windows, docker desktop has all of the same issues as it
| does on mac. Docker's concept of volumes and file permissions
| on windows are nonsense. Windows updates and Docker Desktop
| regularly decide to disagree, [1] It's networking support
| interferes with other applications (like OpenVPN and the Xbox
| Game Center) [2].
|
| [0] https://github.com/docker/for-mac/issues/1432
|
| [1] https://github.com/docker/for-win/issues/599
|
| [2] https://github.com/docker/for-win/issues/1976
| pxc wrote:
| If you're developing for Linux via Mac or Windows and
| you're comfortable at the CLI, just forego Docker Desktop,
| install regular Docker (or podman) in a VM, and work that
| way.
|
| If you can, avoid using x86 Linux containers on Apple
| Silicon. Build some aarch64 ones for development and test
| your x86 images in CI and on the machines of devs using
| x86.
|
| Similarly, if you can avoid deploying your environment via
| Linux containers on macOS, do it. Use Nix to get reliable
| dev envs, and then use Nix to build your production
| containers. You'll have to take your time and learn
| something new, but it's insane how much faster it is and
| you can avoid dealing with all kinds of hassles with
| filesystem mounting and port forwarding and so on.
| anonzzzies wrote:
| I was typing this on my phone, but yes. This. Thanks!
|
| To add: Mac OS X docker actually, after a while, without
| errors, stops responding to running dockers and you
| _cannot_ remove them without reboot. It's total garbage,
| but cannot move from it as everyone uses it.
|
| So, emacs-stable alternative for docker. Maybe that should
| be a movement; emacs-alternative-for. I have many already;
| software that is fast, can run for months/years and doesn't
| get slow vs stuff you need to actually reboot for to run
| ok. I mean emacs is bloated (yeah right, compared to
| whatever others are pushing out?) but disk space, even sdd
| is almost free; it simply runs for months without memory
| growth or performance degradation. The only reason I stop
| it because of reboot for sec updates.
| maccard wrote:
| I've switched to orbstack on Mac. My experience is
| significantly better.
|
| It's the opposite of emacs-stable for docker, but it's
| what I want out of docker.
| anonzzzies wrote:
| Maybe we mean different things when saying that; I mean
| that I can throw anything sensible at it and it keeps on
| chugging. I know if I do something weird, it might die.
| During dev sessions I don't do that, I just want to run
| vanilla containers like mariadb, node etc and pray they
| don't randomly crash (they do).
| maccard wrote:
| Ah, ok. Yeah it works great. When you said emacs, i
| assumed you meant long term stable, libre philosophy.
|
| Orbstack is what docker for Mac should be.
| rhaps0dy wrote:
| I've been using Colima (which uses Lima, and QEMU under
| the hood) and it works fine for me.
| https://github.com/abiosoft/colima
| ajross wrote:
| Isn't this a kernel-side problem, though? The whole
| metaphor behind docker is "containers are super-fast and
| easy". And they aren't on OS X or Windows, you have to use
| a VM. And that's slower.
|
| There are tortuous and awful arguments around about whether
| this is inherent or not, or whether the tradeoffs are worth
| it or not, or where the blame lies. And I'm not interested
| in getting into any of that.
|
| Nonetheless the core idea behind Docker is slow on a Mac,
| because the Mac doesn't implement anything like the kernel
| feature on which it was built.
| maccard wrote:
| I don't believe so, no. I think it's an artifact of
| docker being engineered to run on Linux and taking the
| "easy" option of running a VM.
|
| I have no affiliation with OrbStack, but am a happy user.
| Orbstack is an example of what docker for mac should be.
| It's fast, lightweight, and it works.
| TacticalCoder wrote:
| I'd really love Emacs to have native JPEG XL support. For I use
| Emacs as a pictures viewer and the only thing preventing me from
| converting all my family pictures from JPEG to JPEG XL (it's a
| 22% saving which results in JPEG XL files that can be converted
| back, bit-for-bit, to the original JPEG file) is the lack of
| Emacs support for JPEG XL.
|
| Does anyone know if it's coming? Anything in the JPEG XL or JPEG
| XL libs license that makes it a problem to incorporate in Emacs?
| donio wrote:
| Emacs can handle JPEG XL files as long as you build it with
| ImageMagick enabled and ImageMagick is built with JPEG XL
| support.
|
| You can try evaluating (imagemagick-types) to see if it's
| enabled. If it fails with "void-function" that means that your
| Emacs was not built with ImageMagick enabled. If it returns a
| list of file types but the list doesn't contain "JXL" then your
| libMagick might be too old or not compiled with JPEG XL
| support.
| TacticalCoder wrote:
| Ah that's interesting, I wasn't aware. I'll try that and
| recompile if needed, thanks a huge lot for the info!
| TacticalCoder wrote:
| > ... then your libMagick might be too old
|
| I did check: I'm running the latest Debian stable, Bookworm,
| which basically just came out and it ships ImageMagick 6.9.11
| but apparently JPEG XL support was only added in 7.0.10.
|
| Oh the joy of running Debian! (I'll see if I bump ImageMagick
| to a more recent version or not).
| zellyn wrote:
| Why not add support? Nobody owns emacs any more or less than
| you!
| TacticalCoder wrote:
| Well ofc and I know some _elisp_ but I take it integrating
| _libjxl_ (now using the "new BSD license") or another
| library supporting _jxl_ is one of those things requiring C
| guru skills. And it 's been a really long time I haven't
| written a line of C code.
|
| Moreover I take it that, say, for someone who added WEBP
| support to Emacs, adding JPEG XL would be kinda a no-brainer.
|
| But I fully get your point...
| gjvc wrote:
| emacs has never been in better shape
| goku12 wrote:
| They have even started an Android port. It's on F-Droid already
| - though it's not very usable yet.
| spit2wind wrote:
| The F-Droid port comes from here:
| https://sourceforge.net/projects/android-ports-for-gnu-emacs
|
| Newer builds have better usability (although there are
| definitely still quirks). I recommend using it with the
| Hacker Keyboard for easy Meta-key access.
| goku12 wrote:
| I didn't know that! How is this related to the official
| android feature branch?
| sph wrote:
| For a 50 year old project, they have been quick to adopt new
| technologies like Tree Sitter lately. It definitely feels there
| is a lot of activity behind the scenes to remain as relevant as
| ever in face of editor fads such as VSCode and ( _ducks_ )
| NeoVIM.
| hfkwer wrote:
| Gnu emacs is only 38 years old. And vscode is a fad...?
| sph wrote:
| Sorry, for some reason I thought it was started in the mid
| 70s.
|
| But yes, compared to Emacs , Code is a passing fad, and I
| doubt it'll be around in 15 years, let alone in 38
| _emacsomancer_ wrote:
| Emacs did start in 70s ('76, I think), GNU Emacs is
| later.
| weebull wrote:
| VSCode is very much a fad, much like Eclipse, Atom, Sublime
| and any number of others before it. Emacs and Vim just keep
| going whilst others fade away.
| 7e wrote:
| There will always be an editor which is an order of
| magnitude more popular than emacs or vim, because it is
| an order of magnitude better. It doesn't much matter
| which one it is. People will switch to it, and be
| productive. And when something better comes along, they
| will move to that.
| kstrauser wrote:
| I strongly disagree that any editor will be an order of
| magnitude better than Emacs or Vim. Some new editors will
| be better in certain ways, or add cool new features
| before Emacs/Vim do, but there's nothing _completely_
| better than them. I doubt there ever will be.
| bitwize wrote:
| Emacs requires fiddling. Once you get past a certain age,
| you no longer want to fiddle with your tools; they should
| just work. A tool that just works may well be therefore
| orders of magnitude better than Emacs.
| kstrauser wrote:
| I think that downplays how much fiddling other tools
| take. I've never used another similarly powerful editor
| that didn't require similar amounts of configuration to
| be useful. And if getting some random plugin working
| means you have to tweak its code, it's almost certainly
| going to be fast and easier in Emacs than in the other.
| With Emacs, you can generally just replace a function
| after its been loaded. In other things, you may be
| forking a repo, editing/compiling it, and figuring out
| how to get the editor to load your version of it.
| bitwize wrote:
| VSCode is here to stay. After eight years it is by far
| the most popular programming editor and only becoming
| more so. The sun was already setting on Sublime and Atom
| by this long after their initial release.
| gjvc wrote:
| computing is a pop-culture; that which completely ignores
| what went before it, and continues to spend much of its
| time naively re-inventing the wheel
| bitwize wrote:
| Indeed, but VSCode is "sticky" in the way those other
| editors are not. It now has a critical mass of developer
| interest such that language and framework developers now
| put out tooling for it first (if it's not the only editor
| with official support). Other editors will have to make
| do with third-party tooling from a dwindling pool of
| contributors, falling farther and farther behind the
| state of the art.
| PurpleRamen wrote:
| Eclipse and Sublime do still exist and receive
| improvements. And VS Code is at the moment far too big to
| fade away in the next years, maybe even decade.
| EddieJLSH wrote:
| VSCode is not a fad - it has huge support from Microsoft,
| is the most popular code editor by far, and is a very
| good tool that's beginner friendly and allows for
| customisation. It is already almost a decade old. Visual
| Studio has been around since 1997 so there's a good
| chance VSCode will be around for a good few years too.
| gjvc wrote:
| IT is a fashion business, and fashion is fickle.
| bborud wrote:
| I used Emacs for all development work from about 1990 to
| 2018. About 28 years of development work in a dozen
| different programming languages. I also used Emacs for
| reading Usenet News and my email. I also used it for
| calendaring, planning, tracking work and a few other
| things.
|
| Gnus made Emacs a great Usenet news reader, but I could
| never get it to fit with my email regimen. And eventually
| Usenet died too. For about a decade I used a mail client
| that someone else originally wrote, but which I modified
| over the years to do email like I wanted to. But this
| became really tedious to maintain alone so I have up.
|
| Along the way I tried various IDEs like the tools from
| IntelliJ and Eclipse. None of them took. In fact, I
| figured it had to be me, so I promised myself to spend a
| few months every 2-3 years or so trying to get used to
| IDEs. (I still can't stand the IntelliJ and Eclipse
| tools).
|
| I think what made me switch to VSC was that I eventually
| grew tired of the constant annoyance of having to fix my
| setup so it would be reasonably useful for Go
| development. Emacs support for the Go language server was
| slow and shaky, and eventually I got so tired of having
| to make a patchwork of Emacs packages work that I gave
| Visual Studio Code a second chance.
|
| And the second time around it stuck. I'm not entirely
| sure why it stuck, but it did. It's been 5 years and I'm
| still using it. And I'm still not entirely sure why. I
| think it is mostly that I'm a programmer - not an editor
| enthusiast. Emacs was a pain in the neck to keep running
| when I switched. I liked Emacs, but VSC has better
| support for just about any language you care to program
| in.
|
| I ditched Emacs because I'm interested in writing code.
| I'm not interested in spending a day figuring out how to
| keep barely working Go support running so I can get work
| done. It's a tool. And when maintaining the tool starts
| eating into my productivity, it isn't worth the effort.
|
| The problem with Emacs is that it doesn't have a
| sufficiently large community. Which in turn means that if
| you are interested in creating tooling, your efforts will
| have a much bigger payoff if you choose something
| millions of other developers use. This is a vicious
| cycle.
|
| Last I checked, VSC had about 14 million users. Out of a
| global population of 25'ish million developers. That's
| slightly over half the global developer population.
| That's a pretty big market. I think a fair guess (given
| the stack overflow surveys) is that less than a million
| people use Emacs as their primary development
| environment. Which I find surprisingly high, but it
| should give people hope.
|
| Is VSC a fad? Who gives a crap? What matters is that, for
| me, and for a lot of other people, it is a better tool
| than Emacs. Because it is. If VSC is replaced by
| something else that works even better, and VSC
| disappears: who cares. Better tools is a good thing.
| Getting overly attached to tools that offer less is just
| weird and unproductive.
| gjvc wrote:
| could you summarize in 1 sentence?
| Aurelius108 wrote:
| I agree that sublime is a fad and maybe atom. Sublime's
| biggest mistake imho way their proprietary model combined
| with a plugin system, it'd probably be better to either
| make it free or make it very ease to use. I don't see
| eclipse or VSCode as fads though. To my knowledge eclipse
| is the only way to develop Java code on Linux platforms
| without paying for richer tools (let's face it, eMacs or
| vim doesn't have much support for Java). Also Microsoft
| seems very invested in VSCode
| shakow wrote:
| > eclipse is the only way to develop Java code on Linux
| platforms without paying for richer tools
|
| All the people I know are using IntelliJ CE.
| pk2200 wrote:
| I'm a long-time Emacs user, but VSCode is definitely not
| a fad. Microsoft is all-in on it, and it appears to be by
| far the most popular text editor.
|
| https://survey.stackoverflow.co/2023/#section-most-
| popular-t...
|
| https://trends.google.com/trends/explore/TIMESERIES/16907
| 280...
| ParetoOptimal wrote:
| > VSCode is definitely not a fad. Microsoft is all-in on
| it
|
| Similar to those who were all-in on Eclipse, Atom,
| Sublime?
|
| I do think vscode will stick around longer, but not
| convinced it'll be long enough to not feel like a fad.
| nullifidian wrote:
| >Similar to those who were all-in on Eclipse, Atom,
| Sublime?
|
| But all these (except sublime) including vscode are
| basically the same type of IDE. Yes, implementations
| change, but their share of the "market" remains about the
| same.
| alex_smart wrote:
| Eclipse and vscode are the same type of IDE? What?
| The_Colonel wrote:
| I think we're stretching the definition of "fad" a lot
| here. Editor being one of the most popular for 10 years
| (not yet there, but will be for sure) can't be considered
| "fad".
| pk2200 wrote:
| The two URLs I provided don't convince you that this
| isn't a fad? Of all the SWEs I know, every single one who
| previously used Eclipse, Atom, or Sublime is now using
| VSCode. Some of my Emacs & Vim friends have switched,
| too. I can't imagine what would change this trend in the
| next 5-10 years. Perhaps a new editor with an integrated
| LLM coding assistant that's FAR ahead of all competitors?
| Except VSCode is currently leading there, too.
| agumonkey wrote:
| it's a bit wider and better than eclipse/atom/sublime
|
| there's also the devcontainer and vscode server thing
| which make vscode a sophisticated commodity
|
| i don't use it, but i've seen the previous eras, the
| eclipse haydays .. and vscode doesn't feel the same
| gjvc wrote:
| vscode is the bitcoin of editors
| The_Colonel wrote:
| > For a 50 year old project, they have been quick to adopt
| new technologies like Tree Sitter lately.
|
| From the following it sounds more like a first step towards
| true adoption:
|
| > built-in support for TreeSitter. This means that a few
| years down the road we'll have many Emacs major modes that
| are much faster, robust and feature-rich.
| oslacci wrote:
| Is the configuration still "paste this mystery lisp code
| somewhere in a config / ini file in x,y,z place" or is it finally
| plug-and-play like in VSC?
| jks wrote:
| My experience is the opposite: I can keep my init.el in version
| control, and it contains Lisp code that I can run and debug by
| hand if needed. If some mode doesn't work right, I can step
| through its code and examine its variables. If I want to know
| what a key combination does, I can ask Emacs and it will tell
| me something like "M-s l runs the command consult-line (found
| in global-map), which is an interactive native-compiled Lisp
| function in 'consult.el'." So I know that the combination is
| defined in global-map, and the function is defined in
| consult.el, and I can easily find the code.
|
| In VS Code it's certainly easy to install an extension. Some
| mystery thing happens, and there are new commands available and
| some programming language support might be enhanced, but it is
| all very opaque. If I wanted to debug the code, I have no clue
| where to start. I'm sure it's there somewhere but all this
| looks to me much less discoverable than in Emacs.
| precompute wrote:
| You will not have this issue if you bother learning emacs lisp
| first. C-h is your friend.
| BeetleB wrote:
| As a multi-decade Emacs user, this sentiment was never
| correct, and needs to die. You can do insanely powerful stuff
| in Emacs without learning elisp. I myself was a power user
| for 9 years before I learned elisp. While it definitely gets
| you to the "next level", learning it was not a revolutionary
| improvement.
| gpderetta wrote:
| Learning elisp is indeed absolutely not required. But it is
| hard to use emacs for many years without learning a bit if
| elisp by osmosis.
| BeetleB wrote:
| The amount I knew was trivial: How to set a variable, and
| perhaps one or two other things. I didn't know how to do
| conditionals and for loops.
|
| For my config, beyond setting variables I mostly
| copy/pasted. It gets you very far.
| otabdeveloper4 wrote:
| M-x customize exists since forever, and is more plug-and-play
| than VSCode ever was.
|
| The real problem with Emacs is the shitload of bugs that case
| weird, undocumented and annoying behavior. A scripting language
| like elips is not meant for programming something as large and
| complex as Emacs.
| hollerith wrote:
| I dislike customize though whereas I like the GUI interface
| to settings in vscode.
|
| I agree Emacs has too many bugs (but I haven't found anything
| that suits me better for maintaining notes and to-do lists
| and such).
| _a_a_a_ wrote:
| I've found very few in many years' use. You may be a more
| competent user than I. Please report bugs, the devs are
| very responsive.
| precompute wrote:
| > The real problem with Emacs is the shitload of bugs that
| case weird, undocumented and annoying behavior.
|
| Could you name a few of these "bugs"? I use Emacs for
| practically everything and bugs are very difficult to
| encounter, even on Emacs HEAD.
|
| > A scripting language like elips is not meant for
| programming something as large and complex as Emacs.
|
| Well, that's just plain wrong. A lot of vanilla Emacs
| functionality is written in Elisp.
| teddyh wrote:
| In the menu bar, click "Options" - "Manage Emacs Packages".
| Install whatever packages you like. You can even configure
| third-party package repositories.
| ladyanita22 wrote:
| It's a shame modern distros don't ship with it...
| adr1an wrote:
| Yes! I have Ubuntu at my office and is difficult to get the
| latest emacs. I found a PPA but it has a bit of lagging
| behind..
| botanical wrote:
| There's a snap that's updated very quickly:
|
| https://github.com/alexmurray/emacs-snap/
|
| In fact, it's already updated
| trogdc wrote:
| Does this have native-comp enabled? Or do you still have to
| build from source for that?
| rolandog wrote:
| My approach has been to install Guix, and with Guix install
| emacs-next (and python-wrapper, and python-pip).
|
| I'm still a Guix newb, so all I can say is that there may be
| some tweaking to be done if you're using non-default paths,
| (e.g. XDG Base Directory Specification) [0].
|
| [0]: https://mail.gnu.org/archive/html/guix-
| devel/2019-03/msg0045...
| bachmeier wrote:
| It would definitely be nice to have an updated PPA, but
| compared to some apps, Emacs is simple and fast to compile -
| just a ./configure followed by make. (The first time, you
| need to install a few dependencies, but that's automated too,
| something like apt-get build-dep emacs).
| Y_Y wrote:
| I have a script to build it myself, took a little but of time
| to get right, but now it works nicely and I can stay at the
| bleeding edge.
| adr1an wrote:
| All these answers got me inspired. Might as well try this.
| But for the sake of not reinventing the wheel, Would you
| mind sharing? Maybe as a github gist or any pastebin would
| suffice. (PS. I'm already afraid the GCC version of my
| Ubuntu 20 throws issues hehe! Let's see!!)
| globular-toast wrote:
| Built it this morning on Gentoo!
| jjrh wrote:
| The core issue is there isn't a 'emacs.tiny' package that
| contains a small subset of emacs features.
|
| This makes it difficult to install emacs on a resource
| constrainted environment like a embedded system, and hard to
| justify installing on a server. (Yes we can use tramp but it's
| not always a option)
|
| It's a real shame and why I still need to know vi and vim.
| teddyh wrote:
| Debian and derivatives (like Ubuntu) have the "emacs-nox"
| package, which should qualify for your needs, I think?
| LanternLight83 wrote:
| It's a step in the right direction, but the issue is that
| there's so much that can't be removed from Emacs with build
| flags, eg. `lisp/play/`. Even setting the `-games` USE flag
| in Gentoo only removes cross-user score sharing[1], because
| (although less likely with games) you never know what
| modules might depend on within the standard distribution.
| Emacs is a big ball of stuff that no one's been willing to
| tease apart, even when it comes to modules that are
| _probably_ not going to be loaded at runtime.
|
| 1: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-
| editors/e...
| User23 wrote:
| One option is uEmacs (or one of its many forks such as mg).
| It's tiny.
| globular-toast wrote:
| Most emacs users I know retain a modicum of vi/vim knowledge
| for those situations where emacs isn't available. It's more
| because of the ubiquity of vi/vim, though. There are mini
| versions of emacs available like MicroEmacs and mg, the
| latter being more compatible with GNU Emacs.
| joobus wrote:
| I am an Emacs enjoyer. My biggest issue with Emacs is that
| development is still done via a mailing list and patches. I wish
| they would adopt a Git front-end (web UI) workflow.
| jeltz wrote:
| As an occasional developer of PostgreSQL which also does
| development on the mailing list I see pros and cons with it. It
| is harder to discuss lines of codes in a review on the mailing
| list but the nature of the mailing list (threading, etc)
| promotes much more nuanced and constructive discussions about
| patches on a higher level. Something which I have yet to see in
| any project on Github.
|
| Gitlab has some threading support but not very good one.
| broodbucket wrote:
| It's really not that bad, it's just different. There's pros and
| cons.
|
| https://git-send-email.io/ has a great tutorial for getting
| started.
|
| There's probably also a lot of emacs contributors that use
| emacs as their mail client that would be disrupted by replacing
| it with something web based.
| charcircuit wrote:
| You can use emacs as web client
| ParetoOptimal wrote:
| > There's probably also a lot of emacs contributors that use
| emacs as their mail client that would be disrupted by
| replacing it with something web based.
|
| The further I get into "emacs for everything" the more I
| appreciate using email for everything.
| joobus wrote:
| I think the mailing list flow is a hindrance to attracting
| the next generation of contributors.
| hackernan9000 wrote:
| As lazy as it seems, I've made a couple contributions to
| Neovim whereas I probably wouldn't have bothered if I first
| had to figure out a mailing list flow.
| pkkm wrote:
| Personally, I think that it's the copyright assignment
| that's the biggest barrier. For someone who figured out how
| to use Emacs, it shouldn't be very hard to figure out how
| to use a mailing list too.
| juxtapose wrote:
| 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.
| emacsen2 wrote:
| [dead]
| precompute wrote:
| The "next generation" of Emacs contributors will be Emacs
| users and will not have any issues using email for
| collaboration.
|
| Git was made for email. Needing a separate service for it
| is mostly cruft, when you have mailing lists. Yes, github
| has mass appeal, but a lot of software has been written
| with just email collaboration.
|
| As for attracting low-quality contributions, I don't think
| they matter. People who use Emacs and depend on it will
| contribute. Interest in Emacs has increased and so have the
| available features.
| cjohansson wrote:
| GNU Emacs is now dependent on TreeSitter which is a MIT-licensed
| project and LSP which is a Microsoft project. Also built-in
| support for non-gnu packages to install. Soon it will be a non-
| gnu project entirely. I think it's a bit sad that the ideological
| basis is beginning to be abandoned but I think there is not
| enough believers in the ideology anymore.
|
| I would say most modern editors (Helix, Neovim) do TreeSitter and
| LSP better than Emacs today and probably for many years to come
| natrys wrote:
| LSP I can probably understand, mostly for performance reasons.
| Native json parsing and native compilation goes a long way, but
| clients written in elisp seems susceptible to edge cases where
| it's not performant enough because UI and IO runs in same
| thread in Emacs. Not insurmountable even without
| multithreading, some newer clients that uses better IPC or the
| dynamic module system are not constrained by Elisp requirement
| and seems to be doing fine in terms of performance.
|
| The dynamic module system is generally a win for pragmatism
| over ideology, and it has been around for 7 years already. You
| can't do everything, like say extending core graphics of Emacs,
| but you can do a lot in any language of your choice if you feel
| constrained by Elisp. Tree-Sitter feature is built on top of
| that so it's not clear to me why do you think Emacs can't do
| better than say neovim. I use neovim and tree-sitter daily and
| generally don't think tree-sitter itself is rock solid yet, I
| run into indentation and slow query issues semi-routinely. But
| I am much more impressed with the work happening on Emacs
| community that leverages tree-sitter for advanced tooling [1].
|
| [1] https://github.com/mickeynp/combobulate
| _a_a_a_ wrote:
| Seems you have prior form in not knowing what you're talking
| about https://news.ycombinator.com/item?id=32632468
| 3836293648 wrote:
| Eh, I've been looking and haven't found anything for other
| editors that actually tries to use TreeSitter for anything
| beyond highlighting. The Emacs structural editing packages are
| still very WIP but at least they exist.
|
| (And also some have been based on the out of tree
| implementation that's been around for a while now)
|
| Example: https://github.com/mickeynp/combobulate
| lawn wrote:
| There are quite a few packages for neovim that use treesitter
| for structural editing, folding, jumping and viewing.
| 3836293648 wrote:
| Well, they really need to up their SEO, because I found
| _one_
| YetAnotherNick wrote:
| MIT code could be used in GPL, but other way round is not
| possible. As long as there is a line of code with GPL license,
| entire project will be GPL.
| p_l wrote:
| Not really, only when it can be shown that the project is
| derivative of the GPL code (for example, hard dependence on
| GNU-only library for some of its features vs. "one of the
| multiple possible implementations we can use is GPLed")
| dimitar wrote:
| X-windowing system is also MIT-licensed, were they every
| avoiding that license?
| hvis wrote:
| > GNU Emacs is now dependent on TreeSitter which is a MIT-
| licensed project and LSP which is a Microsoft project
|
| Not really dependent (you can build and use Emacs without
| either).
| SeqDesign wrote:
| > I think there is not enough believers in the ideology anymore
|
| I don't know what ideology you're talking about, but the only
| one I've ever had is the Emacs ideology: use the best program
| ever made and be happy.
| pkkm wrote:
| Why is it a problem that LSP was originally invented by
| Microsoft? It's an open protocol with many free-software
| implementations. You don't have to use any Microsoft code if
| you don't want to.
|
| Besides, even if that wasn't the case, Emacs has long had a
| policy of interoperating with non-free software. It runs on
| versions of Windows from _98_ to 11. That 's not because its
| developers don't value free software, but because they realize
| that this is a more effective way of convincing people to use
| free software than insisting on absolute purity.
| ilyt wrote:
| Tell me you know nothing about licensing without telling me you
| know nothing about licensing...
| goku12 wrote:
| >LSP which is a Microsoft project
|
| Emacs' LSP client Eglot and many of the LSP servers have
| nothing to do with Microsoft. Honestly, LSP is one project that
| I'm thankful to MS for. Personally, I value open standards like
| LSP more than any single FOSS project.
| globular-toast wrote:
| I haven't touched my emacs config in a while, looks like it's due
| for a big update! I'm excited!
| jwr wrote:
| So happy to see my favorite IDE for the last 30 years being
| actively developed and maintained. Multiple IDEs have come and
| gone over those 30 years, and I waved to them on their way as
| they arrived and then as they passed away into nothingness.
|
| Every time a new IDE arrived, crowds cheered, and it was all the
| rage and fashion, while my Emacs was called "obsolete", "hard to
| use", "bizarre", and other things. I spent some time over those
| 30 years looking at new IDEs, trying them out, configuring them,
| and each and every time this was time wasted, because the IDE was
| discontinued, abandoned, or otherwise became useless.
|
| If I could tell something to my younger self, it would be: keep
| faith in solutions that are open and have been around for a
| while, you will save a lot of time over the years.
| rdtsc wrote:
| Same here. It's the oldest continuously used piece of software
| for me. I tried it first on a Sun Unix workstation at the
| university around the late 90s. I've tried komodo, vscode,
| sublime, vi and many others and still use emacs. The funny
| thing I don't even know that many key combinations and use only
| a few customizations.
|
| I was pleasantly surprised when I was issued a mac at work that
| most of the basic editing commands on macos text widgets
| support emacs key bindings (ctrl+a/e/k/p/n).
| krylon wrote:
| Those keybindings are one of the very few features of macOS I
| missed after going back to GNU/Linux. It's such a nice
| thought, especially with macOS using the command key for
| most, uh, commands - it doesn't impose any burden on non-
| emacs-users, but for those who are used to those keybindings,
| it's bliss.
| nextos wrote:
| GTK used to support a similar thing up to version 2? One
| needed to enable it with: gsettings set
| org.gnome.desktop.interface gtk-key-theme "Emacs"
|
| Sadly, I think support was removed. Part of the problem was
| that this and other themes were in conflict with preset
| bindings, e.g C-p for a print dialog.
| krylon wrote:
| Yeah, on macOS it works well, because the Ctrl-based
| shortcuts don't get in the way of the regular
| keybindings.
| adr1an wrote:
| Those are 'readline' keybindings actually, and available in
| many term, shells, repls... Sometimes, just a config away.
| See: https://www.masteringemacs.org/article/keyboard-
| shortcuts-ev...
| nvy wrote:
| >Emacs was called "obsolete", "hard to use", "bizarre", and
| other things.
|
| As a daily emacs user, it is all those things. It's just also
| awesome if you put in the time to get over the hump and learn
| it.
|
| The "out of box" experience for emacs is really, really bad.
| [deleted]
| xyproto wrote:
| This is an emacs-centric world view and many of the same
| arguments applies to open source software in general.
| jwr wrote:
| Most definitely not. In fact, much of open source is
| haphazardly developed without regard for backwards
| compatibility, often also introducing change for no good
| reason (the word "cleaner" should always raise red flags).
|
| Source: a certain developer/admin/netadmin with >30 years of
| experience using open source software.
| pama wrote:
| I'm also very happy with Emacs' continued existence. Frankly, I
| don't know what I'd do without M-x shell plus related hacks,
| but I think I'd have to reinvent the concept of having
| arbitrary numbers of named shells with infinite output/input
| streams attached to them, with searchable histories, etc. Just
| like the unix concept that everything is a file was super
| powerful, so is the Emacs concept that everything is text. And
| of course lisp helps smooth things out whenever there are rough
| edges.
| jon_adler wrote:
| No an eMacs user myself, but do you ever imagine a time when
| the software might be considered "done"?
| golem14 wrote:
| TeX and LaTeX are pretty close to 'done'
| nanna wrote:
| Nah. LaTeX is undergoing major development at the moment to
| support automatically tagged pdfs, and the latex3 work is
| still, as far as I understand, still ongoing too.
| knome wrote:
| "[a program] is never finished, only abandoned"
| ssivark wrote:
| In a field as young as software, three decades is too long
| for almost any software tool to remain frozen. Many new ideas
| might have built up -- especially as the world around you
| (and needs) changes. You might keep writing extensions for
| your tool, or release periodic updates, or freeze your tool
| and call it "done", and write a new tool every few years...
| they are all different ways to handle the same underlying
| mechanics.
| jwr wrote:
| No, I think there is always something you can improve or add.
| The point, I think, is to do it carefully, though, without
| breaking things. Python is an example of how not to approach
| software evolution. Emacs and Clojure are examples of how
| software can be maintained over the long term without
| breaking backwards compatibility.
|
| When I was young (and, ahem, stupid), I didn't care -- I was
| all gung-ho, shoot from the hip, and if something breaks,
| tough. As I matured, I learned that backwards compatibility
| and long-term maintenance should be valued and cherished. Not
| just because if you're not careful, you have to fix the
| things that break, but also because as you start doing more
| and more things in your life, you have less time for each
| thing and you'd rather move forward rather than spend time
| fixing things that break.
| jon_adler wrote:
| Python is an interesting example to choose as a negative
| example. I presume you are referring to the evolution from
| v2 to v3. The popularity of Python has exploded in recent
| years, possibly as a direct consequence of tough decisions
| and breaking backward compatibility. I guess it is a
| subjective topic and an individuals position depends on how
| they define success.
| 7thaccount wrote:
| Yeah. I'm always a little confused by this. It's still
| one of the most popular languages and growing for a
| reason. It surely isn't perfect, but no technology is.
| The tradeoffs they made have worked really well for a lot
| of people.
| throw156754228 wrote:
| Is performance any better than 28 on Mac? I recently tried
| putting 28 on my work M1 and magit diffing on the status screen,
| where you can roll up diff hunks by hitting minus, was unusably
| slow on large files. My own Linux laptop has no such problem.
| billfruit wrote:
| Does intellisense like autocomplete now work out of the box? Is
| company bundled in, as of recent versions? Is there any
| dependency on Clang to get it working for C/C++ code?
| yissp wrote:
| You still need to set up an LSP server, so not exactly out-of-
| the-box. Something like clangd or ccls for C/C++.
| gnuvince wrote:
| Eglot is the built-in LSP client. You need an external server.
| If you do C or C++, clangd is likely what you want. Install it
| (apt install clangd) and enable eglot for C or C++ files in
| your Emacs config, (add-hook 'c-mode-hook 'eglot-ensure).
| TacticalCoder wrote:
| Which version am I running yet? (I know it's not too old for I
| regularly compile Emacs from source) ELISP>
| (emacs-version) "GNU Emacs 29.0.60 ..."
|
| Ah... Time to upgrade ; )
| grumpyprole wrote:
| What an amazing release. Thank you to all that contributed and
| made it happen!
| goku12 wrote:
| And they haven't even started taking full advantage of Pure-GTK
| and Treesitter. This release will cause an explosion new
| packages based on them.
| mssdvd wrote:
| What kind of new packages would spawn from the introduction
| of PGTK?
| goku12 wrote:
| This video discusses the work on pure gtk:
| https://www.youtube.com/watch?v=LPwr8WeE8jU . I found it by
| following this story. It talks about Emacs essentially
| becoming a GTK widget and possibility of nesting GTK
| widgets in Emacs. I'm not fully aware of what they will
| lead to.
| ezekiel68 wrote:
| Nothing kills it!
| treeblah wrote:
| Really happy to see this. I've been using Emacs 29+ for the past
| while and have enjoyed simplifying my configuration now that use-
| package is OOTB. I think now is a really excellent time to try
| Emacs if you haven't already.
|
| I put together a simple tool to generate a starter Emacs config
| from a few configurable options, which I can now update to point
| at a proper release channel instead of a prerelease:
|
| https://emacs-config-generator.fly.dev/
| teddyh wrote:
| > _Emacs is now capable of editing files with very long lines.
| The display of long lines has been optimized, and Emacs should no
| longer choke when a buffer on display contains long lines. The
| variable 'long-line-threshold' controls whether and when these
| display optimizations are in effect._
|
| Yes!
| mark_l_watson wrote:
| Looks good. For me, the best recent feature is native compilation
| so Emacs feels super fast and responsive. I often use macOS and I
| wonder is going to GTK will help a lot there?
| blahgeek wrote:
| Native compilation has been in emacs since 28.1.
|
| AFAIK native GTK should be unrelated to macOS since macOS
| version uses its own cocoa frontend
| [deleted]
| bingemaker wrote:
| How do you compile Emails on OSX? I use `brew install emacs-
| head@30 --with-cocoa` and I feel that org-mode is bit laggy. Is
| there a better way?
| mediumsmart wrote:
| download the source, unpack, cd into directory, ./autogen.sh,
| ./configure --with-imagemagick --with-json --with-mailutils
| --with-modules --with-rsvg --with-gnutls --with-xml2 --with-
| native-compilation=aot --with-pop --without-compress-install
| --without-dbus, gmake (gnumake from brew), src/emacs to test,
| gmake install, pickup the app in nextstep and done I think.
|
| (thats on intel monterey though)
| kstrauser wrote:
| Add `--with-native-comp` to that.
| bingemaker wrote:
| Thanks, time to try this
| kstrauser wrote:
| Oh, I just realized I'm using
| https://github.com/d12frosted/homebrew-emacs-plus . I
| recommend using that over the default formula.
| agumonkey wrote:
| makes me wonder, is the target of native compilation something
| general like 386 ? can i share .eln between x86 computers ?
| aardvark179 wrote:
| As another commenter has said native compilation has been there
| for a while, but you may need to explicitly enable it if you're
| installing via brew or similar. The macOS port doesn't use GTK
| or X unless you specifically link them. What problems are you
| having?
| ducktective wrote:
| I wonder if the latency would be comparable to neovim/vim? I've
| only tried Emacs without nativecomp and the really noticeable
| input lag left a bad impression.
| lycopodiopsida wrote:
| As someone, who jumps between neovim and emacs on a regular
| basis - no, neovim is much faster. If speed and general
| snappiness is your most concern you should stay with neovim.
|
| But, emacs is in most cases fast enough, faster than vscode
| and has other advantages.
| mplanchard wrote:
| Native compilation makes a big difference, but neovim is
| still snappier, especially if you're using lots of packages
| or a framework like doom or whatever
___________________________________________________________________
(page generated 2023-07-30 23:02 UTC)