Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs GUI Library

andreyor.st

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Emacs GUI Library

#51

Post by rgoulter »

Syntonicles wrote: post #41
MatthiasPortzel wrote: post #17

I tried to switch to EMacs a year or so ago. I used it for a couple months and I enjoyed the configurability in elisp. One of the last straws for me was that when scrolling down, the cursor moved to stay on the screen. This is one of the quirks of it being a TUI originally. (There is of course a package to for this functionality, but I found it would break frequently.)

I think it's misguided to think of Emacs having moved away from the TUI paradigm at all. I have lived in Emacs for two years and have never even considered scrolling with my mouse. My hand never touches the mouse. As I move through the document, I already have the location of the cursor origin saved in a register and can jump there, or any of several other locations with a single keypress. I've always considered the…

> I've always considered the mouse & menu system to be an emergency backup for beginners who have hit a wall. They will probably never be first class citizens.

Perhaps, but ideally you'd want your on-ramp experience (or your gateway experience) to be smooth, rather than a full cold-turkey.

Re: Emacs GUI Library

#53

Post by MatthiasPortzel »

Syntonicles wrote: post #41
MatthiasPortzel wrote: post #17

I tried to switch to EMacs a year or so ago. I used it for a couple months and I enjoyed the configurability in elisp. One of the last straws for me was that when scrolling down, the cursor moved to stay on the screen. This is one of the quirks of it being a TUI originally. (There is of course a package to for this functionality, but I found it would break frequently.)

I think it's misguided to think of Emacs having moved away from the TUI paradigm at all. I have lived in Emacs for two years and have never even considered scrolling with my mouse. My hand never touches the mouse. As I move through the document, I already have the location of the cursor origin saved in a register and can jump there, or any of several other locations with a single keypress. I've always considered the…

Thanks for sharing your view. I definitely prefer a GUI editor, I’m currently using Sublime.

I was attracted to emacs because I like writing lisp and I hoped that the high level of customizability would let me smooth over any rough edges. But even though Sublime is not very flexile at all, it’s closer to what I want than I was able to script emacs to be.

Re: Emacs GUI Library

#54

Post by MatthiasPortzel »

seabass-labrax wrote: post #30
MatthiasPortzel wrote: post #17

I tried to switch to EMacs a year or so ago. I used it for a couple months and I enjoyed the configurability in elisp. One of the last straws for me was that when scrolling down, the cursor moved to stay on the screen. This is one of the quirks of it being a TUI originally. (There is of course a package to for this functionality, but I found it would break frequently.)

Are you referring to scroll-restore[1], by any chance? [1]: http://elpa.gnu.org/packages/scroll-restore.html

Yes. If I remember correctly, selecting a region with the mouse would cause it to error and only resume working when emacs was restarted.

Re: Emacs GUI Library

#55

Post by rileyphone »

jfb wrote: post #7
omnicognate wrote: post #2

Anybody should feel free to do what they like to emacs, it's free software. But this would be a fork I would have absolutely no interest in whatsoever. The author sees the fact that emacs UIs are textual as a negative, but it's the reason I love it, the reason I've been using it for 20 years and I dare say the reason some have been using it twice as long. Ditching terminal support and replacing emacs TUIs with GUIs w…

I have long wanted something that was basically a modern~ish Smalltalk environment, that spends more energy integrating with the rest of the world. Emacs is as close as we can get to a system that is inspectable, plastic, and open; I want those qualities in my entire computing environment, and there is literally nothing available for any price better than Emacs at this, but Emacs isn't good at it.

I believe the web currently possesses the capabilities to make a networked Emacs/Smalltalk style system, souped up with AI, targeting web applications that don't require downloads; I've been pursuing such a system for a while and hope to have a prototype soon. There isn't really anything like this - Emacs is stuck in Unix-land, Replit is tied to React/Next.js (blegh), and Urbit sees obscurity as a virtue.

Re: Emacs GUI Library

#56

Post by cmrdporcupine »

NoGravitas wrote: post #27

So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit. It's the most Emacs way of doing things. However! There is one big thing you lose. I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. And it is currently the case that programs written for Emacs almost always…

feels like the right thing here is for the library present a declarative API ("i need these pieces of info of this kind") and then have separate GUI and TUI backends, with the ability to override the rendering options for either

but, yeah, that kind of thing always sounds great in theory, but is always ridiculously hard to get right in practice

Re: Emacs GUI Library

#57

Post by erksa »

jpmattia wrote: post #44

> Speaking of terminals, Emacs can actually run in a terminal! You can start it with emacs -nw and it will happily transform your terminal into Emacs. I love how this is written, as if there wasn't a time that running emacs in the terminal was the only way to run emacs.

I'd imagine the average age of emacs users is younger than emacs itself at this point.

Re: Emacs GUI Library

#58

Post by cmrdporcupine »

jpmattia wrote: post #44

> Speaking of terminals, Emacs can actually run in a terminal! You can start it with emacs -nw and it will happily transform your terminal into Emacs. I love how this is written, as if there wasn't a time that running emacs in the terminal was the only way to run emacs.

to be fair, I've been using emacs since 1992, and from about 1994 on-wards almost all of that usage was in an X windows session, unless I was doing something remote

Re: Emacs GUI Library

#59

Post by iscream26 »

NoGravitas wrote: post #27

So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit. It's the most Emacs way of doing things. However! There is one big thing you lose. I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. And it is currently the case that programs written for Emacs almost always…

> So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit.

I was just thinking this myself. I was thinking about a small, limited-vocabulary (widgets) GUI toolkit (implemented without web technologies) inside of Emacs that could still be navigated with a keyboard. GUI windows would be differentiated from buffer windows, and so functions that are defined for one of them couldn't be enabled on the other. Packages could implement their functionality in either type of window, or both, depending on their purpose.

> I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. [...] That's something I'd dearly hate to lose.

In the imaginary implementation I described above those would still work, they would be buffer-interface-only packages. They wouldn't have to be re-implemented nor updated to keep working properly.

> You could sort of work around that by defining abstract widgets and providing both GUI and TUI implementations, but that constrains the GUIs a lot [...]

It doesn't have to be that way. If GUIs and buffers are defined as different types of interface paradigms that can be used and modified within Emacs, then GUIs could be completely different from their buffer counterparts and vice versa. Packages that wouldn't make sense having on a terminal wouldn't have to implement a buffer interface for it. And not every package would have to implement its own GUI interface either if there's no need for it; buffers are a very simple data model with a vast amount of tooling for them that can all (in theory) work in tandem, so they would still be an attractive baseline for any developer looking to extend the functionality of their editor.

Re: Emacs GUI Library

#60

Post by cmrdporcupine »

Decabytes wrote: post #4

Recently I've been consolidating my workflow. First is using a single monitor, and then using shortcuts to switch to other Windows when I need to. I find that for me it's easy to get distracted when I have multiple different Windows up. I also have moved from a workflow in Emacs where I split my buffer and have things side by side, to one where I make new frames and then flip to the frames. This is easier on my eyes…

There have been tiling window managers based around Emacs before. I think the most recent I tried was https://github.com/ch11ng/exwm -- in this case the window manager is itself emacs, and your windows are buffers in emacs etc.

It makes a lot of sense, since Emacs does its own tiling, and one is usually familiar with the keystrokes already, and then you don't have tiling in tiling.

So I keep meaning to go back and try this again, or something similar, but I recall it having issues with a lot of my commonly used applications back when I tried it.

When I get in the tiling mood, I use regolith, which is a nice packaging up of i3 in with the gnome environment. I'd love to have something like that, but built around emacs.

(The crazy thing is I'd probably end up editing source code in CLion inside that... since the CLion Rust plugin is superior to anything I can get in emacs)

Post reply on HN