One problem with "leave windowing yo your window manager" is now when I automate workflows by scripting that window manager and no longer enjoy emacs extensibility benefits.
Emacs GUI Library
61–70 of 103 posts
Re: Emacs GUI Library
#62Earlier quoted context omitted.
What is the benefit of drawing the interface for `M-x customize-group` as if it was plain text in the terminal when running the Emacs GUI? It makes sense for `emacs -nw` and I don't think there’s many Emacs users who are advocating for ditching terminal support. But it looks like a hack in the GUI.
The benefit is uniformity, everythings the same, which is one of the main reasons I use Emacs. I can use all of my usual navigation keys to move around the documentation of the variable, evaluate things inline, etc.. Just as if it were more text, which is what Emacs is already great at. I would mind the buttons getting a more modern look, but I think everything being text what makes it works this seemlessly, and it w…
> The benefit is uniformity, everythings the same, which is one of the main reasons I use Emacs
Not only the uniformity in use, but also the uniformity in how you extend would be lost.
Re: Emacs GUI Library
#63Anybody 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…
>Ditching terminal support and replacing emacs TUIs with GUIs would not be progress Graphical debuggers are one of the most important tools developers have gotten in the last few decades compared to the TUI and command line era. There exist packages like dap-mode for emacs which do an admirable job in simulating more graphical workflows, but they are limited by the capacities that Emacs has. If you want to put Emacs…
> There exist packages like dap-mode for emacs which do an admirable job in simulating more graphical workflows, but they are limited by the capacities that Emacs has.
Limited by emacs or by developer time?
Re: Emacs GUI Library
#64I was looking for something along this line a while ago. Closest I saw was SVG support in emacs, but for whatever reason, I couldn't get it to work, and it really wouldn't have been adequate anyway.
For those questioning the judgement of having a GUI toolkit in emacs, the answer is simply that the role and scope of emacs has long left behind being a mere text editor. For folks who like the "Lisp Machine that is emacs" I'm surprised the idea of having a modern GUI capability is so looked down upon. I think lots of folks would like a portable lisp machine with a "real" GUI. I mean, if it doesn't impact the closed loop coding and editing experience that folks are used to, what's the harm?
I had some personal projects that I would have liked to, perhaps, do in Lisp. But a requirement was that it be cross platform. I wanted to share my applications with others, and cross platform is a requirement.
And I'm lazy, I do not want to "mess with it", I want it to "just work".
I considered Pharo, but (when I looked), their raw drawing model was still very, very primitive. It was nowhere near what the Browser Canvas model or Java2d is like with their transformations and clipping and paths and what not. The Pharo model was little more than global coordinate line drawing. Plus, they keep redoing their widget toolset. GUIs are really not Pharos drive. Just enough to do another browser is their drive.
Flutter wasn't ready for the desktop yet, friend of mine is a big fan of Flutter right now. But, boy, are (were) Flutter builds slow. You're supposed to be able to a bunch of hot reloading, but that only goes so far.
The Electron style solutions just seemed overwhelming with the scope of browser frameworks (I'm not a front end dev, and I do find the front end world utterly overwhelming). Plus it's huge, the dev turnaround seemed slow when building your project, etc. Serious consideration, people have great success with it, but I chose not to.
I went with JavaFX as I'm a Java person already. Release sizes on par with Electron style apps, but my Clean/Build dev turn arounds are I did not consider Clojure, but did look at potentially using ABCL, but I honestly just didn't want to have to redo the bindings for everything from CL to JavaFX (and back). It would have been a hybrid model, and likely "the worst of both worlds". Maybe that's not true, that was just my sense.
And there's really no other decent Lispy -> cross platform GUI solution. I'm sure it could be done, but just a lot of work. I like Lisp, but I like getting stuff done more.
So, if eMacs had a rendering model and a decent GUI toolset, I could very well given it serious consideration for my dabblings and madness.
Re: Emacs GUI Library
#65What is the current state of using emacs within VSCode? Is it just keybindings or is there something more like what vscode-neovim has?
The bindings of emacs are the least impressive part while extensibility, pervasive documentation, and uniformity everywhere are the best.
Re: Emacs GUI Library
#66Earlier quoted context omitted.
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)
Why does that break? Tramp should basically wake up and reconnect on all things.
It does reconnect, perhaps they've not tried it.
Re: Emacs GUI Library
#67I 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'll split the window and then open up the same buffer in the other window. Now I have a separate window that I can scroll (using alt-pgup with alt-pgdn) while keeping my cursor and editing state right where I want it in the original window.
Re: Emacs GUI Library
#68Anybody 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…
XEmacs was what made me actually enjoy Emacs back in the day.
Re: Emacs GUI Library
#69I really like this blogs ui! I think it was made with hugo.
Since its a emacs guy its probably a self baked org/(e)lisp software capable of exporting posts in formats most people never heard of.
I used to give all my technical presentations in Emacs. https://github.com/jrockway/eslide
I have not tested it on modern Emacs, but it was fun to write. (It basically finds the largest size that each slide can be displayed in, and displays it at that size. And it of course syntax highlights code blocks with Emacs.)
Re: Emacs GUI Library
#70It is surprising how after all these years, Emacs still doesn't have the all the GUI capabilities as Zmacs, or Interlisp Executive/SEdit.