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

21–30 of 103 posts

Re: Emacs GUI Library

#21

Post by taeric »

omnicognate wrote: post #16
taeric wrote: post #12

Earlier quoted context omitted.

My try a minute ago made it seem that it will stage every line in the region you make. Subline regions don't come up that often. Or did I try something wrong?

Yeah, it works at the line level (as indicated by the way it highlights the selected lines) which I think is a limitation as much of git itself as magit. (I'm not sure what subline staging would even do.) But the author isn't trying to stage a region, let alone a subline one. He's trying to stage a whole hunk and says its only working if point is at the start of the line.

Makes sense. I definitely took the complaint to mean that it only works at the line level. Probably because that was the only way I could see the behavior not working?

Subline staging makes sense for some changes. In that, if it does subline indications of what changed, I would expect I could accept one of the changes, but not the others. That said, I agree it is likely a limitation of git, as much as of magit. And, again, I can't imagine this comes up that often.

Re: Emacs GUI Library

#22

Post by AlanYx »

User23 wrote: post #15
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…

When did VS Code get the same level of user discoverability, customizability, and interactivity as Emacs? I took a look at it a few years ago and it didn’t have anything remotely close to what Emacs offers while working considerably worse out of the box for development than Doom. Is it worth taking another look?

Discoverability and interactivity are debatable, but customizability is still not VSCode's forte. It's easy to knock up some quick elisp to scratch an itch in Emacs, whereas just printing Hello World in VSCode requires a bunch of scaffolding as an extension.

Re: Emacs GUI Library

#24

Post by omnicognate »

giraffe_lady wrote: post #14
znpy wrote: post #6

> You start your WM of choice1, you launch Emacs, and as long as the Emacs window is focused, you live in Emacs. what if there is no WM? I do most of my work on a cloud machine where i run emacs in screen, for example

I still knead dough by hand but I don't expect kitchenaid to keep me in mind when designing mixer attachments.

That's a terrible analogy and there's zero chance of GNU Emacs dropping terminal support. Do feel free to fork it, though. (Emacs, not the dough.)

Re: Emacs GUI Library

#26

Post by jxf »

andsoitis wrote: post #10
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…

> I love Emacs but I agree with the poster about how everything as text can have its drawbacks. I'd love to see a NeoEmacs that addresses some of these issues What are the top 3 or 5 things or so you think a NeoEmacs should solve/improve?

The ability to render pictures inline (imo).

Re: Emacs GUI Library

#27

Post by NoGravitas »

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 degrade smoothly from the graphical display to the terminal, which makes Emacs apps like ement.el, nov.el, or mastodon.el the absolute best TUIs available for their respective tasks. That's something I'd dearly hate to lose.

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, and gives you something possibly not much better than what we have now.

Re: Emacs GUI Library

#29

Post by znpy »

gglitch wrote: post #8
znpy wrote: post #6

> You start your WM of choice1, you launch Emacs, and as long as the Emacs window is focused, you live in Emacs. what if there is no WM? I do most of my work on a cloud machine where i run emacs in screen, for example

Elsewhere, the author makes the point that with TRAMP, your local (gui) Emacs can transparently operate your remote machines (bringing with it of course all the customizations and functionality you've built into your local config--and of course your local window management). https://www.gnu.org/software/emacs/manual/html_node/tramp/Qu...

i know about tramp, i don't want to use it. simple stuff like closing your laptop and continuing tomorrow break (ssh connections time out)

Re: Emacs GUI Library

#30

Post by seabass-labrax »

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

Post reply on HN