Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Thoughts on using glutin and winit for the windowing system layer #25

Open
moosingin3space opened this issue Jan 12, 2017 · 13 comments
Open

Thoughts on using glutin and winit for the windowing system layer #25

moosingin3space opened this issue Jan 12, 2017 · 13 comments
Labels
discussion

Comments

@moosingin3space
Copy link
Contributor

Aside from Emacs' XWidgets support, this seems like it could simplify the portable UI layer in Emacs.
@Wilfred
Copy link
Collaborator

Wilfred commented Jan 12, 2017

Sounds like a great idea!

I think it'd be worth exploring, even if using glutin/winit prevented XWidgets. I believe XWidgets still has a number of known cornercases with bugs (e.g. it writes to massive buffer for scrolling).

@moosingin3space
Copy link
Contributor Author

I don't use XWidgets, so I would be able to immediately start using a glutin/winit-based Emacs.

@moosingin3space
Copy link
Contributor Author

moosingin3space commented Jan 13, 2017 •
edited
Loading

We'd probably also want to use RustType for portability and ease of compilation.

@leroycep
Copy link

Would it be possible, or even a good idea, to use something alacritty for this?

@moosingin3space
Copy link
Contributor Author

Wonder if alacritty and remacs could share code for drawing grids of text.

@moosingin3space
Copy link
Contributor Author

After the announcement of Pathfinder, I would be very excited about using it, with appropriate fallback, as part of this glutin/winit-based windowing system.

I think RustType should be sufficient for a proof-of-concept, though. Do you agree?

@Wilfred
Copy link
Collaborator

Wilfred commented Feb 21, 2017

The problem with RustType is that it doesn't support right-to-left text, which is a big source of complexity in (r)emacs. I don't think we want to lose that feature.

@moosingin3space
Copy link
Contributor Author

moosingin3space commented Feb 21, 2017 via email

@Wilfred
Copy link
Collaborator

Wilfred commented Feb 21, 2017

We could use the Rust bindings to freetype -- that's what servo does (though apparently it uses directwrite on windows).

jeandudey pushed a commit to jeandudey/remacs that referenced this issue May 29, 2017
@npostavs @mina86
Fix ‘!NILP (Vpurify_flag)’ assertion failure during temacs bootstrap
4b3db0d 
The recent changes to src/casefiddle.c cause build failure as seen
below:

    Starting program: /home/npostavs/src/emacs/emacs-bootstrapping/src/temacs
	--batch --load loadup bootstrap
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/libthread_db.so.1".
    Loading loadup.el (source)...
    Using load-path (/home/npostavs/src/emacs/emacs-bootstrapping/lisp
	/home/npostavs/src/emacs/emacs-bootstrapping/lisp/emacs-lisp
	/home/npostavs/src/emacs/emacs-bootstrapping/lisp/language
	/home/npostavs/src/emacs/emacs-bootstrapping/lisp/international
	/home/npostavs/src/emacs/emacs-bootstrapping/lisp/textmodes
	/home/npostavs/src/emacs/emacs-bootstrapping/lisp/vc)
    Loading emacs-lisp/byte-run (source)...
    Loading emacs-lisp/backquote (source)...
    Loading subr (source)...
    Loading version (source)...
    Loading widget (source)...
    Loading custom (source)...
    Loading emacs-lisp/map-ynp (source)...
    Loading international/mule (source)...
    Loading international/mule-conf (source)...

    lread.c:3914: Emacs fatal error: assertion failed: !NILP (Vpurify_flag)

    Breakpoint 1, terminate_due_to_signal at emacs.c:363
    363	  signal (sig, SIG_DFL);
    (gdb) bt
    #0  0x0000000000579826 in terminate_due_to_signal at emacs.c:363
    remacs#1  0x000000000060ec33 in die at alloc.c:7352
    remacs#2  0x000000000066db40 in intern_c_string_1 at lread.c:3914
    remacs#3  0x0000000000576884 in intern_c_string at lisp.h:3790
    remacs#4  0x00000000005dc84f in prepare_casing_context at casefiddle.c:69
    remacs#5  0x00000000005dd37f in casify_object at casefiddle.c:311
    remacs#6  0x00000000005dd47f in Fcapitalize at casefiddle.c:356
    remacs#7  0x00000000006325ac in eval_sub at eval.c:2219
    remacs#8  0x0000000000632368 in eval_sub at eval.c:2184
    remacs#9  0x000000000063446c in apply_lambda at eval.c:2875
    remacs#10 0x00000000006329af in eval_sub at eval.c:2294
    remacs#11 0x000000000062d462 in Fprogn at eval.c:449
    remacs#12 0x000000000062d4cf in prog_ignore at eval.c:461
    remacs#13 0x000000000062f19c in Fwhile at eval.c:982
    remacs#14 0x00000000006321f4 in eval_sub at eval.c:2172
    remacs#15 0x000000000062d462 in Fprogn at eval.c:449
    remacs#16 0x000000000062f0c4 in Flet at eval.c:963
    remacs#17 0x00000000006321f4 in eval_sub at eval.c:2172
    remacs#18 0x0000000000632963 in eval_sub at eval.c:2290
    remacs#19 0x000000000062d462 in Fprogn at eval.c:449
    remacs#20 0x000000000062f0c4 in Flet at eval.c:963
    remacs#21 0x00000000006321f4 in eval_sub at eval.c:2172
    remacs#22 0x0000000000668caa in readevalloop at lread.c:1927
    remacs#23 0x0000000000667253 in Fload at lread.c:1332
    remacs#24 0x0000000000632683 in eval_sub at eval.c:2233
    remacs#25 0x0000000000668caa in readevalloop at lread.c:1927
    remacs#26 0x0000000000667253 in Fload at lread.c:1332
    remacs#27 0x0000000000632683 in eval_sub at eval.c:2233
    remacs#28 0x0000000000631be5 in Feval at eval.c:2041
    remacs#29 0x000000000057e1af in top_level_2 at keyboard.c:1121
    remacs#30 0x000000000062ffc7 in internal_condition_case at eval.c:1324
    remacs#31 0x000000000057e1f0 in top_level_1 at keyboard.c:1129
    remacs#32 0x000000000062f51e in internal_catch at eval.c:1091
    remacs#33 0x000000000057e0ea in command_loop at keyboard.c:1090
    remacs#34 0x000000000057d6d5 in recursive_edit_1 at keyboard.c:697
    remacs#35 0x000000000057d8b4 in Frecursive_edit at keyboard.c:768
    remacs#36 0x000000000057b55b in main at emacs.c:1687

    Lisp Backtrace:
    "capitalize" (0xffffcf70)
    "format" (0xffffd130)
    "define-charset" (0xffffd370)
    "while" (0xffffd560)
    "let" (0xffffd7c0)
    "dolist" (0xffffd910)
    "let" (0xffffdb70)
    "load" (0xffffdfe0)
    "load" (0xffffe4a0)

* src/casefiddle.c (syms_of_casefiddle): Declare four new symbols:
Qtitlecase, Qspecial_uppercase, Qspecial_lowercase and
Qspecial_titlecase.
(prepare_casing_context): Use aforementioned symbols.
@cbbrowne cbbrowne mentioned this issue Nov 23, 2017
Closed
@travankor
Copy link

Any update on this?

I think if Remacs had a better rendering model than stock Emacs, this would be a massive opportunity to get more users/mindshare (like neovim with async support).

@shaleh
Copy link
Collaborator

shaleh commented Dec 23, 2018

Right now our focus is on getting the port mostly done and stable. Experimentation is welcomed but at the moment it is not our priority. @harryfei has an experiment using WebRender underway because they want to explore it. Maybe what is learned from that project can help here.

@harryfei
Copy link
Member

harryfei commented Dec 24, 2018 •
edited
Loading

Maybe what is learned from that project can help here.

That's totally true. I am using glutin and winit in my WebRender branch.

@travankor
Copy link

This is good to know. My experience so far is that gtk-rs is not that great, so I think this will be a really important topic down the road. (Some people still build their emacs with the ancient lucid toolkit to avoid the mess that is GTK)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discussion
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@Wilfred @moosingin3space @shaleh @harryfei @leroycep @jeandudey @travankor