[HN Gopher] The Emacsen family, the design of an Emacs and the i...
___________________________________________________________________
The Emacsen family, the design of an Emacs and the importance of
Lisp (2023)
Author : oumua_don17
Score : 124 points
Date : 2024-02-16 15:02 UTC (7 hours ago)
(HTM) web link (emacsconf.org)
(TXT) w3m dump (emacsconf.org)
| heinrichhartman wrote:
| Direct Link to "Lem" the Common Lisp based "Emacs" discussed in
| the talk.
|
| https://lem-project.github.io/ https://github.com/lem-project/lem
| globular-toast wrote:
| Sadly not licensed under the GPL.
| kyykky wrote:
| Is there a benefit in using GPL for text editors?
| kleiba wrote:
| Only the same benefit as for any software.
| lupusreal wrote:
| It prevents the editor from (legally) becoming proprietary
| software which deprives users of their software freedoms.
| Jtsummers wrote:
| I suspect that if someone is in a position where they are
| compelled to purchase and use the proprietary version and
| not the free (and available) version, they already lack
| most software freedoms. Probably several other, more
| important, freedoms as well.
| globular-toast wrote:
| Licences like MIT optimise individual freedom: they give
| each user the freedom to do anything _including restricting
| the freedom of others_.
|
| Licences like GPL optimise community freedom: they give
| each user the freedom to do anything _except restricting
| the freedom of others_.
|
| Think of it like local vs global optimisation.
| GrumpySloth wrote:
| MIT doesn't give anyone the ability to restrict the
| freedom of others. When you fork a project and use a
| difference licence for it, the original project remains
| under MIT.
| GrumpySloth wrote:
| I can understand wanting to restrict use of something a
| person created using a restrictive licence. I can't
| understand being sad about someone else not restricting what
| they created. To me it looks like someone being sad after
| seeing someone else giving out free ice cream, even though
| the person being sad didn't contribute to making the ice
| cream.
| samatman wrote:
| I call these personality types free software socialists,
| and free software communists. The free software socialists
| are my friends. The free software communists are not.
| stolen_biscuit wrote:
| Calling the GPL a restrictive license is a bit like saying
| you can't cut down the trees in a public park and sell the
| wood is restrictive.
| GrumpySloth wrote:
| That analogy would make sense only if cutting trees left
| the trees intact and didn't annoy people in the park with
| noise etc. Alas, it's nonsense.
| tshirttime wrote:
| For those confused by the dangling modifier, he means the
| combined act of cutting the trees and selling the wood is
| restrictive. Also, a terrible analogy since trees are an
| exhaustible resource within a meaningful time range.
| globular-toast wrote:
| GPL is more free than MIT, not less. I would never make
| significant contributions to a non-GPL project.
| tmtvl wrote:
| My view on the GPL is that it's freedom-preserving, like
| how a law forbidding the enslavement of people is freedom-
| preserving, even though it technically restricts a freedom.
| That's why I look more favourably on GPL software than
| software with a so-called 'permissive' license.
| GrumpySloth wrote:
| This and similar arguments in this thread work on the
| same logic that frames software piracy as theft. It's the
| fallacy of treating software as a tangible thing that,
| when copied, is taken away from someone and altered
| irreversibly.
| tshirttime wrote:
| _I can 't understand being sad about someone not
| restricting what they created_
|
| I can. The guy giving away the ice cream is destroying the
| market. You can't compete against free. If programmers
| would stop surrendering their labor, personal data
| resellers like Google and Facebook wouldn't be our primary
| means of making a comfortable living. Say what you will
| about Microsoft's monopoly in the 90s. At least they took
| your money with your eyes open.
|
| The irony of course is free software zealots are pissed at
| the free ice cream guy for completely different, and I
| agree with you, utterly stupid reasons.
| GrumpySloth wrote:
| Yeah. I can get this angle. This is why we don't have
| small independent companies making C and C++ compilers
| today. Only BigCorps which fund this development with
| money made from less honourable business.
| whartung wrote:
| Is this based on Hemlock, or was it written from scratch?
|
| I really, really want a graphical emacs. By that I mean, I want
| an emacs with graphics, not an emacs in windows. I want to
| easily be able to draw stuff.
|
| I ran into this the other day, I like to dabble in emacs, and I
| had a list of results I wanted to make a quick chart. I ended
| up dumping it out in a simple CSV, and copy/pasting that into a
| spreadsheet, and hitting "chart".
|
| Would have been nice to go (line-chart my-list) and have a
| window pop up with reasonable defaults. And be able to print it
| to a PDF.
|
| emacs has some SVG support, but I guess its maintainer whim
| whether you get it or not, I wasn't able to easily get it
| working on my Mac. That could be a start. But something "nicer"
| would be, you know, "nice".
| strken wrote:
| image-mode can render real images, so there should be a way
| to embed charts of some kind.
| account-5 wrote:
| Completely off topic but this website is how it should be done.
| No JavaScript enabled and I can play the videos and see the text
| and images. Well done.
| moi2388 wrote:
| Well I can't play any of the media, perhaps JavaScript isn't
| that bad?
| ThinkBeat wrote:
| That is odd. It works on Edge and Firefox for me. They also
| give you the links to download each one to play it local.
| jocaal wrote:
| I use chromium on linux without proprietary codecs. There
| have been many times where videos didn't play for me, but
| these all worked.
| lupusreal wrote:
| Sounds like a Safari/Apple issue, not a lack-of-javascript
| issue.
| GrumpySloth wrote:
| Yup. I've downloaded the Webm file and iOS doesn't know
| what to do with it, which is odd, since Apple allegedly
| added support for Webm in iOS 15. I'm on iOS 17.
| cesarb wrote:
| > which is odd, since Apple allegedly added support for
| Webm in iOS 15. I'm on iOS 17.
|
| Which video codec? Originally webm could contain only
| VP8, but nowadays it can also contain VP9 and AV1. It's
| possible that Apple only implemented VP8
| (https://caniuse.com/webm implies that it has implemented
| VP8 and VP9 but has VP9 disabled by default); if this
| video uses a newer codec, it won't work.
| GrumpySloth wrote:
| Yeah. It uses VP9.
| digging wrote:
| For sure, I'm on Orion browser (Safari clone) and it's not
| playing even with JS enabled.
| DonaldFisk wrote:
| I don't know the reason in your case, but for a few weeks
| ending today, I wouldn't have been able to either, due to a
| long-standing issue with Opera and libffmpeg.so. Today Opera
| updated itself and everything now works fine, at least until
| the problem recurs. Maybe you have a similar problem?
| agumonkey wrote:
| fosdem and emacsconf were very lean in many aspects, website,
| video streaming.. and even Q&A (bigbluebutton?) they made a
| beautiful setup
| alwayslikethis wrote:
| Ah, a grand achievement. Looking good without using any of the
| fancy stuff people use nowadays and doesn't feel slow.
| rs_rs_rs_rs_rs wrote:
| Just don't read it on a mobile device.
| account-5 wrote:
| Firefox on android for me.
| serial_dev wrote:
| The only thing missing is CSS that works (layout was messed up
| on my phone).
| nanna wrote:
| Sacha Chua does God's work for the Emacs community with
| building the Emacsconf infrastructure and her Emacs newsletter.
| See her blog on how she set up auto captioning:
|
| https://sachachua.com/blog/2024/01/2024-01-28-yay-emacs-clos...
| federicotdn wrote:
| Two projects that may be of interest, related to this topic:
|
| - Rune (https://github.com/CeleritasCelery/rune) - A re-
| implementation of Emacs but in Rust (like Remacs, but actively
| developed)
|
| - Pimacs (https://github.com/federicotdn/pimacs) - Same, but
| using Go (created by me, but developed in a very slow pace)
| rurban wrote:
| Rune, the language, came before. So we have now 2 rune
| projects, the language and the emacs vm
| jdougan wrote:
| And Runestone, the open source editor framework for iOS [1].
| It is also a text edotor on the app store that uses the
| framework.
|
| [1] https://github.com/simonbs/Runestone
| wglb wrote:
| Ok, as a long-time emacs user (I think I started in 1985), I am
| officially nerdsniped.
|
| Building the sdl2 version, there is no luck finding libSDL2_ttf,
| so I'll be trying the ncurses version.
|
| Looks pretty snappy so far.
| taeric wrote:
| Same. The live demo at the end was very effective at spiking
| more interest, as well.
| kleiba wrote:
| Really? I find that the one really good design decision that
| survived in GNU emacs over all these years is that it does
| not have dialog windows. But it seems that that's pretty much
| what Lem does, at least when you find a file?!
| taeric wrote:
| I'm assuming that is something you could get rid of, if you
| want. It was more the popping over to the repl of the
| editor that I found fun to watch. And the fact that it was
| working.
| whacked_new wrote:
| For anyone running nix/nixos, looks like there isn't a nix-shell-
| able package but `nix run github:dariof4/lem-flake` starts the
| ncurses version
| Dariof4 wrote:
| The flake is unfortunately stuck on an old version (v2.0.0),
| since they changed how it's built with v2.1.0 and I haven't
| gotten around to fixing the flake, I'll try to see if I can get
| an update for it soon.
| dleslie wrote:
| It's weird to be building an Emacs clone nowadays. It's fairly
| clear that Vim and Emacs _both_ lost the editor wars, and VSCode
| has come out on top. That's not to say either Vim or Emacs are
| dead or will disappear, but building a clone of a niche editor is
| risking dooming the project to being a niche within a niche.
|
| If it's just because hacking is fun, then by all means have a
| blast. But if the goal is to compete with Emacs, consider instead
| setting the target at something with far greater popularity than
| Emacs.
| LukeShu wrote:
| I'm pretty sure I read this exact comment 10 years ago, but
| "Sublime Text" instead of "VSCode".
| tom_ wrote:
| And Atom, as well.
| tom_ wrote:
| I suppose TextMate was a bit more niche, being OS X only,
| but at one point it seemed to be _everywhere_.
| tom_ wrote:
| Hmm, while we're counting, what about BRIEF? At one
| point, widely enough used that Visual Studio even had
| BRIEF emulation!
|
| (When I was starting out in software development, almost
| _all_ of my colleagues used this. Now just a footnote.)
| ericvsmith wrote:
| BRIEF by UnderWare! I loved that editor. I particularly
| liked the "go to this line number, but use the line
| number before unsaved edits". This let you compile a
| file, get the error log, then start making edits; but the
| line numbers in the error log were still useful.
|
| https://en.wikipedia.org/wiki/Brief_(text_editor)
| dleslie wrote:
| VSCode is why Sublime Text, Atom, and others are not as
| relevant as they once were.
| BeetleB wrote:
| And in 10 years, there will be a comment saying "XYZ is why
| VSCode is not as relevant as it once was."
|
| And Emacs will still be around.
| idispatch wrote:
| And VSCode will still be around.
| BeetleB wrote:
| Just as Sublime Text is still around :-)
| nequo wrote:
| Atom is not around. Not 100 percent sure that VSCode will
| be around. (But I also don't think that this should hold
| anyone back who finds VSCode to fit their needs best.
| There'll be something else that will take its place.)
| omaranto wrote:
| My impression is that all of those are fads, we jsut
| haven't seen VS Code fade way yet, like the others have.
| I've used Emacs throughout all of those fads, seems easier
| than switching editors every few years.
| heinrichhartman wrote:
| > lost the editor wars
|
| What does that even mean? Both editors have large&strong
| communities. I don't see them going anywhere.
| iainctduncan wrote:
| If someone is interested in lisp, you can assume they aren't
| driven by mass market popularity. Why on earth would want to go
| up against MS on their turf???
| thomastjeffery wrote:
| Diversity of interest does not equate to intensity of interest.
| uludag wrote:
| Software definitely doesn't have to be popular to be useful.
| Not being extremely popular comes with advantages as well.
| Nevertheless, Emacs is probably more popular than a lot
| software shared on Hacker News.
| Pr0ject217 wrote:
| Speaking from personal experience, I moved from VSCode to Doom
| Emacs a year ago, and the on-ramp wasn't nearly long or as
| tough as I thought. The defaults are good, and anything else
| that I customized I actually just used ChatGPT/GPT-4 to
| generate it. It took about a month to get used to the new
| setup. With LSP/Magit, it feels like I'm not missing out on
| much from what VSCode offered, and then whenever I want to
| personalize it, I can. For a creative person (which I'd argue
| most developers are, kind of by definition), it's fun.
| dleslie wrote:
| I've been using Emacs for roughly three decades; it's my
| favourite editor. And for sure, LSP has been an absolute game
| changer.
|
| Worth noting is that LSP came from Microsoft as part of their
| efforts to build a better editor experience; and its
| integration with VSCode is largely unparalleled.
|
| For example: in VSCode the user doesn't have to understand
| how to install a language server, it just automagically
| suggests allowing it to install one for you. In Emacs, if
| you're using the official distribution you will have eglot,
| whose developers specifically refuse to add that
| functionality. If you're savvy enough you can install lsp-
| mode and it will add that functionality, but at that point
| you may as well just install the language server yourself.
|
| And about magit: it's a beautiful piece of software, it truly
| is. It's also hot garbage with large repositories hosted on
| Windows. I simply cannot use it for work because every
| operation takes around a minute to resolve, which locks up
| Emacs entirely. Again, here VSCode shines because the default
| git integration is pretty good, and there are extensions that
| make it excellent.
|
| For these reasons, and more, I always recommend VSCode to new
| developers and don't recommend Emacs. Emacs is for people who
| want to make editor customization a _hobby_.
| chlorion wrote:
| >For example: in VSCode the user doesn't have to understand
| how to install a language server, it just automagically
| suggests allowing it to install one for you. In Emacs, if
| you're using the official distribution you will have eglot,
| whose developers specifically refuse to add that
| functionality.
|
| I can understand this not being friendly for some users,
| but on most systems that people are using Emacs on,
| software is installed through a system package manager and
| not downloaded and unpacked into ${HOME}. I do _not_ want
| software that isn 't the system package manager to install
| LSP servers.
|
| Maybe this is more of an issue for people using Emacs on
| Windows, since there is no system package manager, and
| people are less likely to understand how to install stuff.
| kagevf wrote:
| > Emacs is for people who want to make editor customization
| a _hobby_.
|
| I disagree. I use it for org mode to take notes, track
| time, and write documentation. I use it with SLIME to
| program in Common Lisp (side projects, though). I make
| changes to .emacs or write an elisp function once in a
| while, usually to finesse something that I do frequently,
| but it's definitely not a hobby. It's a great tool, even
| before any customizations, IMO.
| cmrdporcupine wrote:
| "savvy enough" for emacs these days for lsp is literally
| "M-x package-install lsp-mode"
|
| Earlier today I started up emacs in a C++ project after
| working exclusively in Rust, and I didn't have an lsp
| server for C++ installed. I did M-x lsp-mode and it
| prompted me (paraphrased): No language server for C++
| installed, do you want me to go get one for you? Options
| are: clangd. Sure, said I, and it just went and installed
| it and off I went.
|
| Granted, you'll also need company-mode and stuff, yes. And
| to get an IDE like experience... treemacs, projectile, etc.
| etc.
|
| Yes, it's an acquired taste. But it's not like it's
| obsolete. It's better and more active than it's ever been.
| And I've been using Emacs (mostly casually) since 1992.
| dleslie wrote:
| First you have to know that lsp-mode exists. VSCode just
| detects what to do from the file.
|
| About projectile: Emacs ships with project.el and that
| does 90% of what projectile can do.
| cmrdporcupine wrote:
| I'm sorry maybe this has improved in the two years since
| I tried but the last time I tried to set up VSCode to
| even approach the capabilities of CLion (the tool I used
| most at the time) it required a whole bunch of
| configuration, and stuff that felt more brittle and
| confusing than the emacs setup I have now.
|
| In particular, no, it did not do all the LSP stuff out of
| the box, and didn't do basic refactorings out of the box
| either. Maybe it does so for other languages? Or maybe
| they've fixed the UX? But I recall having to install at
| least two or three plugins. And along the way found some
| that fought with each other.
| BeetleB wrote:
| > It's fairly clear that Vim and Emacs _both_ lost the editor
| wars, and VSCode has come out on top.
|
| Many (most?) Emacs enthusiasts don't use it primarily for SW
| development. VSCode simply isn't an alternative for their
| needs.
|
| Make two lists:
|
| - List of things you can do in VSCode that you can't in Emacs
|
| - List of things you can do in Emacs that you can't in VSCode
|
| The latter list will be 10-100x longer.
| digging wrote:
| Since I only use VSCode (or Codium...), what sorts of things
| would be in the latter list?
| BeetleB wrote:
| Can I use VSCode to:
|
| - Read and reply to my emails?
|
| - Manage TODOs across domains (so e.g. I can make a TODO
| that has a link to a specific email)?
|
| - Use it as a Mastodon client (read and write toots, boost
| them, favorite them, etc)
|
| - Scrape a web site (several pages), getting only the
| relevant content[1]
|
| - Bulk rename/copy lots of files with a custom naming
| algorithm
|
| - Chat on IRC
|
| - Use it as a spreadsheet
|
| - Do numerical integration with it
|
| - Have a literate document with code in several languages
| that talk to one another
|
| - Annotate PDFs
|
| This is a tiny list. In fact, you can browse past Emacsconf
| talks to see how people use it.
|
| [1] https://blog.nawaz.org/posts/2023/Mar/solving-a-
| scraping-pro...
| cmrdporcupine wrote:
| TIL about mastodon.el and now I'm off to MELPA that hot
| stuff.
| samatman wrote:
| I think it's fair to say that most people don't need, or
| even want, their IDE/text editor to do a bunch of stuff
| that can be done with other programs. I know Emacs people
| like it (I was, at one time, an Emacs person), and that's
| great, but "can your text editor/IDE do a bunch of not-
| text-editor-slash-IDE stuff?" is a weird gotcha.
| Sometimes you want to buy your dessert topping and floor
| wax in separate cans, y'know?
| tshirttime wrote:
| Emacs is the can class, not two can instances. The power
| comes from a single can interface, and leveraging one's
| can-fu across multiple tasks. Also, everyone enjoys some
| foot cheese in their whipped cream.
| BeetleB wrote:
| Most people don't need or want all the UNIX tools'
| capabilities. Does it make sense to compare the Windows
| command environment with the Linux one and say "Don't
| include all these capabilities in the analysis?"
|
| > but "can your text editor/IDE do a bunch of not-text-
| editor-slash-IDE stuff?" is a weird gotcha.
|
| It's not a weird gotcha when dismissing the tool. If you
| want to artificially narrow the comparison to "writing
| SW" (which is even narrower than text editing), then by
| all means - VSCode is the superior tool. But why stop
| there? The bulk of PC/laptop users use Notepad as their
| editor, and have no use for VSCode's capabilities. Shall
| we dismiss all the cool things in VSCode for it?
|
| And sorry, what? Non-editor stuff? About half the items I
| listed are editor related.
|
| > Sometimes you want to buy your dessert topping and
| floor wax in separate cans, y'know?
|
| True, but wouldn't it be at least nice if you could buy
| both cans from the same store, using the same currency?
|
| No one's arguing using only one tool. As I write this, I
| have both VSCode and Emacs windows open. Use the tool for
| its strengths. But blanket comparing VSCode with Emacs is
| silly - it's like comparing Excel with all of Linux. One
| is an application. The other is a platform. Excel is
| easily the best spreadsheet out there, but for many
| people, Linux is much more useful than Excel.
| samatman wrote:
| > _It 's not a weird gotcha when dismissing the tool. If
| you want to artificially narrow the comparison to
| "writing SW" (which is even narrower than text editing),
| then by all means - VSCode is the superior tool. But why
| stop there?_
|
| One, I wouldn't have conceded the crown to VSCode so
| easily as that. A fine-tuned Emacs config, with the
| requisite muscle memory and custom elisp, is a hot rod. I
| do use VSCode, and before that Sublime, but it was under
| protest, the details don't matter here but there were
| features I needed and no task budget for provisioning
| them in Emacs.
|
| Second, why _not_ stop there? I have a program for
| reading my email, it isn 't VSCode, I'm fine with that.
| So telling me Emacs can read email is completely
| irrelevant to my use of VSCode. For most people, adding
| all of these features to the Emacs side of the balance
| backfires, because now Emacs has to be better than all
| the tools they use for that stuff, rather than just
| better at what VSCode does than VSCode is.
|
| "Emacs does everything" is an aesthetic, and it has many
| decades of refinement, and people like it. That's fine.
|
| > _Most people don 't need or want all the UNIX tools'
| capabilities. Does it make sense to compare the Windows
| command environment with the Linux one and say "Don't
| include all these capabilities in the analysis?"_
|
| This isn't at all what you're doing. It's more like if
| someone says "awk is fine for text munging, why would I
| use Perl" and your answer was that Perl has a web server.
|
| There's such a thing as a like-for-like comparison. Emacs
| has org-mode, it has SLIME, it has paredit and parinfer.
| Those are all edges over VSCode, whereas checking email
| isn't. This conversation piqued my curiousity, and
| indeed, there's a plugin for that[0], a few actually, and
| yes, I'm sure Emacs does a better job, for some value of
| better. But I'll never know, because I don't intend to
| use either tool for that job.
|
| [0]: https://github.com/buhe/vscode-mail
| cmrdporcupine wrote:
| The reason some people, including myself, like to do
| things like email or irc or whatever inside emacs is
| because we got hooked on the powerful text and buffer
| management facilities in emacs, and want them everywhere,
| and consistently.
|
| All these things we're talking include editors in their
| separate applications. They just use the default OS
| editor widget using CUA bindings or whatever. Pulling
| them into emacs turns that on its head, and brings with
| it all the power (and weirdness) that comes with that.
|
| It's not for everyone, but it's also not something that
| it's fair to make fun of or dismiss outright.
|
| In the end, what the emacs nerds are doing is remaking
| the world of Lisp machines, but compromised and/or
| modified for the environments we have now. Not everyone
| digs that. I kind of do.
| samatman wrote:
| > _not something that it 's fair to make fun of or
| dismiss outright_
|
| I took pains not to do that in either post I made.
| lispm wrote:
| Just that something is largely written in Lisp, doesn't
| make it a "Lisp Machine", nor a clone of it.
|
| > but compromised and/or modified for the environments we
| have now.
|
| I would think that GNU Emacs is also compromised by its
| own design decisions, starting in 1984, when RMS rewrote
| Gosling Emacs.
| BeetleB wrote:
| > Second, why not stop there? I have a program for
| reading my email, it isn't VSCode, I'm fine with that. So
| telling me Emacs can read email is completely irrelevant
| to my use of VSCode.
|
| I agree it is irrelevant to your use of VSCode. The
| comparison, though, was for VSCode with Emacs. Not
| "VSCode with Emacs for samatman's needs".
|
| > For most people, adding all of these features to the
| Emacs side of the balance backfires, because now Emacs
| has to be better than all the tools they use for that
| stuff, rather than just better at what VSCode does than
| VSCode is.
|
| It's illogical to say that Emacs has to be better than
| all those tools to use them. We're not enforcing a
| dichotomy. You can use both. You can use Gmail's web
| interface _and_ Emacs mailing abilities. All you need is
| for one to have _some_ capability that the other doesn
| 't, as opposed to having _every_ capability the other
| has.
|
| Next: A large part of my point in this thread is that
| comparing VSCode to Emacs as a whole is in itself silly -
| one is a fairly specialized tool and the other is fairly
| generic. If you want to reduce the discussion to SW
| development, then fine. But people (not you) blanket
| saying VSCode is better (or worse) than Emacs is like
| saying Excel is better than Linux. I don't have any
| desire to convince someone to leave VSCode for Emacs.
| What for?
|
| Next: Implicit in your comments is the notion that stuff
| like reading mails is an "extra" in Emacs. It's
| artificially categorizing. Reading email in Emacs is not
| an addon - it's part of Emacs's capabilities (although
| you may get better experiences than the default with
| addons). If reading/writing emails is considered
| "extras", then keep in mind so are things like syntax
| highlighting, debugging, compiling, etc. Emacs is a text
| editor, and all those features are addons - at the same
| level as reading mails.
|
| As a VSCode user, some of these addons mean more to you,
| and you don't care about the others, but understand that
| lots of people do care about them. So many people out
| there use Emacs only for org mode and magit.
|
| > This isn't at all what you're doing. It's more like if
| someone says "awk is fine for text munging, why would I
| use Perl" and your answer was that Perl has a web server.
|
| Context matters. Understand that my list was in response
| to "What can Emacs do that VS Code can't?" If someone
| asked "What can Perl do that awk can't?" then mentioning
| CPAN and Web servers is totally appropriate. It's
| pointing out that if you learn Perl, it may benefit you
| far more than awk ever could. Whether it would or not
| depends on your goals, of course.
|
| > There's such a thing as a like-for-like comparison.
|
| Agreed, but it helps if the scope is stated clearly. More
| often it's "Why do you use Emacs when VSCode exists?" And
| then of course, I'll list all the things I do in Emacs
| that VSCode doesn't provide. If someone asks "Why do you
| shop at Walmart when you can shop at Whole Foods?" it's
| not a problem to respond with "Because I can buy
| electronics at Walmart." You wouldn't jump on him and say
| "Hey, you're not doing a like-for-like comparison!"
| cyrialize wrote:
| Apologies if this is do-able in VSCode, but for me the
| killer feature of Emacs is that configuration is literally
| just running code.
|
| In VSCode, I don't think there's anything like "place code
| in this file, run it at startup, and code within this file
| can be present/applicable everywhere". Maybe you could do
| something as a plugin, but that is a big lift compared to
| Emacs.
|
| For example, think about doing a "Hello World".
|
| In Emacs, you just open init.el and place `(message "Hello
| World!")`.
|
| In VSCode, you have to follow a whole set up for an
| extension [0].
|
| [0]: https://code.visualstudio.com/api/get-started/your-
| first-ext...
| logicprog wrote:
| Check out org mode (very complex and advanced task
| management / todo list system, calendar, etc), org roam
| (basically all the features of Obsidian), the ability to
| act as an email client, having a cross platform system
| shell independent shell (in elisp), and of course just
| general emacs architecture things like the ability to hot
| reload and replace and debug and inspect and get docs on
| and add to and modify every part of the editor
| Jtsummers wrote:
| I don't think there's anything that's technically not-
| doable in VS Code that emacs can do. For me, it's more
| about _ease_ of use that differentiates the two.
| Specifically around extensions.
|
| https://code.visualstudio.com/api/get-started/your-first-
| ext...
|
| That's the VS Code description on how to start writing
| extensions to VS Code. The first steps involve installing
| node.js so you can install another tool so you can generate
| scaffolding.
|
| In emacs it would be:
|
| Step 1: Open emacs
|
| Step 2: Open a scratch buffer (q&d extensions, put in a .el
| file if you want to preserve it)
|
| Step 3: Write some lisp code
|
| Step 4: Evaluate the lisp code
|
| Step 5: There is no step 5, use your extension
|
| Caveats:
|
| You have to learn programming to extend either of them so
| that's a common burden.
|
| You have to learn lisp to extend emacs, but that's an easy
| thing to do.
|
| You have to read the documentation to really get going with
| extension development, another common burden.
| cmrdporcupine wrote:
| _" The latter list will be 10-100x longer."_
|
| And on top of all that the actual core _editor_ is, once you
| get your fingers wrapped around it, just... the best. It can
| do so many things that other editors just don 't do, it's
| responsive and fast, the buffer metaphor it works with is
| great (so easy to have the same file open in multiple windows
| at different regions, it's beautiful) and I love the tiling
| system for its frames, etc. etc.
|
| In 30 years, we'll still be using Emacs, but VSCode will have
| moved on.
| evanriley wrote:
| Why do anything if there is already someone doing it?
| f1shy wrote:
| This post MUST be pure irony. Big lol! Thanks for the fun.
| kazinator wrote:
| I need an editor that starts up, cache cold, in a few hundred
| milliseconds at most. Thanks for playing.
| cmrdporcupine wrote:
| To be fair, that's not emacs. I'm a huge emacs fan, but its
| startup is awful compared to vim & friends.
|
| Yes, you can use emacsclient, but that's a bit of a different
| thing and has its own disadvantages.
| serial_dev wrote:
| I, for example, am very happy that the Helix editor exists,
| which could be considered a clone of Vim (if you squint a
| little).
|
| I'm pretty sure the authors of NeoVim heard wise advice like
| yours, but I'm happy they continued.
| yashasolutions wrote:
| emacs and vim were niche way before VScode was around. The goal
| was never market dominance. It's not a market. It's a tool.
| With users. And these users are also active contributors to
| their own ecosystem.
| riddley wrote:
| It's so crazy to think the original emacs was a commercial
| product.
| widge wrote:
| The original emacs was a commercial product?
| lispm wrote:
| It wasn't.
|
| What he probably meant, that GNU Emacs (1984-...) was based
| on the code of another Emacs implementation, Gosling Emacs,
| which also had a commercial version.
|
| The original EMACS was developed at MIT, 1976, by Guy L.
| Steele Jr. and David Moon.
| DonaldFisk wrote:
| The original EMACS ran on ITS on PDP 10s in the MIT AI Lab. It
| definitely wasn't a commercial product.
| dctoedt wrote:
| In the mid-1980s there was a commercial Emacs workalike (on
| floppy disks) for the IBM PC, called The Final Word, later
| acquired by Borland and renamed Sprint. For printing, it
| featured a workalike of Scribe, an early text markup language
| and precursor to HTML by Brian Reid. In law school I'd used a
| TOPS-20 Emacs and Scribe for law-review work, so later I bought
| The Final Word and an early HP LaserJet printer to produce
| camera-ready copy for my first book. Good times (sort of).
|
| https://en.wikipedia.org/wiki/Sprint_(word_processor)
| shadowgovt wrote:
| I think I fell in love with emacs when I realized that individual
| key presses could be scripted. Or possibly when I wrapped my head
| around macro injection. Hard to say, this thing grew on me from
| being an absolute space alien of an architecture to the first
| tool in the toolbox I reach for if I've got a new project to
| tackle.
|
| My advice to people when editor wars come up is that going deep
| on something is more important than going deep on the right
| thing. emacs versus vi? No strong opinion. I happened to learn
| emacs first and would be repeating a lot of labor to go as deep
| on vi.
|
| (... But I do tend to give a slight nudge in the direction of
| something of that ilk because relative to say, VS code... Those
| editors have already stood the test of time, they aren't beholden
| to one owner, and while past performance is not proof of future
| expectations, there's a lot of people heavily invested in keeping
| both of them alive and thriving).
| dingnuts wrote:
| > I happened to learn emacs first and would be repeating a lot
| of labor to go as deep on vi.
|
| Speaking as someone who used vim for 10 years before getting
| sniped by Emacs (ten years ago.. shit I'm getting old):
|
| vim isn't as deep as Emacs, it's not even close. vim is only as
| deep as evil-mode. In fact, vim has a UX paradigm that's out-
| of-the-ordinary, and that's it.
|
| That's why in Emacs, modal editing is just another minor mode..
| PaulDavisThe1st wrote:
| Yes the day you find out that in GNU Emacs, the "u" key is
| actually bound to (self-insert-command) and thus can instead be
| made to do anything ... well,it's quite a day.
| EdwardCoffin wrote:
| I really wish that Deuce [1] [2] got more attention as a source
| for ideas for Emacs alternatives. It sounds incredibly cool.
|
| [1]
| https://web.archive.org/web/20221002093520/https://groups.go...
|
| [2]
| https://web.archive.org/web/20210407151341/https://discuss.a...
| cylinder714 wrote:
| Could you do a separate HN post for this, so it'll come up in
| searches?
| logicprog wrote:
| I like the idea of a more modern Emacs that uses the full power
| of Common Lisp a lot, but I worry I'd miss a lot of features.
| Does Lem have org mode, a good LSP system, something like
| projectile, and the ability to display images and GUI buttons and
| such? And most importantly, does it have an evil mode with
| doom/spacemacs style leader key support?
| cmrdporcupine wrote:
| It has LSP, but not the other things, really, from what I saw.
| You'd miss a lot. No idea about the modal editing, not my
| thing.
|
| Of course, it could be a foundation to build on, I dunno.
|
| EDIT: yes after watching the presentation, it has a modal/vi
| type mode
| phforms wrote:
| Take a look at the GitHub readme[1]: "Lem supports other
| programming languages thanks to its built-in LSP client. You
| can choose between an Emacs and a Vim mode.".
|
| Although I wish they'd explore the Kakoune/Helix style of
| editing too, which I think will become a major competitor to
| Vim (and I personally prefer it myself).
|
| However, I am also worried that Lem won't gain any traction
| because the Emacs ecosystem is just too vast and has too many
| killer apps (Magit, OrgMode, Dired, the amazing built-in
| Help/Documentation - to name a few).
|
| But it may very well become a modern Emacs alternative if they
| focus on better user experience, leave behind some
| idiosyncrasies of the past and create great alternatives or
| ports of Emacs's most appreciated plugins. There is a great
| opportunity in starting from scratch, but I guess it is also a
| huge challenge to compete against decades of development, a
| huge community and a rich ecosystem.
|
| [1]: https://github.com/lem-project/lem
| logicprog wrote:
| Thank you! I actually found my way to its website and then
| downloaded, compiled, and briefly tried it after I posted
| this comment and discovered things for myself. It looks like
| it doesn't support a leader key so that's a pretty big
| blocker to me using it for even basic editing, but you're
| correct the bigger reason I won't use it is because it
| doesn't have the truly incredible emacs ecosystem.
| cmrdporcupine wrote:
| Yes, I mean, I use all a lot of those things (haven't caught
| the org-mode bug tho, it's too incompatible with my
| attention-deficit...) but to be frank a lot of the stuff I
| jam into emacs (vertico, treemacs, projectile, all-the-icons
| etc) is in fact to get around UX issues with stock emacs.
|
| I'd hope that a fresh emacs from scratch would just ship with
| something close to what those provide.
|
| In the end my biggest beef with emacs these days is just the
| terrible lack of multithreading, bringing long pause and
| startup times. Most of my problems in the past have been
| rectified. Emacs 29 is really quite delightful and much
| easier to manage than ever before.
| cmrdporcupine wrote:
| I tried out Lem a couple times, and I was impressed, but couldn't
| see myself moving to it. What was impressive is how starting it
| up just.. worked... with LSP type stuff... I was editing Rust and
| that all functioned. Not as featureful as my Emacs setup, but
| further along than I expected. And the keybindings were mostly
| familiar.
|
| But so many of the things I now rely on -- company mode,
| treemacs, vertico, etc. are not there. The value in Emacs is the
| huge community of things.
|
| Also I had some instability each time I tried it -- buffers
| filling up with Common Lisp backtraces, etc.
|
| Still I really want to see some advancement in this arena,
| because the actual _implementation_ of GNU emacs leaves a lot to
| be desired in 2024. The packages overtop of it are nice, but the
| core editor blocks and pauses too much.
___________________________________________________________________
(page generated 2024-02-16 23:01 UTC)