[HN Gopher] EmacsConf 2024 Notes
___________________________________________________________________
EmacsConf 2024 Notes
Author : JNRowe
Score : 324 points
Date : 2024-12-28 14:22 UTC (1 days ago)
(HTM) web link (sachachua.com)
(TXT) w3m dump (sachachua.com)
| duozerk wrote:
| As someone who exclusively uses emacs for all their editing, some
| nice topics there; though a bit miffed it's all video only.
|
| Although this, from the page linked, was pretty fun:
| https://www.youtube.com/watch?v=urcL86UpqZc
| sctb wrote:
| On the main page for this year there are all kinds of media
| available, audio, video, slides, transcripts, Q&A:
| https://emacsconf.org/2024/talks/.
| duozerk wrote:
| My bad, thank you !
| uludag wrote:
| > EmacsConf feels like a nice, cozy get-together where people
| share the cool things they've been working on and thinking about.
|
| Emacsconf was indeed executed great this year, and nice and cozy
| were my feelings too. It's interesting to compare and contrast
| the ambience between Emacsconf and that of the other editors'
| like neovim conf and the release "parties" of Visual Studio Code
| and Jetbrains.
| Handprint4469 wrote:
| What was different about it compared to the neovim conf?
| Keyframe wrote:
| People can't seem to find an exit.
| lbj wrote:
| Wow, that's actually hilarious!! :D
| iLemming wrote:
| You don't "exit" Vim, tis not a stage - you quit it. And
| then go to Emacs because tis a killer, a vocation from
| which there's no quitting - it is for life.
| alfiedotwtf wrote:
| It's wild doing the following on a shared production
| machine. I've seen 30+ sessions unattended for days:
| ps aux | grep vi
|
| People not knowing how to quit vim is a meme but at the
| same time is real as ever.
| pjmlp wrote:
| Maybe my error was XEmacs instead, I only put up with it
| until IDEs finally became part of UNIX culture.
| iLemming wrote:
| For non-emacs nerds who didn't get the joke - command for
| exiting Emacs is 'M-x kill-emacs', also, you don't
| "delete-word" in Emacs, command for it is 'kill-word',
| there's also 'kill-paragraph' and so on.
| trelane wrote:
| Now I wish there were a way to yank emacs after killing
| it.
| hadjian wrote:
| I respect you for that joke.
| downut wrote:
| People like the organizer.
| sitkack wrote:
| I wouldn't believe how well it was run if I wasn't there. Sacha
| is a powerhouse, the amount of code she wrote in elisp to make
| this conference happen with the quality it did is just amazing.
|
| Thanks Sacha!
| JadeNB wrote:
| I had no idea that there was a NeovimConf! It's kind of a shame
| that it's so low in the search rankings that searching directly
| for it seemed to turn up only hits for Neovim configuration
| files, so I hope that I may be forgiven for linking here:
| https://neovimconf.live .
| dingnuts wrote:
| honestly the community Emacs has really sets it apart, and it's
| a piece of software where the GPL makes sense and shines and
| this is super clear in the Emacs community.
|
| It gives me hope for the longevity of the editor, and indeed,
| in the short ten years I've been a casual user it has only
| gotten better.
|
| Long live the Emacs community
| llm_trw wrote:
| Emacs is good because the barrier to entry is so high. Anyone
| who sees elisp and doesn't run for the hills is the type of
| person who has interesting ideas.
| mahmoudimus wrote:
| That was the defining reason for me to switch from vim to
| emacs :) still have the date on my calendar and I celebrate
| my emacs-versary with M-x tetris :D
| sph wrote:
| I still chuckle whenever someone tries to remake Emacs
| using Lua, completely missing the reason Emacs is so
| powerful is because it's written on a Lisp.
|
| EDIT: looks like even in this thread people are suggesting
| to use Lua instead of elisp. smh
| iLemming wrote:
| Kids that dismiss Lisp without even grasping the amazing
| power behind it, remind me the story of Yanomami
| languages of Amazonian tribes. Apparently, there's word
| for 'one' and for 'two', but there's no word for 'three',
| in their language, only a generic word that basically
| means 'a lot'.
|
| Now imagine trying to explain to them the concept of
| subtracting a hundred from a billion and the most
| straightforward way to deal with that is a decimal
| numbering system. I think they'd kill you for
| blackmagicfuckery on the spot.
|
| Well, if that comparison feels condescending, let's
| imagine ancient Romans - with all their sophisticated
| culture, economy and traditions. They wouldn't kill you,
| but still the idea of a number such a billion would
| probably terrify them. They'd probably be like: "dear
| sapientissime senore, we respect your wisdom, but we
| rather use... Lua"
| anthk wrote:
| Romans knew about thousand based multipliers with a mark
| over the letter.
| JonChesterfield wrote:
| Lua can be viewed as a pretty solid lisp dialect. You've
| got the compiler available at runtime, first class
| functions and coroutines, sensible language runtime. Type
| system is pretty much the same. It doesn't do the phase
| separated macros out of the box, but metalua does.
| Performance is rubbish and the syntax is a parse away
| from the s-expression ast but whatever, the semantics are
| right.
| kragen wrote:
| I mostly agree.
|
| Probably Stallman would object that Lua doesn't have read
| (apart from eval) and print.
|
| As for performance, LuaJIT performance is better than any
| Common Lisp or Elisp, and dramatically better than the
| first 35 years of Elisp, before native-code compilation.
| anthk wrote:
| Any common Lisp? SBCL is no turtle.
| kragen wrote:
| Compared to LuaJIT it is, unless you monomorphize and
| turn off safety checks, at which point you're basically
| programming in C with Lisp syntax.
| ajbt200128 wrote:
| Amazing work again! EmacsConf was as fun as ever this year
| krylon wrote:
| There was supposed to be one talk about an attempt to re-vitalize
| a Guile-powered Emacs. I am not sure if it's in there somewhere
| or not (but I haven't looked yet).
|
| I imagine Emacs gaining native compilation capability took some
| pressure off that. But the appeal of scripting Emacs in languages
| other than Elisp still has some appeal, I think. Scheme or Lua
| would very nice for that purpose.
|
| EDIT: There it is - https://emacsconf.org/2024/talks/guile/
| bjoli wrote:
| I think just having a proper runtime for elisp would be
| great...
|
| I am a guile person, but even if the Emacs folks would only
| allow elisp on guile it would still be a win.
| mdaniel wrote:
| > or Lua would very nice for that purpose.
|
| There have been a couple of front-page threads on Lua recently
| and their comments really show how polarizing of a language
| that one is
| mahmoudimus wrote:
| I feel very strongly against Lua. I use it for WoW add on
| development all the time - I make so many mistakes with the
| 1-based index when porting algorithms. It is very very
| painful.
| iLemming wrote:
| why not Fennel?
| mjcohen wrote:
| Fortran has arbitrary-based indexing forever (as does Ada).
| The default is 1 but it can be specified as anything. I
| don't see why this capability is so rare.
| kragen wrote:
| It has that in common with Lisp!
| lysace wrote:
| I wonder how many users Emacs has lost to VS Code over the past
| few years. I'm one of them.
|
| Feels sad. And also potentially shortsighted.
| f1shy wrote:
| Is a matter of time until it will be enshitified, and they come
| back...
| lysace wrote:
| I guess there are two aspects to the the typical process of
| MSFT enshittification:
|
| a) lack of regular revenue leading to bizarre product
| management choices (probably not a case, because of GH
| Copilot subs)
|
| b) initial really talented team members gradually being
| replaced by bozos because of entropy and/or management (work
| on something new/important)
|
| I suppose b) is the most obvious risk.
| devjab wrote:
| I think option A is actually part of their problem. Not
| because they lack revenue but because they are successful
| with it. You mention Copilot but VSC integrates with a lot
| of Microsoft owned cloud services as the "default" or
| "first class citizen". I'm not sure why people would use
| the Azure extensions over the AZ cli, but they are
| obviously rather popular. It's a lot like how Google search
| became the default search in a lot of products, except here
| it's GitHub, Azure and so on.
|
| On top of that they get some wild telemetry. Your privacy
| data is obviously safe, but the metadata they collect goes
| right down to your project structure. So Microsoft knows
| what sort of projects and in what sort of languages
| everyone uses. They know what you're putting into your
| Azure cloud and they know if you're not using Azure. I
| imagine these things are rather valuable to the biggest
| tech company in the world.
|
| Obviously they're going to focus their development on
| upselling Microsoft products to you. Which will only get
| worse as they succeed more and more. Because why wouldn't
| an enterprise company do that?
| iLemming wrote:
| Yup. The prospect of having to someday switch to VSCode
| unnerves me. It's not because it's technologically
| inferior to Emacs or because of my habits, muscle memory,
| dogmas, or childhood traumas. It's because of Microsoft.
| I just can't blindly trust the good intentions of a mega-
| corporation. A behemoth that expends huge amount of
| resources constructing a modern code editor packed with
| numerous features that they then offer at no cost. When I
| used IntelliJ and paid for it, I understood precisely
| what I was buying, I understood their revenue model. Then
| I switched to Emacs - which is only theoretically free -
| as it cost a substantial amount of time, dedication, and
| energy. I still understand who benefits from my choice -
| the community, me, and the wider industry too. Every time
| I activate a VSCode instance, I'm unsure of the exact
| cost that I'm incurring. It already felt like a hostage
| situation when they took over GitHub. If everyone is now
| must become a VSCode user, I don't even understand how
| people don't realize how dystopian that is.
| devjab wrote:
| I don't see why you would ever have to switch to a
| certain IDE, but I can see from some of the other
| comments a lot of people seem to be unfortunate enough
| not to have the choice. One of the reasons I like emacs
| (again in in doom so it could be Neovim) is that it's
| basically an IDE I can use forever and easily get working
| on any computer by pulling my dot files from my git repo.
| I say easily but it's obviously not easy on windows
| considering you sort of need WSL, C server and to install
| some LSP support.
|
| I understand why people like VSC, but at the same time
| I've seen people go from other IDEs to VSC and now many
| are going yo Zed. Mean while I can just trundle along in
| the same IDE. Some of the emacs purists haven't had to
| learn a new IDE for decades and likely never will.
|
| To each their own of course.
| iLemming wrote:
| > I don't see why you would ever have to switch to a
| certain IDE
|
| Alarmingly, basic proficiency in VSCode becoming a must
| in many software developing teams and I don't like that.
| People really seem to have zero concerns about Microsoft
| aggressively pushing their proprietary agenda, neatly
| wrapped in "open-source" packaging.
| devjab wrote:
| I'm genuinely wondering why you would chose VSC over emacs.
| Granted, I'm on doom emacs and it's mainly because I'm too lazy
| to config Neovim, so it's not like I'm really a purist. I even
| use VSC occasionally when I'm in a context on my lovely windows
| work computers where I don't have access to WSL, but it's such
| a horrible experience. It's slow, the plugins are ass and the
| LSPs are horrible for basically anything which isn't
| Typescript.
|
| I don't even think VSC is "that" bad despite what I made it
| sound like, but it's probably as temporary as any other modern
| IDE. In a few years "every" VSC user will probably have moved
| on to Zed. Meanwhile your emacs (or vim) dot files will setup
| the only IDE you've ever used on any machine.
| lysace wrote:
| I started using GNU Emacs in the mid 1990s. I like the
| ergonomics of the interface. It's muscle memory since long. I
| _tolerated_ the LISP aspect.
|
| In VS Code I use the "Awesome Emacs Keymap" extension by
| Yuichiro Tachibana (Tsuchiya):
|
| https://marketplace.visualstudio.com/items?itemName=tuttieee.
| ..
|
| What won me over? GH Copilot + the overall packaging. It just
| works. Good, polished UX. Emacs needs to catch up on this
| front.
| BeetleB wrote:
| Copilot is available on Emacs, but yes, a lot less
| polished.
| arrsingh wrote:
| I've been using emacs for 30 years and have tried VS code
| several times but the muscle memory on Emacs has prevented
| me for switching. I've gotten LSP on emacs working well
| enough but the performance just isn't there. So today
| thanks to your suggestion I tried it once more with the
| Awesome Emacs Keymap extension and right away I ran into
| not having dired mode to switch files.
|
| A quick google search got me vscode-dired (incase anyone
| else runs into it):
|
| https://marketplace.visualstudio.com/items?itemName=rrudi.v
| s...
|
| Quick Tip: I set C-x C-d, C-x C-b and C-xb all to call
| extension.dired.open per this stackoverflow:
| https://stackoverflow.com/questions/62235792/how-to-add-
| mult...
|
| that seems to satisfy the muscle memory... and it seems at
| first glance that this time the switch to vscode might
| actually stick. (thanks for the link to the emacs keymap
| extension)
|
| We'll see how it goes!
|
| edit: After even 5 minutes of building some rust code I ran
| into too many issues! I love the syntax highlighting in VS
| Code and everything else but I have way too much custom
| elisp to build and debug Rust/Go/C++ and recreating all
| that in VSCode or learning the new bindings is a bridge too
| far! I would pay real money to someone who would build an
| amazing performant experience for emacs. Sigh.
| throwup238 wrote:
| Depending on the language you use VScode might not be any
| more performant because it probably uses the same LSP on
| top of electron instead of elisp. I write Rust/C++ on a
| sizable project and since everyone depends on rust-
| analyzer* all IDEs are just unbearably slow and mostly
| useless in language integration beyond basic refactors
| and click to go to definition.
|
| * except RustRover but that comes with its own set of
| issues
| arrsingh wrote:
| yes its rust. Looks like you're right. Well is back to
| good old emacs for me!
| throwup238 wrote:
| _> I have way too much custom elisp to build and debug
| Rust /Go/C++_
|
| What kind of emacs scripts do you write to help debug
| Rust?
| arrsingh wrote:
| Nothing special or too sophisticated. On the one hand I
| use Just (a command runner) to standardize specific build
| and test commands that call cargo with various flags.
| Here is a simple example from one of my repos:
| https://github.com/deepmesa/deepmesa-
| rs/blob/mainline/justfi...
|
| Then I have a bunch of elisp code that calls just and /
| or generates boilerplate code right in the buffer - M-x
| new-macro or M-x run-test (asks for a test to run) etc. I
| keep writing more elisp as I go along and add specific
| key bindings to specific things and now its too hard to
| move away from it all.
| iLemming wrote:
| > LSP on emacs working well enough but the performance
| just isn't there.
|
| Have you tried https://github.com/blahgeek/emacs-lsp-
| booster? Also, build Emacs --with-native-comp flag
| iLemming wrote:
| > It just works.
|
| That "it just works" thing gets me all the time. I just
| don't get it. Some things surely do work nicely out of the
| box in a proprietary specialized tool, like for example
| JS/TS-related things indeed are very nice in VSCode. Just
| like Java-related stuff works great in IntelliJ.
|
| But programming is far more than writing code. I can argue
| that writing in plain English for a programmer is perhaps
| far more important than writing in a PL.
|
| And for any kind of plain-text manipulation, Emacs
| absolutely has no match today. Of that, I'm certain,
| because I have watched and followed many VSCode/IntelliJ
| power users and long-time users, and I do occasionally use
| those tools personally as well. There are so many practical
| example use cases where Emacs just kicks things out of the
| ballpark - from sending requests to LLMs in the midst of
| taking notes, to controlling video playback, and annotating
| PDFs - typing those annotations while browsing the
| document.
|
| And then that "it just works" fallacy. No cookie-cutter
| solution ever can make a true coder happy. How can one not
| get annoyed by a bunch of minor, seemingly not-big-of-a-
| deal issues over a long period of time? Like having to use
| the mouse for certain operations without a good
| alternative, or fixed keybindings that can't be fully
| customized, or the search bar not remembering your last
| search position and parameters? It's like buying a car with
| seats at a fixed angle and not even being able to change
| that.
|
| I mean, sure, Emacs may seem dauntingly complex at first
| glance, but the initial investment in learning this
| infinitely hackable tool pales in comparison to the
| countless hours lost wrestling with the unchangeable
| constraints of less adaptable alternatives.
|
| > I tolerated the LISP aspect.
|
| I don't know the extent of what you meant by that, but I
| guess you've "acquired a vehicle," using it to commute and
| go grocery shopping, and never even realized that you had
| an actual spaceship all this time. Emacs is most
| importantly "a Lisp Machine" with a built-in text editor
| and not the other way around. It is exactly Lisp that makes
| it so fascinatingly hackable. One chooses Emacs, Lem, Light
| Table, etc., specifically because of Lisp, not to
| "tolerate" or "suffer" through dealing with it.
| sgillen wrote:
| I switched because all my coworkers use VSC, just easier to
| have extensions like linters and goto definitions synced, we
| can help each other with any issues in the workflow.
|
| Still use emacs + org mode for notes though, and spent quite
| a lot of time getting VSC to act like emacs in terms of
| shortcuts etc.
| BeetleB wrote:
| > Still use emacs + org mode for notes though,
|
| Sounds like you didn't switch, but rather added another
| tool in your toolbox.
|
| The constant comparisons to VSCode frustrate me because
| they're often presented as "either-or".
|
| I use Emacs. And I use VSCode.
| lucasoshiro wrote:
| > The constant comparisons to VSCode frustrate me because
| they're often presented as "either-or"
|
| I can say the same for Vim... My primary editor is Emacs,
| but I use vim if I want to edit something quickly in the
| terminal (config files, git commits, etc). If the
| codebase is bigger then I use the JetBrains IDEs...
|
| I installed VSCode but I just don't like it. Until today
| I didn't find a use case for it being added to toolbelt.
| But I must admit that it almost won the editor wars,
| people just suppose that you use it.
| tcoff91 wrote:
| Do you use EViL mode?
| lucasoshiro wrote:
| No. I have used exclusively Vim for some time before
| going to Emacs, and I switched because the package
| management in Emacs was better and because the plugins
| were more polished. Then I wanted to do "the official
| way", using the default Emacs keybindings, even though I
| find the Vim keybindings better.
|
| I switched in late 2015, things were different back then.
| If it was today I think I would probably jump to Doom
| Emacs or Neovim.
| subjectsigma wrote:
| > It's slow
|
| What?
|
| > the plugins are ass > the LSPs are horrible for basically
| anything which isn't Typescript
|
| _What??_
|
| I need to edit projects on a remote machine nearly every day.
| (I do cross-platform Python dev so I need to run and test
| code on Windows and Linux VMs while working on a Mac.)
| Compare VSC's Remote Edit plugin to TRAMP and let me know
| what you think. For me it's not even a contest. TRAMP just
| simply doesn't work in a majority of use cases and I've only
| had a few small hiccups with the VSC Remote Edit. Getting LSP
| plugins working over TRAMP on another machine is hell. I just
| use Emacs for org-mode and Magit now.
| IceDane wrote:
| Anyone comparing tramp to Vscs remote editing is
| delusional, and I say this as an emacs user.
| otabdeveloper4 wrote:
| VSCode remote editing is a broken piece of shit.
|
| [Yeah, yeah, I know, I shouldn't be running NixOS and I
| should use a Microsoft (c) approved OS instead like all
| the cool kids. Wake me up in 100 years when Microsoft
| ceases to exist.]
| ParetoOptimal wrote:
| For fully local things like docker containers or across
| lan, its comparable if you use SSHControlMaster.
|
| Also, the emacs approach uses very little resources. This
| matters if your LSP server takes 80% of your RAM. Vscode
| takes 20%, emacs/tramp doesn't.
| subjectsigma wrote:
| I can't tell from this comment if this means you like VSC
| remote editing or dislike it
| d0mine wrote:
| Most of my work projects require remote machines. But I
| edit local files most of the time (in Emacs). Unit tests
| may be run locally sometimes (docker or even on the
| localhost). Other tasks/tests run remotely and setup may be
| rather involved (VSC would be of little help here) but it
| is easy to use/extend (Python glues together some ssh
| commands and cloud APIs). The code may be synced (non CI
| case) using a customizable wrapper around entr & rsync
| (more efficient, more control, more reliable than VSC
| plugin)-- it helps with the fast feedback loop.
| shepherdjerred wrote:
| At the very least it's useful to use the tools that your
| coworkers are using. If you're helping a new grad out you do
| _not_ want to recommend that they use emacs over VS Code.
| And, when they have questions about VS Code, it's useful if
| you can answer them.
|
| Maybe you don't have to use VS Code full-time, but having a
| knowledge of it is useful.
|
| Personally, I started using VS Code because support for
| frontend is much better there than in JetBrains IDEs and it
| has great remote editing capabilities. I would prefer to use
| JetBrains IDEs (I did for many years, and I still go back for
| Java), but VS Code is just better. I would never use Vim for
| editing full-time, though I do use lunarvim when I need to
| quickly edit a remote file.
| golly_ned wrote:
| I use doom too. It's slow vs VSC for me and doesn't have a
| lot of code intelligence actions easily accessible. The LSPs
| are great for languages I code in, Go and Python.
| mardifoufs wrote:
| What do you mean by slow? Like, slow at doing what? I can't
| think of a specific feature that is slower on vscode. Emacs
| is actually rather slow...
| cerved wrote:
| Starting
| ParetoOptimal wrote:
| Remote access because vscode uses a daemon but emacs uses
| scp for tramp.
| mardifoufs wrote:
| Remote access has been way faster on vscode for me. I'm
| not sure what the daemon has to do with speed here, if
| anything it's one of the reason why remote SSH on vscode
| is so good.
| mdaniel wrote:
| Merely for consideration, ControlMaster gets one out of
| the business of establishing a fresh ssh session per
| ssh/scp operation:
| https://man.openbsd.org/ssh_config#ControlMaster (and its
| friends https://man.openbsd.org/ssh_config#ControlPersist
| & https://man.openbsd.org/ssh_config#ControlPath )
| iLemming wrote:
| > Emacs is actually rather slow.
|
| It depends on so many different things. Aside from platform
| specifics (sure, it can be painfully slow on Windows),
| Emacs might feel slow for various reasons, but it doesn't
| have to be. Built-in Profiling tools are godsend and if
| used properly Emacs can be quite impressively fast. My
| Emacs starts quickly (in less than a second), and it is
| very pleasantly snappy.
| parasti wrote:
| I switched from Emacs to VS Code some years ago after being a
| hardcore Emacs user for many years. For me it was
| customization fatigue. Just an endless accumulation of Emacs
| Lisp one liners and functions that I have no use for outside
| of Emacs. In comparison, I don't even know where my VS Code
| dotfiles are. I don't need it to be set up with my
| customizations, I just use it out of the box and add
| extensions when I need to.
| Lyngbakr wrote:
| I was an Emacs user for years, then discovered Helix. I tried
| it on a whim and it turns out that I really enjoyed a modal
| editor that requires minimal config. I'm not sure if it's due
| to my an age, but I no longer want to constantly tweak my setup
| and just want a solid out of the box experience.
| seanw444 wrote:
| Yeah if I'm on a machine that I isn't my primary system, and
| I don't want to spend forever configuring my whole setup, I
| use Helix or (Neo)vim.
| BeetleB wrote:
| > I wonder how many users Emacs has lost to VS Code over the
| past few years. I'm one of them.
|
| I think Emacs users care more about the total population than
| one particular outmigration.
|
| I don't have actual data, but if I compare to the amount of
| activity (blog posts, tweets/toots, packages, etc), then
| (heavy) Emacs usage seems to be monotonically increasing.
|
| Almost everyone I know who switched to VSCode was using Emacs
| primarily for work, and mostly limited to SW development. That
| category of users may be large in absolute numbers, but most of
| the Emacs ecosystem is not driven by that category (i.e. even
| if that category shrinks to a tenth of its size, it won't have
| any impact on Emacs development).
|
| Just take a look at the talks in the conference. The vast
| majority are orthogonal to SW development/programming.
| lawn wrote:
| I think your analysis applies to Neovim too.
| lysace wrote:
| Non-programmer usage of neovim outweighs programmer usage?
| opan wrote:
| I consider myself a non-programmer and use nvim daily on
| my PC for config editing, note-taking, anime playlist
| management, writing emails (inside aerc). Next time I try
| programming, I'll also use it for that I'm sure.
| lysace wrote:
| Are you saying that most emacs users aren't in "SW
| development/programming"? Of course not.
|
| Would someone not _very carefully_ reading your comment think
| otherwise? Yes, probably.
| yoyohello13 wrote:
| I'm continually surprised how many non-programmers or
| occasional programmers use emacs. Writers seem to love it.
| iLemming wrote:
| > Writers seem to love it.
|
| Of course, how can you not love it? All the tools you
| need for writing are at your fingertips. You can have a
| thesaurus, spellchecking, translation and search,
| dictionaries, etymology lookup, word counter, Flesch-
| Kincaid reading ease tester, ChatGPT, Anthropic and other
| models, dictation, formatter, converter, exporter and so
| much more. Why would anyone ever exposed to that power
| willingly part with it?
| kragen wrote:
| Which packages do you recommend for each of these things?
| I don't have most of them in my Emacs.
| iLemming wrote:
| You can simply 'M-x list-packages' and search for things.
|
| - Thesaurus - there are a few different packages,
| powerthesaurus, le-thesaurus, etc. I use mw-thesaurus, at
| this point mainly out of habit, it's the first Emacs
| package I ever made and it served me so well, I never had
| reasons to look for alternatives.
|
| - Spellchecking - I suppose flyspell still holds the
| majority, I prefer jinx.el, it completely replaced
| flyspell for me
|
| - translation - also multiple choices, from translate-
| mode, org-translate, ob-translate, lingva, immersive-
| translate, etc. I use google-translate - for no
| particular good reason, it's just an old habit.
|
| - search - consult-omni, it takes some initial tweaking,
| but then you can simultaneously search on Google,
| Wikipedia, YouTube, your browser history, etc., while
| typing the query once.
|
| - dictionaries - sdcv
|
| - etymology - define-it, wiktionary-bro
|
| - word counter - is built-in; reading ease testing -
| writegood.el
|
| - LLMs - multiple choices, gptel and chatgpt-shell are
| the most popular.
| kragen wrote:
| Thanks!
| BeetleB wrote:
| I'm saying that the bulk of the community that keeps it
| alive and growing are either not SW professionals, or are
| but their use of Emacs goes well beyond SW use. As such,
| even if they "switch" to a tool like VSCode, they'll still
| primarily use Emacs for most things (email, document
| authoring, TODOs, etc). And Emacs as a SW will continue to
| grow as a result.
|
| A significant portion of the Emacs "influencers" are not SW
| developers (think Protesilaos). Quite a few very popular
| Emacs packages are made by non-SW folks.
|
| Which, as I pointed out, is why most of the talks are not
| related to SW development. Because that's not why the power
| users use Emacs.
|
| In my (large) company, the bulk of Emacs users I've met use
| it for SW development, and little else. As such, while they
| may be really good users for the SW development they do,
| they tend to be fairly ignorant about the rest of Emacs
| (not heard of org mode or magit, some even think XEmacs is
| the improved Emacs, etc). Globally, such folks may well be
| in the majority, and if the bulk of them stop using Emacs,
| no one would even notice.
|
| In fact, as someone who's been using Emacs since before
| VSCode existed, I simply did not notice the (real) exodus
| to VSCode. If you follow only the Emacs ecosystem (Emacs
| reddit, blogs, social media), the online engagement has
| exploded in the last 15 years. You would never guess that
| Emacs may have lost users overall (if it did).
| SoftTalker wrote:
| Why would emacs users care what editor anyone else uses?
| Emacs seems like the sort of thing you use and develop for if
| it solves a problem for you. It's not a business; it doesn't
| need to win popularity contests.
| rtpg wrote:
| I think it's interesting to think about why people choose
| things. You can then decide "we want these qualities as
| well", or "we don't want those", or "we want them but
| haven't figured out how to get there without paying too
| high of a cost we want in other things".
|
| Not a goal in itself to capture everyone, of course. But
| it's a data point!
| iLemming wrote:
| "Data point" is simply this - Emacs and Vim have seen way
| too many popular editors and IDEs over the years and
| VSCode is just another thing in a long list of
| "contenders" - Brief, Wordstar, Borland Sprint/Turbo
| Pascal/varios 'Builders', QEdit, TextPad, Norton, Delphi,
| Adobe shit, Macromedia stuff, Microsoft crap, Eclipse,
| Netbeans, etc.
|
| Emacs proceeds strategically, not tactically. Even though
| it outlived so many different editors it was only a
| single decade, a point in history when it was considered
| kinda, sorta mainstream, the rest of its lifetime it
| wasn't.
|
| Emacs is just like Lisp itself - it never dies, and never
| gets to be hugely popular. Anyone wishing either speedy
| death or widespread popularity for Lisp (and Emacs) will
| likely remain disappointed. Those who value Lisp and
| Emacs will continue using them, even decades from now.
| Those who never learn to appreciate either - will keep
| ignoring them.
| rtpg wrote:
| I mean Lisp "never dies", but there have been plenty of
| Lisp flavors that have come and gone. We don't write
| Lisp, we write some flavor (each with vastly different
| properties and values).
|
| There's nothing wrong with looking at the ecosystem and
| saying "huh, this is a pretty good idea". Emacs (the
| community as a whole) didn't ignore the LSP, and thanks
| to that it gets first-class support for tools that
| otherwise would have required someone to show up and "do
| the work" to get it to happen.
|
| I do think we're in agreement about "strategically, not
| tactically". Like Emacs _is_ doing its own thing. It's
| just that sometimes you can see good ideas from other
| places.
| skydhash wrote:
| The thing is Emacs, just like Lisp, can incorporate all
| those neat ideas without drastically transforming itself.
| I don't know any strong features other editors have that
| users can't replicate unless powered by closed source
| code. It won't be as polished, but that mostly because
| users have different workflow.
| b1476 wrote:
| I've tried twice to make the move to VS Code and keep coming
| back to Emacs. I would often be overwhelmed by my obsession to
| tweak things (ADHD..) but switching to Doom Emacs and sticking
| to the standard config helped with that. Learning some Elisp to
| write custom functions and embracing org-mode has made it near
| impossible to switch to another editor now.
| kstrauser wrote:
| I was one of them but I went back. It's just soooo good, and VS
| Code sits in my uncanny valley of almost-but-not-quite native
| in a way that bugs me.
| ParetoOptimal wrote:
| I tried vscode, but couldn't picture leaving emacs for it.
| uludag wrote:
| The percentage of the pie is smaller, but the pie has grown so
| much larger that in absolute numbers, there may not be any
| decrease.
|
| > And also potentially shortsighted.
|
| Looking at the recent releases, it feels like the vscode
| enshittification has already begun...
| nickysielicki wrote:
| If vscode could replicate the fuzzy-search -> filter ->
| collect-to-buffer flows that I'm used to with emacs, I'd be
| right there with you.
|
| I don't think there's an argument to be made that we're at risk
| of losing something. So much of editor progress in the past
| ~years is shared -- treesitter, lsp backends, linters and
| snippets, etc. It's hard for me to imagine how the editor
| ecosystem could collapse.
| magical_spell wrote:
| Could you elaborate on those flows? Sounds useful. Is it
| vanilla Emacs?
| zkry wrote:
| I really enjoyed the conference this year! It had a good mix of
| project updates, emacs internals, configuration, Emacs rewrites
| in different languages, org-mode applications, community,
| interesting packages, and things that went over my head.
| amichail wrote:
| Do you think TeXmacs should be included in EmacsConf, even though
| it is based on neither Emacs nor TeX, but merely inspired by
| them?
| nxobject wrote:
| From an entirely armchair commentator, I think so - the
| exchange of ideas and enthusiasm among Emacs-likes can only
| benefit both projects and Lisp-based editors in general. (The
| reason I'm very armchair is because use LyX when I want to
| write technical documents, which does leave out one of
| TeXmacs's really important use cases.)
| Vekz wrote:
| I was really impressed with the online presentation of EmacsConf
| 2024. Everything captured and published in org-mode: Transcripts,
| Comments, QA, Video links. Was really nice to peruse.
| emptybits wrote:
| Wondering if the Lem project is "accepted" (or worth a test
| drive) by the Emacs community. I'm a long time Emacs user,
| occasionally leaving but always returning. Lately, Lem has my
| attention. https://github.com/lem-project/lem
|
| For those not familiar, Lem is very approximately an Emacs,
| natively written and extendable in Common Lisp, multiplatform,
| NCurses & SDL2, etc. LSP. And fast.
| stackghost wrote:
| Lem is really great. I hope it keeps gaining mind share because
| it's superior to emacs in a lot of key ways.
| sourcepluck wrote:
| What is better, from your experience?
|
| I'm a happy Emacs user, but think having more options is
| great, and I've delved into some Common Lisp and certainly am
| eager to learn more. So I'm thrilled to see Lem continue to
| be developed.
| stackghost wrote:
| Emacs is "better" only because it has more features at
| present, and is somewhat more mature.
|
| But emacs remains replete with bugs, the performance leaves
| a great deal to be desired, the UI locks up if you update
| your packages because the whole thing is single-threaded,
| and emacs lisp (the language) quite frankly sucks, a lot.
|
| Lem is not very mature and has a lot of sharp edges but
| already in this state I can see that it will eclipse emacs
| if it continues its current trajectory.
| iLemming wrote:
| Oh come on. Emacs is not that buggy. For a piece of
| software that's been developed for over forty years it's
| quite surprisingly stable. Most of the "bugs" I see are
| due to some tighter integration between different
| packages - someone upstream would change something that
| inadvertently breaks things somewhere else. It doesn't
| happen that often.
|
| Also, Elisp isn't really that bad. Well, sure, Common
| Lisp of course is a lot nicer language, and of course,
| not having any good concurrency story doesn't add any
| points, still, Elisp isn't so horrendous.
|
| That being said, I do really hope Lem would get traction,
| and people start building plugins for it. Alas,
| realistically I'm not sure how feasible that would be.
| Replicating anything like Org-mode, with tons of
| extensions may take many years. Lispers however are known
| for their tenacity and ingenuity, who knows, maybe it
| wouldn't take too long.
| downut wrote:
| I tried it out twice now but it doesn't support multiple
| frames. So it's a terminal only sorta thing? Or maybe
| Wayland? Whatever, it doesn't support multiple decade proven
| workflows. Totally ok, but not superior.
| tmtvl wrote:
| Lem is a nice try, but the default theme is utterly
| disgusting and because it wasn't designed with themes in mind
| going with a sane theme is impossible (because some colours
| are hardcoded so they become impossible to see on a proper
| light background). The lack of an Emacs-like configuration UI
| and Emacs-like documentation is also unfortunate.
| stragies wrote:
| Sounds nice, how is the ecosystem of plugins/extensions
| compared to Emacs? Are there Debian packaging plans?
| jhoechtl wrote:
| Latest release is of February. Has progress been made?
| emptybits wrote:
| I'm running that February release as my daily driver on MacOS
| happily. Haven't launched Emacs except by accident for a few
| weeks. I admit it's an experiment but so far so good.
|
| Lem always feels very responsive (threading or rendering
| architecture, I assume) and my meagre needs for Emacs
| keystrokes seem supported. One thing I'd love to see Lem
| support soon, though, is org-mode awareness.
| Vegenoid wrote:
| It is clear from the commit history that the project is
| active and work on it continues.
| djaouen wrote:
| I can't see myself leaving Emacs. _Maybe_ for LunarVim, in an
| extreme case. But otherwise, no.
| globular-toast wrote:
| Ah man, I'm gutted I didn't "attend" this. Been an Emacs user
| more than 15 years and people like Sacha were there at the
| beginning for me and a huge reason why I got into Emacs back
| then. I feel so lucky to have got into it back then. I see
| colleagues struggling with their tools which they can't fix or
| even tweak, but I can't imagine any of them putting in the time
| now to learn Emacs. It's truly the editor of a lifetime.
| imiric wrote:
| > It's truly the editor of a lifetime.
|
| This is the main reason I use it as well.
|
| Emacs is far from perfect. It's slow, lacks some of the bells
| and whistles of other editors, and can be downright frustrating
| to use at times.
|
| But damnit, it's _mine_. It has allowed me to create the
| perfect editing and programming experience _for me_, and no
| other environment gives me that freedom and enjoyment. Vim and
| friends come close, and I continue to use it as my secondary
| editor (and couldn't function without vim-mode), but Emacs
| allows much deeper customization and Lisp is so elegant for
| this.
|
| As editors come and go, it's comforting to know that Emacs will
| always be there for me. Warts and all. <3
| sourcepluck wrote:
| I loved browsing the emacsconf videos this year, really nicely
| presented, and such cool stuff happening. Still have lots to
| watch, but so far in particular the infrastructural and UI type
| stuff seemed amazing, there's loads happening! Favourites
| included:
|
| https://emacsconf.org/2024/talks/casual/ -- Charles Choi
| designing UIs for human beings rather than octopuses (this jibe
| is meant fondly, I am a happy octopus)
|
| https://emacsconf.org/2024/talks/literate/ -- Howard Abram,
| literate programming
|
| https://emacsconf.org/2024/talks/gypsum/ -- Emacs and emacs lisp
| clone in Guile
|
| https://emacsconf.org/2024/talks/rust/ -- Rune, an experimental
| Emacs core in Rust
|
| https://emacsconf.org/2024/talks/julia/ -- lovely talk about the
| synchronicity between Julia and Emacs
|
| https://emacsconf.org/2024/talks/guile/ -- Robin Templeton
| relaunches Guile-Emacs!
|
| https://emacsconf.org/2024/talks/mcclim/ -- eh, this talk
| accepted questions from lambdaMOO?
| iambvk wrote:
| > The total hosting cost for the conference was USD 42.92 + tax
| and the BBB testing in the lead-up to the conference was USD 3.11
| + tax, so a total of USD 46.03+tax. The web node and the
| livestreaming node are kept as 1GB nanodes the rest of the year
| (USD 5 x 2 servers + tax, so USD 110). Very manageable.
|
| How does this compared to all other conf costs?
| mark_l_watson wrote:
| I have followed Sacha for a long while, love her frequent Emacs
| updates. I am a rabid Common Lisp enthusiast, and I bought the
| Mastering Emacs book last year, I just need to pull the trigger
| and try doing a project in Emacs Lisp.
| tiberious726 wrote:
| Common lisp -> elisp is an incredibly frustration transition.
| Get ready to really think in terms of dynamic scoping.
|
| I did it the other way, and going back to elisp is /hard/.
| beanjuiceII wrote:
| Sacha is awesome!!!
| eigenspace wrote:
| I was hoping to see something about EAF[1] this year, as I think
| the big thing emacs is still missing is a good way to drive
| interactive graphics, but EAF is still super janky and
| underdocumented.
|
| It'd be good to see this (or something better!) make progress.
|
| [1]: https://github.com/emacs-eaf/emacs-application-framework
___________________________________________________________________
(page generated 2024-12-29 23:01 UTC)