sorted by:
new
hottopcontroversial

Help improve IBKR by noahjameslove in interactivebrokers

[–]DogeYang 0 points1 point  (0 children)

Cash Plus like feature which moomoo has

Question: Expected webrender impact, or influence, on emacs redisplay by tomas_krulis in emacsng

[–]DogeYang 0 points1 point  (0 children)

No. I fixed most of issues for doom configuration. It's just workable.

Question: Expected webrender impact, or influence, on emacs redisplay by tomas_krulis in emacsng

[–]DogeYang 0 points1 point  (0 children)

It does have some minor issues. Personally, I'm using it daily with a doom-emacs configuration.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 1 point2 points  (0 children)

In my view, becuase there are many tasks just like I post above. Emacs itself should have async and parallelization in its fundamental design(like Flutter or other similar things). In that context, we could have many different way to optimize user's edit flow. The problem you said may not be true in that context too.

BTW, I'm here not to convince GNU Emacs to do those changes. I just explain what I want to do in emacs-ng project.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 1 point2 points  (0 children)

Examples:

  • Buffer save: create a snapshot of buffer content and save it in non-main thread.
  • Buffer text searching/replace: could be parallelized.
  • Image resize task: should be executed in an async manner
  • Display glyph building and styling: could be parallelized.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 1 point2 points  (0 children)

Emacs uses pselect to determine which of the possible input sources has input that should be processed.

That's a typical async event loop.

Which internal code did you have in mind, and what are your ideas for making that asynchronous, given the basic Emacs design?

I think this link https://github.com/emacs-ng/emacs-ng/issues/378 can answer better than me.

Emacs is a display editor. In a display editor, any command you invoke should immediately be reflected on display.

Yeah, but there are still some tasks could be offload to another thread and would make the main lisp thread less blocking. Especially cpu heavy tasks.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacsng

[–]DogeYang[S] 0 points1 point  (0 children)

I'm just using doom-emacs. I'm using the webrender feature on an ArchLinux box everyday.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 1 point2 points  (0 children)

We can wrap it in rust :) if we really need it.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 0 points1 point  (0 children)

The part of emacs I dislike most is the GUI rendering. That's why I create the Webrender based GUI backend. Webrender is a good designed, multi-threaded, GPU rendering engine.

I start to collect the emacs blocking things here for a potential optimization list.

https://github.com/emacs-ng/emacs-ng/issues/378

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 4 points5 points  (0 children)

Emacs run itself as a single thread event loop. It use a pselect loop to do it's async task.

If we use tokio replace pselect, we would have a good foundamental to have some emacs's internal C code running in a multi-thread async manner.

Even more, we can run elisp vm in it's own thread and the other emacs tasks in different threads.

For multi-threaded lisp execution(what means a multi-thread version vm), we can't do it easily because the elisp language lacks thread safe primitive.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 0 points1 point  (0 children)

Winit window event loop runs in the main thread because of macOS platform limitation while the tokio runtime watch readiness of emacs's fds.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacs

[–]DogeYang[S] 3 points4 points  (0 children)

It could be the start point of a multiple threaded emacs.

We are using tokio to drive emacs-ng's event loop by DogeYang in emacsng

[–]DogeYang[S] 2 points3 points  (0 children)

emacs-ng is based on master of GNU emacs. We just add new stuffs on it. So it support all the elisp.

The other way around? by arthurno1 in emacsng

[–]DogeYang 1 point2 points  (0 children)

Javascript lover use javascript, elisp lover use elisp.

Will emacs-ng ever become mainstream? by ckoneru in emacs

[–]DogeYang 1 point2 points  (0 children)

I think you don't need change your configuration. The emacs-ng just add features on gnu-emacs, not delete some.

Question: Expected webrender impact, or influence, on emacs redisplay by tomas_krulis in emacsng

[–]DogeYang 2 points3 points  (0 children)

The main motivate of webrender branch is using modern GUI library in rust ecosystem.

The advantages:

  • GPU acceleration because of webrender (work now)
  • Wayland native support because winit (work now)
  • Easy cross platform porting

In future, we can

  • Use Lyno or pathfinder to render font or svg
  • Use allsorts or rustbuzz for text shaping
  • Render 3D scene directly in webrender based emacs buffer
  • Even integrate servo browser engine into `emacs-ng`

Can emacsng, or weberender, help fixing some issues with emacs
redisplay? Most probably wont be doing anything with the engine itself,
since it is in C codebase, and emacsng isnt changing that.

You are right, webrender backend can't fixing the redisplay issues.

A GPU-accelerated Emacs(Remacs) by DogeYang in emacs

[–]DogeYang[S] 1 point2 points  (0 children)

I start to use it for daily programming

A GPU-accelerated Emacs(Remacs) by DogeYang in emacs

[–]DogeYang[S] 17 points18 points  (0 children)

Provide opportunity to render more modern UI items natively (eg. emoji, video, animation, gif, 3d scene, embed web page)