[HN Gopher] Emacs-ng: A project to integrate Deno and WebRender ...
___________________________________________________________________
Emacs-ng: A project to integrate Deno and WebRender into Emacs
Author : kuba-orlik
Score : 101 points
Date : 2023-11-17 10:20 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| netzego wrote:
| probably one should start with implementing systemd in
| GNU/Emacs..
| stevekemp wrote:
| No need to be systemd, but emacs can already run as /sbin/init:
|
| https://news.ycombinator.com/item?id=8325308
| diffeomorphism wrote:
| > https://www.gnu.org/software/shepherd/
|
| > The GNU Shepherd is a service manager written in Guile that
| looks after the herd of daemons running on the system. It can
| be used as an "init" system (PID 1) and also by unprivileged
| users...
|
| Not systemd, but it is an init system.
| dmm wrote:
| > Webrender
|
| Would this allow emacs to be used as a web application?
| chrismorgan wrote:
| > _WebRender is a GPU-based 2D rendering engine written in Rust
| from Mozilla. Firefox, the research web browser Servo, and
| other GUI frameworks draw with it. emacs-ng use it as a new
| experimental graphic backend to leverage GPU hardware._
|
| No.
| rice7th wrote:
| No. Webreneder is a graphics renderer/library very similar to
| skia, however webrender is developed by mozilla, written in
| rust and used in firefox and servo. It basically gives emacs
| GPU acceleration since cairo doesn't have it IIRC.
| artsi0m wrote:
| >allow emacs to be used as a web application
|
| I think that it is already possible if you compiled emacs with
| gtk3/pgtk as toolkit of choice and use Broadway GDK backend.
| dmm wrote:
| I don't know how I missed this. You made my day! Thanks!
| rullopat wrote:
| Electron for Emacs?
| JNRowe wrote:
| This was discussed a couple of years ago with lots of comments1.
| I'm unsure how much has changed in the meantime, as the top
| couple of pages of commits on GH are upstream emacs changes.
| Would make me happy to see it progressing though, as(like with
| neovim) the tugs in different directions allows things to be
| tested out that might not make it past the original mail to a
| developer list in the upstream projects.
|
| _Edit_ : I decided to have a quick poke around, and there are
| ~40 non-upstream commits this year. About half of those are minor
| cleanups and cargo dependency updates.
|
| 1 https://news.ycombinator.com/item?id=26453174
| v3ss0n wrote:
| Emacs becoming an OS is not a meme anymore with this. Now EMacs
| becoming a Starship.
| sakesun wrote:
| Typescript with Web render engine ? Why not just build VSCode
| extensions ?
| letmeinhere wrote:
| Because they use Emacs? Let's say you are an org-mode user but
| write Typescript for your day job, and want to make a new
| plugin. This lets you do that with the language in which you
| are most proficient.
| rollcat wrote:
| The main advantage Emacs has over other, more modern IDEs is
| ELisp, and the vast ecosystem built around it. I don't see how
| supplementing ELisp with JS would make Emacs more attractive;
| most of Emacs' shortcomings originate elsewhere: single-threaded
| core, IO-blocks-UI, ELisp defaulting to dynamic scoping, bad
| defaults in general, poor OS/GUI integration, antiquated
| nomenclature, and just the sheer number of third-party packages
| and config tweaking that it takes to bring features that should
| work out of the box (sane dired, LSP, (ma)git, tabs, etc).
|
| Emacs desperately needs to deal with its tech debt, but adding a
| new language runtime without addressing the mountain of
| architectural issues is just circling around the problem, without
| actually even looking at it. Hats off for the effort but I'll
| pass.
| bvaldivielso wrote:
| > IO-blocks-UI
|
| This is one of the things that _are_ addressed by the project.
|
| Regarding your broader point, I don't know if adding a new
| language would/will help emacs or not but it's _plausible_
| something like that would work. The plugin ecosystem in the vim
| world became more vibrant once writing them in lua was an
| option.
| funcDropShadow wrote:
| > I don't know if adding a new language would/will help emacs
| or not but it's _plausible_ something like that would work.
|
| I don't think it is plausible. Emacs extensibility and power
| stems from the fact you can see and change almost everything.
| You can add advice, i.e. modify, any function there is. And
| you can inspect any object that exists in the heap. If you
| add another language into the mix, these two languages either
| have to share an object/data structure model or they have to
| bridge them somehow. In vim you have plugins that add new
| commands, or hook into some callbacks. But in emacs you can
| extend every third-party functionality with another third-
| party library. Fragmenting the ecosystem into two language
| camps would probably diminish this advantage.
| johanvts wrote:
| Agreed, but I think the defaults aren't that bad. It should not
| be an IDE or git UI out of the box IMO. What's needed is better
| default completion and discoverability.
| 0xpgm wrote:
| > tweaking that it takes to bring features that should work out
| of the box (sane dired, LSP, (ma)git, tabs, etc).
|
| For LSP (language server protocol), eglot worked out of the box
| quite well once installed. It ships by default in emacs in the
| latest versions.
| dleslie wrote:
| It's part of Emacs 29, so it's in Emacs out of the box now.
| darau1 wrote:
| I say this as a software developer using Emacs daily as my IDE:
| emacs is not an IDE -- at least not OOTB. It _can become_ a
| competent IDE, but that isn 't what it's built for. Instead, I
| think of Emacs as an overengineered elisp REPL.
|
| That said, I would love to see the issues you mentioned
| addressed, and would love to see how the EAF[1] does in the
| future.
|
| [1]: https://github.com/emacs-eaf
| otabdeveloper4 wrote:
| Emacs is just a text editor. And that's okay.
| PurpleRamen wrote:
| > The main advantage Emacs has over other, more modern IDEs is
| ELisp, and the vast ecosystem built around it.
|
| Ecosystem yes, and also it's architecture and culture. ELisp I
| would say no. If we ignore the specific flavor, then 99% of
| what's realistically done with with elisp, is also covered by
| other dynamic languages like JavaScript. And the rest is so
| esoteric that it's probably not that worth the trouble.
|
| > I don't see how supplementing ELisp with JS would make Emacs
| more attractive;
|
| Not everyone likes lisp, not everyone is willing to learn a new
| strange language for unknown benefits. And JS has a vast
| ecosystem of its own. Far bigger even that Emacs heritage, but
| on different areas. A well working combination of both, with no
| side making significant sacrifices, could be very alluring for
| many more people than Emacs has now.
| mtlmtlmtlmtl wrote:
| I think it's fine for Emacs to be Emacs. It's basically a
| museum piece from the Lisp Machine era at this point. There
| are so many choices already if you insist on javascript.
| Adding it to Emacs feels like the programmer's equivalent of
| putting a giant neon sign atop the Pyramid of Khufu; it just
| doesn't belong there.
|
| Emacs is unique and I'd like to preserve that.
| PurpleRamen wrote:
| A Museum is fancy storage for unused things. But Emacs is
| full of very useful and still usable parts, and a useful
| philosophy and prospering culture. What's wrong with
| spreading all this to other spaces, and letting other
| people learn about them, making them more accessible? Works
| well for (neo)vim. They have moved beyond lousy vim-key-
| implementations and today people are able to learn about
| modal editing and composable commands on a good level.
| mtlmtlmtlmtl wrote:
| Please don't misunderstand my use of the word "museum".
| I'm not saying Emacs is useless or that we should never
| improve or use it. But Emacs is more or less the only
| surviving relic of a very different paradigm of doing
| computing and software, one which many of us still
| cherish.
|
| >What's wrong with spreading all this to other spaces,
| and letting other people learn about them, making them
| more accessible?
|
| Because the philosophy of Emacs and the computing
| tradition it grew out of is fundamentally at odds with
| those other spaces. Everything being in one dynamic
| language is a huge and intrinsic part of that tradition.
|
| I suppose you could write an Emacs entirely in javascript
| if you wanted to, if you followed the same software
| philosophy. But personally I think Javascript is such an
| inelegant language that a lot of the power of the idea
| would be lost even in that case.
| PurpleRamen wrote:
| > But Emacs is more or less the only surviving relic of a
| very different paradigm of doing computing and software,
| one which many of us still cherish.
|
| I don't think that's true at all. Emacs is a lisp-
| machine, but that's just the means, an implementation-
| detail, not the culture and the aim. Every shell, web
| browsers, any REPL is pretty much the same as Emacs, just
| in a different flavor. The culture I'm talking about is
| to have a customizable tool & workspace. Something that
| adapts to you, a canvas where only your time and
| imagination is the limit. Limiting Emacs to being "just"
| lisp, is doing it a disservice.
| taeric wrote:
| Thinking that any REPL is the same as Emacs feels...
| wrong. Same for shells and other items there.
|
| I can almost see the argument for browser, but we left
| user customization as the default in browsers a long long
| time ago.
|
| To make my point a bit more concrete, the culture of
| lisp-machines was that the user was in full control.
| Curious what will happen if you type something? You can
| literally lookup what will happen on any keystroke or
| button press. Curious what code runs for a function? Odds
| are high that you can jump into the code for any feature
| and edit it on the fly. Yes, there are some native code
| sections that you can't do this for, but the vast
| majority is not that.
| mtlmtlmtlmtl wrote:
| No, you're not getting he gist here.
|
| Browsers are nothing like Emacs in design
| philosophy(except Nyxt, which gets close, but falls a bit
| short due to intrinsically having to deal with a bunch of
| JS; an excellent example of my point, come to think of
| it).
|
| Take Firefox for example. It has extensions, but they're
| intrinsically limited by the fact that they're sandboxed
| and can only interact with the browser through a limited
| API. And yes, you could certainly extend it arbitrarily
| by changing the C++/Rust/whatever code and recompiling
| it. But it's not designed to be extended that way by
| users.
|
| In emacs, the configuration is really just patches
| applied to the code at runtime. There fundamentally is
| nothing you can't do through the configuration.
|
| But why Lisp you say? Precisely because Lisp is a dynamic
| meta-programming language, which is _the_ ideal paradigm
| for this. It can be molded to be a highly abstracted
| configuration language without losing the ability to run
| arbitrary code. You get all the upside of JSON, YAML, XML
| and other configuration languages with none of the
| downside of being limited in what you can do.
|
| Adding javascript to the mix just complicates this simple
| and elegant model. You gain nothing in extensibility, and
| will probably lose quite a lot unless you take extreme
| effort to avoid it through clever design.
| PurpleRamen wrote:
| > Take Firefox for example. It has extensions, but
| they're intrinsically limited by the fact that they're
| sandboxed and can only interact with the browser through
| a limited API.
|
| That's design, a choice. It used to be different in old
| Firefox, and other browsers are different in that aspect
| even today. But to be fair, I mainly meant the page-
| context, not the application-context. Most normal web
| browser support userscript, bookmarklets and debugging
| some way or another. Or should I say, still. Because this
| is a bit in decline. And if you take something like web-
| or electron-apps, the page-context becomes the app
| itself. All just a matter of implementation and
| architecture.
|
| > There fundamentally is nothing you can't do through the
| configuration.
|
| You can't patch the C-core, can you? Another necessary
| implementation-detail.
|
| > Precisely because Lisp is a dynamic meta-programming
| language, which is the ideal paradigm for this.
|
| It was ideal when Emacs was created. Today, we have many
| alternatives.
|
| > You gain nothing in extensibility,
|
| Except more ability, more heritage, more users... At the
| end, it's all a matter of managing the tradeoffs, the
| implementation-details.
| samus wrote:
| > You can't patch the C-core, can you? Another necessary
| implementation-detail.
|
| The C core contains low-level things or performance-
| sensitive things that one really doesn't want to patch.
| Nevertheless, lots of things in the C core are
| configurable and extendable through hooks.
|
| > Except more ability, more heritage, more users... At
| the end, it's all a matter of managing the tradeoffs, the
| implementation-details.
|
| Regarding heritage, you can't get more than Enacs has,
| which was around when GUI didn't even exist yet.
|
| Users who are put off by the choice of configuration
| language are unlikely to be productive extension writers
| [edit: in any language].
| adamc wrote:
| Also, on a pragmatic level... I think an ecology built
| around scripting in multiple languages (because you have
| to support emacs lisp -- that's what things are written
| in now) will actually make it _more_ confusing to do
| future development, and now debugging /extending other
| people's packages requires competence with both languages
| -- potentially, anyhow. You end up fracturing the
| community.
|
| Something as simple as getting advice for solving a
| problem on web forums would also be affected by the
| dichotomy. I think that might be worse for newbies.
|
| Still, I think it's fine to run the experiment, and see
| if that is what people want.
| medo-bear wrote:
| I like the neon sign comment. Emacs is beautiful because it
| is raw simple and powerful. In architecture this is called
| brutalism. A lisp serves it well because it is in some
| sense the most brutalist high level language. JS on the
| other hand is anything but. In comparison to lisp it is Y2K
| worthless-trash wrote:
| What does "Y2K" mean in this context ? The 2000 AD ? I
| lived through it, it had its own share of shitty tech
| problems.
| medo-bear wrote:
| I was stuck for words. But 2000AD to me was a period of
| bloated superficial high tech, which is my view of js
| medo-bear wrote:
| > Not everyone likes lisp, not everyone is willing to learn a
| new strange language for unknown benefits.
|
| Im curious why someone would use emacs if they dislike lisp.
| To me its like writing SPAs without js
| PurpleRamen wrote:
| Humans are not binary. "Not liking" does not mean dislike.
| And Emacs is more than just lisp.
| miroljub wrote:
| > Im curious why someone would use emacs if they dislike
| lisp. To me its like writing SPAs without js
|
| Why use Windows (or MacOS, or Linux) if you don't like C?
| medo-bear wrote:
| None of those are meant to be customizable with C in the
| way Emacs is with elisp
| brlewis wrote:
| I'd prefer to write extensions to my IDE using TypeScript
| rather than elisp, but my attempt in 2018 or so to move
| from emacs to vscode failed, despite there being extensions
| that made keymappings largely compatible.
|
| Emacs has a much more focused UI than vscode. It's not
| obvious to me how to make all the extraneous things I'm not
| editing disappear.
|
| The emacs-compatible extensions as far as I've seen still
| haven't been able to make switching files in vscode as fast
| and convenient as switching in emacs. I spend more time
| maintaining software than writing new code in a single
| file, so this is a noticeable slowdown.
|
| VSCode doesn't feel as fast. I never fully investigated all
| the reasons. But I might make another attempt to move to it
| after it has a few more years to improve.
| EFreethought wrote:
| Not everyone likes JS. I am not a Lisp genius, but once you
| get the concept it's not that hard.
|
| If you want to use JS, there are plenty of places to do it.
| Some of us just want to avoid that dumpster fire.
|
| And if JS is so wonderful, why not make a JS editor from the
| ground up?
| avbanks wrote:
| I would much rather deal with Elisp than JS. IMO JS is a
| terrible choice for this.
| miroljub wrote:
| > Not everyone likes lisp, not everyone is willing to learn a
| new strange language for unknown benefits. And JS has a vast
| ecosystem of its own. Far bigger even that Emacs heritage,
| but on different areas.
|
| As much as I dislike elpa package manager, the mere thought
| of having to use npm or similar in Emacs makes me nervous
| already.
| e12e wrote:
| > If we ignore the specific flavor, then 99% of what's
| realistically done with with elisp, is also covered by other
| dynamic languages like JavaScript.
|
| Is that really true?
|
| https://github.com/search?q=repo%3Amagit%2Fmagit%20defmacro&.
| ..
| rollcat wrote:
| > Not everyone likes lisp [...]
|
| I think it's fair to say that if you don't like ELisp, Emacs
| might be the wrong choice for you. I'm not being elitist, I
| just think the two are glued together even closer than POSIX
| and C, and it would be extremely difficult to avoid it.
| kwhitefoot wrote:
| I haven't written any elisp in fifteen years yet I use
| Emacs every day even though I am retired and no long
| programming all the time.
| pjmlp wrote:
| Back in the day, I was mostly an XEmacs user as it did provide
| some niceties that Emacs lacked, including being closer to the
| Windows based IDEs.
|
| Not sure how much of it has eventually become part of it, as I
| seldom use Emacs, even though 10 years of usage leave their
| mark on the brain. :)
|
| I see Emacs finally adopting Guile as a much better path going
| forward, than attempts like these.
| danShumway wrote:
| Genuine question, not trying to be snarky: isn't JS a great way
| to address most of those concerns that you list?
|
| Deno and WebRender have good integration with workers,
| webrender offers the option of providing better GUI integration
| (although it's not clear exactly how it will be leveraged),
| jumping to Javascript gets rid of dynamic scoping, and (in my
| experience, although mileage may very much vary) tends to
| handle IO-blocking better.
|
| The project's performance justifications it lists are:
|
| > Async I/O from Deno, WebWorkers, and WebAsm, gives you the
| tools to make Emacs a smoother and faster experience without
| having to install additional tools to launch as background
| processes or worry about shared library versions.
|
| I don't _disagree_ necessarily, in some ways adding another
| language instead of fixing the one that 's still going to be
| the dominant way most integration is handled is a very, for
| lack of a better word, temporary fix. If Lisp isn't good enough
| for an editor, then we'd all jump ship to VSCode or whatever.
| There is something hacky about saying, "we're not leveraging
| this language well, let's just add another."
|
| But even saying that, I do still (at least at first glance and
| without looking into it harder) see the appeal.
|
| Even dropping the JS entirely, WASM workers seem like a non-
| terrible way to get better worker support and to get rid of the
| IO-blocking-UI problem (which I agree is a problem, and might
| be one of my biggest criticisms of Emacs). Am I missing
| something?
| admax88qqq wrote:
| I honestly don't think IO-blocking-UI is such a big issue.
|
| And if you try to solve it using workers you introduce an
| annoying programming paradigm of async/await and IPC.
|
| Copying data over IPC can be slow, and having to set up IPC
| to share the data you need to run in a worker is also
| annoying.
|
| The great thing about the single threaded shared memory model
| of elisp is that it's a lot easier to code against. And yeah
| sometimes someone blocks the UI doing synchronous I/O, but
| that comes at the benefit of making it really easy for people
| to write addons that do all sorts of things.
|
| A lot of the I/O blocking UI problems could be alleviated by
| just moving to async I/O primitives without incurring the
| runtime and developer experience problems of a multi process
| architecture
| danShumway wrote:
| Hrm. I don't know if I agree with this or not. Your last
| sentence is 100% spot on. But at the same time, I've used
| Emacs as a window manager before, and the reason I stopped
| was because of IO blocking the UI. I could not handle
| having a process bug out and having it freeze my entire
| window manager, and it happened frequently.
|
| I don't want to dismiss the argument; maybe it's just that
| Emacs packages are bad at avoiding that behavior? But I'm
| not sure that async I/O primitives are _enough_ for a text
| editor, even though I would generally agree with you.
|
| On the subject of that last sentence:
|
| > A lot of the I/O blocking UI problems could be alleviated
| by just moving to async I/O primitives without incurring
| the runtime and developer experience problems of a multi
| process architecture
|
| This sounds like an advertisement for Javascript to me?
| This is one of the reasons I think why NodeJS became so
| popular when it was first introduced, literally because it
| was single-threaded with good async I/O primitives (or good
| enough, this was before Promises were in the language), and
| that led to huge performance improvements over other server
| implementations that prioritized workers.
|
| So while I still don't like the kitchen sink approach, I'm
| still left feeling like a lot of the problems and solutions
| being proposed here are kind of things that would be
| addressed by using Deno in Emacs? At least, I'm seeing the
| appeal. Single-threaded memory pool to help make developer
| experience better and to improve performance, coupled with
| decent async I/O primitives -- that's Javascript, that's
| one of the things the language is sort of good at. You have
| workers for larger tasks, and that's definitely handy, but
| most of your programming is happening in a single-threaded
| event loop using promises.
|
| If I looked at this sentence in isolation, I would think
| that you were arguing in favor of adding Deno.
| samus wrote:
| Adding a new language still doesn't solve the blocking
| problems with the _current_ extensions. It still seems
| way less complicated to just patch the extensions that
| are not behaving well. If their maintainers don 't want
| to cooperate, there is always the possibility to fork
| these extensions, but that's also way easier than writing
| these from scratch or treating them in Typescript.
| danShumway wrote:
| > Adding a new language still doesn't solve the blocking
| problems with the current extensions.
|
| That is a pretty strong argument which I agree with. The
| somewhat dismissive answer I could give around JS in
| Emacs is that if I wanted to write JS so badly that I was
| willing to rewrite the ecosystem in order to do it, I'm
| not sure why I shouldn't just use VS Code.
|
| I'm floating the idea that JS would be a good fit for a
| lot of these problems, but it is correct to ground that
| with the idea that having 2 separate coding languages in
| a text editor just feels weird and cumbersome and I don't
| know, isn't the ecosystem fragmented enough? I can't
| _actually_ avoid Elisp in Emacs and I wouldn 't be able
| to just because Javascript was added.
| chlorion wrote:
| I think having a single-threaded async/await style
| interface for doing non-blocking things like creating and
| reading output from subprocesses could be pretty nice.
|
| As far as I can tell Emacs already supports the primitives
| required to implement an async/await style interface. The
| way it works now, is that the editor is one big event loop.
| The event loop handles reading keyboard input and eval'ing
| the elisp functions bound to those keys, and while that's
| not happening, non-blocking things like subprocesses are
| being progressed. This happens outside of elisp, inside of
| the C part of Emacs somewhere.
|
| Right now subprocesses support using custom "sentinels",
| these are an elisp function that gets called by the event
| loop whenever the subprocess progresses in some way.
|
| I'm not really a concurrency expert but I think you could
| work these already existing things into a nice interface.
| Having built in support for this would be a huge upgrade!
|
| There are libraries like emacs-aio that try to do this, but
| I don't know very much about them right now, but that
| should at the least serve as a proof of concept.
| taeric wrote:
| I'm still not entirely clear that most people understand the
| problems that well. The way you would hear it on most forums,
| emacs blocks whenever you do anything that takes time.
| Nevermind compilation mode being a thing basically forever.
|
| So, yes, you can block the UI thread. There have been ways to
| not do that basically forever. I welcome better ways to
| manage this, but there will always be some way to do code on
| the UI thread, such that it will always be possible to
| somewhat block things.
|
| The alternative is to make all code preemptive, it seems. And
| that just begs for race conditions on the shared mutable
| state that is the editor.
| danShumway wrote:
| So this is a complaint I do have. But in fairness, I do
| worry a little that I've used Emacs for so long as my
| primary text editor that I've lost perspective of what the
| failure rates are for other text editors. I remember Atom
| being absolutely terrible about this, and thinking that
| Emacs was basically as good if not significantly better at
| not blocking the UI whenever it needed to think.
|
| The problem is I had to use Atom for a while seriously
| before I understood how often it failed for me. If you're
| just trying out a text editor to see if it's comfortable,
| you don't see these failure modes as clearly. So I've tried
| VSCode before, but I don't know if it's better or worse at
| avoiding hanging the UI, because I don't use it constantly
| all day long with a ton of packages installed.
|
| If I had to make a list of all the times I get frustrated
| at Emacs, a long operation that has nothing to do with the
| UI blocking everything is pretty high on the list, that is
| a regular complaint that I have. I feel comfortable saying
| that I wish Emacs packages would get better at this, and
| maybe there are ways to improve it within Emacs.
|
| But I guess truthfully for all I know VS Code could have
| the same problem but even worse.
|
| I agree that making code preemptive is probably not a good
| idea.
| oefrha wrote:
| > The way you would hear it on most forums, emacs blocks
| whenever you do anything that takes time. Nevermind
| compilation mode being a thing basically forever.
|
| Sure, it's _possible_ to write code that doesn't block the
| UI, but it's very difficult in Emacs and just about every
| built-in functionality is an offender. This includes
| network operations, which can block forever. You'd be
| laughed out of the room if you implemented a text editor
| today that can lock up completely and indefinitely with M-x
| package-list-packages.
| taeric wrote:
| I'm a little confused, as that doesn't seem to block on
| my machine? Is it something that used to block, but
| doesn't anymore?
|
| You are right that it is difficult in many respects. But
| it is far from impossibly difficult. And most of the
| tricks you could do to make it easier typically lead to
| some silly hard edge cases in the code.
| worik wrote:
| > I'm a little confused, as that doesn't seem to block on
| my machine?
|
| Me too.
|
| I routinely run emacs on a Raspberry Pi IV building large
| rust projects
|
| Blocking has never been an issue
|
| I bury the compilation buffer and carry on as usual
|
| The main problem I have is too many options and
| possibilities
|
| I think a better thing to do is organise all the third
| party packages with decent documentation
|
| The documentation in the package ecosystem ranges from
| barely adequate to woeful with the emphasis on the latter
| jorams wrote:
| package-list-packages does not do network operations in
| the foreground unless package-menu-async is nil. It's t
| by default. package-refresh-contents does, but I've
| always been able to C-g to abort at any time.
| jlarocco wrote:
| > Genuine question, not trying to be snarky: isn't JS a great
| way to address most of those concerns that you list?
|
| I genuinely don't think it is - Javascript is just a
| language. Why not implement Async I/O and WebWorkers APIs in
| Elisp? Why complicate things with an entirely new language?
|
| And with Elisp native compiled on most platforms, it seems
| doubtful WebAsm is going to make a noticeable difference in
| performance.
| ASalazarMX wrote:
| Fair point, but have you considered the joy of tarnishing
| nice things with JavaScript? Corrupting the venerable Emacs
| would be a great achievement.
| dleslie wrote:
| If Emacs moved away from Lisp I would simply stop using Emacs.
| It's a key factor in why I use Emacs instead of NeoVim, or
| VSCode.
| paddy_m wrote:
| I'm glad to see ambitious development being done on the core
| emacs platform. Could you include some images of what is possible
| with webrender in the README and the introduction to your docs
| page. I think it will help others get excited about what you're
| building.
| coldacid wrote:
| One of the great things about Emacs is that I can run it on a
| terminal when needs be, or as a GUI application when I have a
| graphical environment up and running. Doing something like
| rebasing it on WebRender means I wouldn't be able to use it in
| the terminal anymore.
|
| There are plenty of problems in Emacs that need to be resolved,
| but this is NOT one of them.
| charcircuit wrote:
| This project probably didn't remove no window mode. Even if
| they did remove it, in 2024 people are using Emacs in a GUI
| whether directly or hosted within a terminal emulator.
| cloudhan wrote:
| You might also want to watch on helix, if PR 8675 is merged, then
| scheme will be the extension langauge, then we get the best of
| both world. Modal editing and scheme =)
|
| PR 8675: https://github.com/helix-editor/helix/pull/8675
| __MatrixMan__ wrote:
| I'm pretty excited about that.
|
| Helix is great and I have a plugin in mind and I aspire to get
| more acquainted with the lisp perspective (though I find emacs
| a bit much). It's gonna be fun.
| notnmeyer wrote:
| man, this will be so great! getting a plug-in system in place
| will be huge for helix. gimme that sweet sweet copilot.
| vindarel wrote:
| There's also Lem, which has a good vim mode and is scriptable
| in Common Lisp (since it's built in CL) :D
| https://github.com/lem-project/lem/ It has: LSP support, a
| treeview, project-related commands, a directory mode, a POC git
| mode... with ncurses and SDL2 UIs.
| BaculumMeumEst wrote:
| the text rendering on the SDL2 frontend is much better than
| the last time I tried it, and performance is much improved.
| the install process used to be quite painful before but is
| very easy now. maybe sometime in the next 5 years i'll build
| enough willpower to start trying to port over all my stupid
| little emacs customizations. but it would be a bummer to lose
| tramp.
| smegsicle wrote:
| pretty sure the -ng suffix is for a rewrite after the original is
| abandoned, not taking something that's still developed and
| slapping on random web tech
| mst wrote:
| I might have called it emacsperiment instead but the
| documentation is very clear about what it is/isn't so shrug.
| layer8 wrote:
| JavaScript is like the hammer that makes every problem look like
| a nail.
| DDSDev wrote:
| I am the main author behind the JS/TS integration for emacs-ng. I
| still think it is one of the cooler things I have done that
| people have taken note of.
|
| I am a game programmer by trade, and I had experiencing embedding
| JS into projects from a previous engine I worked on where JS was
| the primary gaming scripting layer.
|
| I love emacs and I love lisp in general - I added JS to emacs
| mainly to find out if I could do it. I also had a hope that
| adding JS could expand emacs usage to people that don't know
| elisp, and have JS be a "gateway" into elisp.
|
| I think that the JS integration is a huge testament to the
| flexibility and quality of emacs and elisp.
|
| As I have gotten older, I've had less and less time for open
| source, but I don't consider this project abandoned. I still want
| to upgrade us to the latest deno. My previous upgrade attempt
| (which you can see in draft PR at the time of this comment) was a
| little too ambitious - I tried to move us to a more multithreaded
| approach, but I think I need to work on this more incrementally.
| _hl_ wrote:
| I've always wanted to start building something much like this,
| but the sheer scale of the task put me off.
|
| I tip my hat and then some to the fine folks rolling this stone
| up the mountain. And that's coming from someone who is married to
| elisp.
| 3836293648 wrote:
| Does webrender actually help yet or does it still bring
| everything to a crawl when transparency gets involved?
|
| The other unfortunate part of this is that it's based on the gtk
| branch, which breaks certain input chains that I personally rely
| on
| exxos wrote:
| Why not Bun ?
___________________________________________________________________
(page generated 2023-11-17 23:01 UTC)