11 ms·

Emacs GUI Library

161 points by iscream26 3y ago

omnicognate 3y ago
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 would not be progress, and if that's what you want I doubt modifying emacs is going to be a rewarding way of trying to achieve it. Just use vscode.
- jfb 3y ago
  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.
  - omnicognate 3y ago
    Then go ahead and build it. All I'm saying is that A) that's a fork of emacs I won't be remotely interested in and B) I highly doubt starting with emacs will be good way to achieve it (but go ahead and try by all means). (Anything that removes terminal support from emacs will be a fork.)
    - jfb 3y ago
      Yeah, it's true. And Emacs would be a very poor substrate for this.
    - iLemming 3y ago
      > (Anything that removes terminal support from emacs will be a fork.) GNU/Emacs already has tons of features that don't work in terminal and it's not a fork. GUI has: - better fonts and better colors - childframe support, nice for posframes - viewing images and pdfs - SVG support - icons and emojis - etc.
  - rileyphone 3y ago
    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.
  - trenchgun 3y ago
    https://pharo.org/ https://pharo.org/ ?
  - guestbest 3y ago
    Is there a modern smalltalk that focuses on building TUI?
- User23 3y ago
  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?
  - AlanYx 3y ago
    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.
    - PurpleRamen 3y ago
      Some customizing being easier, doesn't mean it's overall more customizable. Both have a different focus in customizing, and different areas where it's easy or hard.
- nequo 3y ago
  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.
  - ymherklotz 3y ago
    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 would be much tougher to get a uniform feel with graphical windows.
    - ParetoOptimal 3y ago
      > 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.
    - alwaysbeconsing 3y ago
      There's no reason keyboard navigation can't work in a GUI context. In fact it might be easier to define things like "up" or "forward" since widgets will often have a natural hierarchy with direct references to each other, so there's no need to parse anything to figure out what the "sexp" is.
      - ParetoOptimal 3y ago
        One problem is that macros currently work even in things like the settings buffer. If you change that to GUI, depending on the implementation, I'm not sure if that stays true. For a settings buffer, maybe it doesn't matter. However macros working everywhere in your editor as a default is quite powerful.
- ArtWomb 3y ago
  XEmacs 24 on SunOS 5 was cool: code, web, mail, data all-in-one! Pixel Fold & Tablet 5G + living in Emacs on Android at the cafe, beach and golf resort is totally do-able ;) https://www.reddit.com/r/emacs/comments/ugxfi2/fyi_i_installed_emacs29_with_native_compilation/ https://www.reddit.com/r/emacs/comments/ugxfi2/fyi_i_install...
- Barrin92 3y ago
  >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 on the same footing with modern IDEs I don't think you get around to at some point getting it to a modern GUI system.
  - ifyoubuildit 3y ago
    > If you want to put Emacs on the same footing with modern IDEs I don't think you get around to at some point getting it to a modern GUI system. Maybe I'm in the minority on this, but I'm not interested in emacs being on the same footing with modern IDEs. I'm happy with what it is, and would be sad if it didn't exist as it does today. (I only ever use emacs without -nw by accident)
  - ParetoOptimal 3y ago
    > 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?
- pjmlp 3y ago
  XEmacs was what made me actually enjoy Emacs back in the day.
- witx 3y ago
  And ideas like these (there are tons amongst longer emacs users) is part of the reason of why I left emacs after 8 years of running my own config. I just can't stand the reasoning "No no don't change things I like how they are, cowebs and all". There are lots of places emacs should improve to became a better modern editor, not necessarily to attract more people but to make the life of those who use it better.
taeric 3y ago
I'm actually surprised you can't stage regions in magit, as it clearly seems to indicate that you can. Mark a section and it will ask about regions. Clearly, this hasn't come up that often for me, or I may have already known this. (More likely, if it came up often, someone would have made it work. :D ) I do think regarding things as "text" goes a long way to underestimating what can be done with it. As easy to think of it as serialized symbols, where the symbols can have specific meaning. At this point, the power seems a bit more manifest. If you are lucky (and someone else has put in the work), then you can use familiar "textual" symbol manipulations and that will keep meaning in the other domain that is being represented.
- omnicognate 3y ago
  You certainly can stage regions. The author is complaining of a bug - not one I've seen and possibly some sort of interaction with another package he's using. Magit's author is awesome so maybe worth raising a github issue... and donating!
  - taeric 3y ago
    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?
    - omnicognate 3y ago
      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.
      - taeric 3y ago
        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.
Decabytes 3y ago
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 as I can have a large window for larger fonts, and I don't have to deal with wrapping in both Windows. 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
- andsoitis 3y ago
  > 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?
  - jxf 3y ago
    The ability to render pictures inline (imo).
    - taeric 3y ago
      Emacs can do that today, though?
      - entropie 3y ago
        Iam pretty sure emacs was capable of rendering any images (invluding svgs) more than a dekade ago. I remember because I was really excited as I realized.
    - tra3 3y ago
      You can link images with org-mode and toggle their visibility [0]. You can have 'em resized etc. #+CAPTION: This is the caption for the next figure link (or table) #+NAME: fig:SED-HR4049 [[./img/a.jpg]] [0] https://orgmode.org/manual/Images.html https://orgmode.org/manual/Images.html
znpy 3y ago
> 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
- gglitch 3y ago
  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/Quick-Start-Guide.html https://www.gnu.org/software/emacs/manual/html_node/tramp/Qu...
  - gglitch 3y ago
    I've known this was possible for many years; but on a lark, I just wrote a microfunction that opens, in my local Emacs, a remote file I often have to edit as root. I don't live in Emacs, but there's no denying that, if I'm already in Emacs and I need to edit this file, I just saved myself a small amount of faffing about; I've also added my local init as a site for future automations. ;; Update [redacted] (defun [redacted] () (interactive) (find-file "/ssh:[me]@[host]|sudo:[host]:[file]"))
  - znpy 3y ago
    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)
    - taeric 3y ago
      Why does that break? Tramp should basically wake up and reconnect on all things.
      - ParetoOptimal 3y ago
        It does reconnect, perhaps they've not tried it.
MatthiasPortzel 3y ago
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.)
- seabass-labrax 3y ago
  Are you referring to scroll-restore[1], by any chance? [1]: http://elpa.gnu.org/packages/scroll-restore.html http://elpa.gnu.org/packages/scroll-restore.html
  - MatthiasPortzel 3y ago
    Yes. If I remember correctly, selecting a region with the mouse would cause it to error and only resume working when emacs was restarted.
- taeric 3y ago
  This is a fun one, all told. The Mac way of leaving the cursor at the top of a document is infuriating to me. Why would I want the cursor to be off of the visible screen? Point being that I suspect this is very much a learned behavior and you can grow to like either way. Not that one is superior to the other.
- Syntonicles 3y ago
  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 mouse & menu system to be an emergency backup for beginners who have hit a wall. They will probably never be first class citizens. What editor do you use?
  - 3y ago
binary132 3y ago
NYET, EMACS IS FINE.
- Koshkin 3y ago
  But every decent OS must have a GUI toolkit!
  - NoGravitas 3y ago
    [flagged]
CalChris 3y ago
What is the current state of using emacs within VSCode? Is it just keybindings or is there something more like what vscode-neovim has?
- pksebben 3y ago
  Just out of curiosity, what would you expect the value-add to be in this? From my perspective, if you're using emacs, it's value comes from being the 'top layer' that ties together all the functions and coordinates between the things you need. This is a genuine question coming from a place of relative ignorance, mind you. I haven't touched VSCode since the dark ages so I don't really know what it adds to the experience.
- ParetoOptimal 3y ago
  The bindings of emacs are the least impressive part while extensibility, pervasive documentation, and uniformity everywhere are the best.
NoGravitas 3y ago
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.
- cmrdporcupine 3y ago
  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
- iscream26 3y ago
  > 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.
sureglymop 3y ago
I really like this blogs ui! I think it was made with hugo.
- entropie 3y ago
  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.
  - fhd2 3y ago
    Being an Emacs guy, I can recommend weblorg - I guess most people haven't heard about org-mode indeed, but it's one of the biggest reasons I stuck to Emacs, worth a look. Got curious what this guy uses for the site, but couldn't find a public repo for it with a few minutes of digging. Mostly you couldn't really tell what static site generator someone uses unless it's one that supports themes, and they use one of the popular ones.
  - terracottalite 3y ago
    Sadly, it seems it is just hugo. He mentions hugo in a post[1]. [1]: https://andreyor.st/posts/2020-06-05-managing-background-processes-from-kakoune/ https://andreyor.st/posts/2020-06-05-managing-background-pro...
    - BeetleB 3y ago
      He definitely is using Emacs for most of it. He authors his posts in org files, and uses ox-hugo to export to Hugo. I do something similar for my blog, except Pelican is my backend. https://andreyor.st/posts/2022-10-16-my-blogging-setup-with-emacs-and-org-mode/ https://andreyor.st/posts/2022-10-16-my-blogging-setup-with-...
    - sureglymop 3y ago
      Interesting. I think I must've seen the same post when he posted it. Nowadays I just use Pandoc to go from markdown (with extras) to html.
  - 3y ago
_a_a_a_ 3y ago
Perhaps the author could say something about how his suggestion would improve usability and me getting my work done better. AFAICS all he's saying is he wants it to be prettier.
fdr 3y ago
> And I think terminal support is one of the things that holds Emacs back. Think about it - why do you even need a terminal if you’re already using Emacs? Because I'm doing non-trivial (but probably not extensive) work on a server that does not have windowing. Tramp is a hassle for some use cases, especially if you use SSH FIDO to authenticate; either you need set up the session somewhere and use SSH channel multiplexing from a session you established previously, and some protected environments limit the number of channels per SSH connection (often, to one). Handling a text terminal emulator is a lower common denominator for sure than elisp to fulfill those functions. I'd also like to point out that emacs has been praised by those with issues with their eyesight for its textual interface working with screen readers far better in practice. Other applications inevitably break their accessibility far more often, because their programming model makes it more expensive to do and keep in good order. I don't mean to suggest this is how "text editors oughta be," but it's good at least one editor is this way, in regard to its relationship to UI elements and text.
- michaelcampbell 3y ago
  > > And I think terminal support is one of the things that holds Emacs back. Think about it - why do you even need a terminal if you’re already using Emacs? > Because I'm doing non-trivial (but probably not extensive) work on a server that does not have windowing. Indeed, of the ~7 machines I work on regularly, 5 of them are via ssh and need no GUI. `emacs -nw` is so much quicker and efficient than having to deal with an X server (or equivalent). And the GUI provides me with really no benefit.
jpmattia 3y ago
> 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.
- erksa 3y ago
  I'd imagine the average age of emacs users is younger than emacs itself at this point.
- cmrdporcupine 3y ago
  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
palmy 3y ago
This post just made me check out XWidget support in Emacs, and oh my bejebus is this amazing. Yes, it's not like running an actual browser, but this is so much better than anything I expected. https://macowners.club/posts/using-xwidgets-on-macos/ https://macowners.club/posts/using-xwidgets-on-macos/ gave me a quick and nice overview of how it looked.
- e40 3y ago
  Just tried the install given in the above blog and the resulting emacs wouldn't take any input. All of it was read by the Terminal where I started emacs-mac.
ParetoOptimal 3y ago
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.
whartung 3y ago
I 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 < 10s. I've tested it across Mac/Ubuntu/Windows, and it all seems to work. (JavaFX does not support Wayland, so I don't know what the real impact of that is.) 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.
pjmlp 3y ago
It is surprising how after all these years, Emacs still doesn't have the all the GUI capabilities as Zmacs, or Interlisp Executive/SEdit.
spiralpolitik 3y ago
A future for Emacs would be to separate out the underlying engine from the ui layer. That way the TUI and a more GUI based Emacs could evolve separately without one being hamstrung by the other.
agumonkey 3y ago
if kept sensible[0], this could lead to great many talks and projects [0] be sure to review lisp culture of homoiconicity, so not to add too many layers, a bit like M-x customize.. but be a bit crazy too :)
BeetleB 3y ago
> It’s easy to forget about it, and use such things like Treemacs, Customize, heck, even Org Mode, thinking that you’re interacting with UI elements (file nodes in Treemacs, text-boxes in Customize, Org Modes sub-trees and drawers). However, it is an illusion, though neatly crafted. It’s still text. Org mode, in particular, is a real pain to script. It's a tree based workflow, but behind the scenes it is all text parsing. There's no "node" structure. When you compare it with Leo[1], the elisp to manage org mode nodes is horrible. Nevertheless, I am not in favor of this post's primary thesis. The fact that you can attempt forward-sexp in a Magit buffer is a good thing. One of the joys with Emacs is utilizing commands from one Emacs package in another without either author intending it. I, for one, would be very upset if the Magit buffer disabled forward-sexp without a good reason. [1] https://leo-editor.github.io/leo-editor/ https://leo-editor.github.io/leo-editor/
- radarsat1 3y ago
  > behind the scenes it is all text parsing. There's no "node" structure. But I feel like this is one of the strongest things about org mode and something that keeps it really apart from similar tools. Rather than being forced to think in "org" and manipulate its "objects", you just manipulate text, and if you happen to shape that text into something org recognizes, then it knows how to work with it. This is amazingly inviting because you never feel "stuck" like you converted something to the wrong type of thing and now can't get it back, or whatever. Instead if you make a mistake you just.. change it to what it should be. It feels very fluid and you learn it quickly because you're not presented with trying to fit your thoughts into someone else's abstractions. You just write what you want and progressively learn more and more how to naturally shape your work into something that org can help you with.
  - BeetleB 3y ago
    > But I feel like this is one of the strongest things about org mode and something that keeps it really apart from similar tools. Having manipulated nodes in both Leo and Org mode, the former is one to two orders of magnitude easier (no exaggeration!), and I did not find anything lacking in it compared to text parsing org nodes in elisp. I'm not arguing that text parsing should not work, or not be available. But there really should be a solid, robust API to do simple things like: 1. Move a node from one place to another. 2. Get the body of the node (sans any children, drawers, and other metadata). 3. Traverse nodes in whatever order you want (DFS, BFS, random, etc). The underlying implementations of these functions can handle the text parsing. I shouldn't have to do it every time.
JoeyBananas 3y ago
Many have tried to have a GUI in emacs, but it is always doomed to fail. In Emacs, the tyranny of the text buffer is real. There is just not much you can do to escape it.
iLemming 3y ago
You boomers who are screaming that Emacs doesn't need a GUI layer perhaps need to wake up. It's 2023 and we're constantly dealing with an enormous amount of data. The data that's begging to be visualized. Lisp (especially Clojure) is one of the best tools to deal with data. You can slice it, dice it, chunk it up, measure it, convert it, analyze it, etc. Having a composable, extensible graphics layer in Emacs is only the natural next step in its evolution. When it finally gets added, you will happily be using its awesome features while shaking your heads, remembering that at some point you were against them.
- ticviking 3y ago
  Emacs pretty clearly needs to be split into 3 layers. Elisp The editor - written in elisp GUI/TUI - Also in elisp that call back to the editor functions.
BaculumMeumEst 3y ago
i wish so badly that ccl was ported to ARM mac so that you could build GUI programs with the cocoa interface on a newer machine
dkarl 3y ago
> Lately, my Magit buffer broke once again because of something weird going on with major mode It's 2023, and emacs still sucks in exactly the same way as it did when I first used it in 1995, and when I last used it for everyday coding in 2009-2010. Every time I tried to buff emacs with extra functionality, I found it constantly breaking. I would post to mailing lists about code changes I had to make to get modes working, and I found that other users treated it as a totally normal part of the user experience to have to rewrite some code to get things working in your setup. Comments like this let me know that it happens even to the emacs gurus; they just don't mind it as much and (presumably) can fix it faster than the rest of us. Emacs doesn't need a GUI library. It needs a rewrite with a different architecture for modern times, and people who love emacs should keep trying despite the many past failures. Correction: emacs doesn't need anything. It can continue in its present form for decades, but I think it would be nice if it had a bigger, brighter future that might bring me back to it someday.
deafpolygon 3y ago
Unpopular take; let's move beyond this and ditch Emacs - invest in newer things (glad I can only get downvoted to -4, which I fully expect with this comment).
- nequo 3y ago
  For better or for worse, Emacs is in a unique spot with package availability and with how easy it is to extend. Do you have a good copyleft alternative that its maintainers can't just turn into closed source, or one that is fully open source and isn't injected with telemetry?
  - deafpolygon 3y ago
    Emacs is also very old, rooted in antiquity, and has cruft that really needs to be jettisoned. What prevents us from creating copyleft alternatives to Emacs that are rooted in a modern paradigm?
    - nequo 3y ago
      What prevents us is probably the willingness to put in the hours and the coordination to do so. It is not easy to write an alternative that improves on it but is also capable of running Org and Magit which are two nontrivial packages that make people stick with Emacs.
smitty1e 3y ago
Among the array or reasons to hold tight to text: Emacs really doesn't care if there is a desktop or not. If one wanders headless in the clouds over SSH, the same configuration works fine; lasts a long time. "Pixels to those that require them", say I.

161 points by iscream26 3y ago

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 would not be progress, and if that's what you want I doubt modifying emacs is going to be a rewarding way of trying to achieve it. Just use vscode.

jfb 3y ago
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.
- omnicognate 3y ago
  Then go ahead and build it. All I'm saying is that A) that's a fork of emacs I won't be remotely interested in and B) I highly doubt starting with emacs will be good way to achieve it (but go ahead and try by all means). (Anything that removes terminal support from emacs will be a fork.)
  - jfb 3y ago
    Yeah, it's true. And Emacs would be a very poor substrate for this.
  - iLemming 3y ago
    > (Anything that removes terminal support from emacs will be a fork.) GNU/Emacs already has tons of features that don't work in terminal and it's not a fork. GUI has: - better fonts and better colors - childframe support, nice for posframes - viewing images and pdfs - SVG support - icons and emojis - etc.
- rileyphone 3y ago
  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.
- trenchgun 3y ago
  https://pharo.org/ https://pharo.org/ ?
- guestbest 3y ago
  Is there a modern smalltalk that focuses on building TUI?
User23 3y ago
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?
- AlanYx 3y ago
  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.
  - PurpleRamen 3y ago
    Some customizing being easier, doesn't mean it's overall more customizable. Both have a different focus in customizing, and different areas where it's easy or hard.
nequo 3y ago
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.
- ymherklotz 3y ago
  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 would be much tougher to get a uniform feel with graphical windows.
  - ParetoOptimal 3y ago
    > 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.
  - alwaysbeconsing 3y ago
    There's no reason keyboard navigation can't work in a GUI context. In fact it might be easier to define things like "up" or "forward" since widgets will often have a natural hierarchy with direct references to each other, so there's no need to parse anything to figure out what the "sexp" is.
    - ParetoOptimal 3y ago
      One problem is that macros currently work even in things like the settings buffer. If you change that to GUI, depending on the implementation, I'm not sure if that stays true. For a settings buffer, maybe it doesn't matter. However macros working everywhere in your editor as a default is quite powerful.
ArtWomb 3y ago
XEmacs 24 on SunOS 5 was cool: code, web, mail, data all-in-one! Pixel Fold & Tablet 5G + living in Emacs on Android at the cafe, beach and golf resort is totally do-able ;) https://www.reddit.com/r/emacs/comments/ugxfi2/fyi_i_installed_emacs29_with_native_compilation/ https://www.reddit.com/r/emacs/comments/ugxfi2/fyi_i_install...
Barrin92 3y ago
>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 on the same footing with modern IDEs I don't think you get around to at some point getting it to a modern GUI system.
- ifyoubuildit 3y ago
  > If you want to put Emacs on the same footing with modern IDEs I don't think you get around to at some point getting it to a modern GUI system. Maybe I'm in the minority on this, but I'm not interested in emacs being on the same footing with modern IDEs. I'm happy with what it is, and would be sad if it didn't exist as it does today. (I only ever use emacs without -nw by accident)
- ParetoOptimal 3y ago
  > 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?
pjmlp 3y ago
XEmacs was what made me actually enjoy Emacs back in the day.
witx 3y ago
And ideas like these (there are tons amongst longer emacs users) is part of the reason of why I left emacs after 8 years of running my own config. I just can't stand the reasoning "No no don't change things I like how they are, cowebs and all". There are lots of places emacs should improve to became a better modern editor, not necessarily to attract more people but to make the life of those who use it better.

taeric 3y ago

I'm actually surprised you can't stage regions in magit, as it clearly seems to indicate that you can. Mark a section and it will ask about regions. Clearly, this hasn't come up that often for me, or I may have already known this. (More likely, if it came up often, someone would have made it work. :D ) I do think regarding things as "text" goes a long way to underestimating what can be done with it. As easy to think of it as serialized symbols, where the symbols can have specific meaning. At this point, the power seems a bit more manifest. If you are lucky (and someone else has put in the work), then you can use familiar "textual" symbol manipulations and that will keep meaning in the other domain that is being represented.

omnicognate 3y ago
You certainly can stage regions. The author is complaining of a bug - not one I've seen and possibly some sort of interaction with another package he's using. Magit's author is awesome so maybe worth raising a github issue... and donating!
- taeric 3y ago
  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?
  - omnicognate 3y ago
    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.
    - taeric 3y ago
      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.

Decabytes 3y ago

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 as I can have a large window for larger fonts, and I don't have to deal with wrapping in both Windows. 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

andsoitis 3y ago
> 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?
- jxf 3y ago
  The ability to render pictures inline (imo).
  - taeric 3y ago
    Emacs can do that today, though?
    - entropie 3y ago
      Iam pretty sure emacs was capable of rendering any images (invluding svgs) more than a dekade ago. I remember because I was really excited as I realized.
  - tra3 3y ago
    You can link images with org-mode and toggle their visibility [0]. You can have 'em resized etc. #+CAPTION: This is the caption for the next figure link (or table) #+NAME: fig:SED-HR4049 [[./img/a.jpg]] [0] https://orgmode.org/manual/Images.html https://orgmode.org/manual/Images.html

znpy 3y ago

> 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

gglitch 3y ago
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/Quick-Start-Guide.html https://www.gnu.org/software/emacs/manual/html_node/tramp/Qu...
- gglitch 3y ago
  I've known this was possible for many years; but on a lark, I just wrote a microfunction that opens, in my local Emacs, a remote file I often have to edit as root. I don't live in Emacs, but there's no denying that, if I'm already in Emacs and I need to edit this file, I just saved myself a small amount of faffing about; I've also added my local init as a site for future automations. ;; Update [redacted] (defun [redacted] () (interactive) (find-file "/ssh:[me]@[host]|sudo:[host]:[file]"))
- znpy 3y ago
  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)
  - taeric 3y ago
    Why does that break? Tramp should basically wake up and reconnect on all things.
    - ParetoOptimal 3y ago
      It does reconnect, perhaps they've not tried it.

MatthiasPortzel 3y ago

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.)

seabass-labrax 3y ago
Are you referring to scroll-restore[1], by any chance? [1]: http://elpa.gnu.org/packages/scroll-restore.html http://elpa.gnu.org/packages/scroll-restore.html
- MatthiasPortzel 3y ago
  Yes. If I remember correctly, selecting a region with the mouse would cause it to error and only resume working when emacs was restarted.
taeric 3y ago
This is a fun one, all told. The Mac way of leaving the cursor at the top of a document is infuriating to me. Why would I want the cursor to be off of the visible screen? Point being that I suspect this is very much a learned behavior and you can grow to like either way. Not that one is superior to the other.
Syntonicles 3y ago
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 mouse & menu system to be an emergency backup for beginners who have hit a wall. They will probably never be first class citizens. What editor do you use?
- 3y ago

binary132 3y ago

NYET, EMACS IS FINE.

Koshkin 3y ago
But every decent OS must have a GUI toolkit!
- NoGravitas 3y ago
  [flagged]

CalChris 3y ago

What is the current state of using emacs within VSCode? Is it just keybindings or is there something more like what vscode-neovim has?

pksebben 3y ago
Just out of curiosity, what would you expect the value-add to be in this? From my perspective, if you're using emacs, it's value comes from being the 'top layer' that ties together all the functions and coordinates between the things you need. This is a genuine question coming from a place of relative ignorance, mind you. I haven't touched VSCode since the dark ages so I don't really know what it adds to the experience.
ParetoOptimal 3y ago
The bindings of emacs are the least impressive part while extensibility, pervasive documentation, and uniformity everywhere are the best.

NoGravitas 3y ago

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.

cmrdporcupine 3y ago
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
iscream26 3y ago
> 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.

sureglymop 3y ago

I really like this blogs ui! I think it was made with hugo.

entropie 3y ago
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.
- fhd2 3y ago
  Being an Emacs guy, I can recommend weblorg - I guess most people haven't heard about org-mode indeed, but it's one of the biggest reasons I stuck to Emacs, worth a look. Got curious what this guy uses for the site, but couldn't find a public repo for it with a few minutes of digging. Mostly you couldn't really tell what static site generator someone uses unless it's one that supports themes, and they use one of the popular ones.
- terracottalite 3y ago
  Sadly, it seems it is just hugo. He mentions hugo in a post[1]. [1]: https://andreyor.st/posts/2020-06-05-managing-background-processes-from-kakoune/ https://andreyor.st/posts/2020-06-05-managing-background-pro...
  - BeetleB 3y ago
    He definitely is using Emacs for most of it. He authors his posts in org files, and uses ox-hugo to export to Hugo. I do something similar for my blog, except Pelican is my backend. https://andreyor.st/posts/2022-10-16-my-blogging-setup-with-emacs-and-org-mode/ https://andreyor.st/posts/2022-10-16-my-blogging-setup-with-...
  - sureglymop 3y ago
    Interesting. I think I must've seen the same post when he posted it. Nowadays I just use Pandoc to go from markdown (with extras) to html.
- 3y ago

_a_a_a_ 3y ago

Perhaps the author could say something about how his suggestion would improve usability and me getting my work done better. AFAICS all he's saying is he wants it to be prettier.

fdr 3y ago

> And I think terminal support is one of the things that holds Emacs back. Think about it - why do you even need a terminal if you’re already using Emacs? Because I'm doing non-trivial (but probably not extensive) work on a server that does not have windowing. Tramp is a hassle for some use cases, especially if you use SSH FIDO to authenticate; either you need set up the session somewhere and use SSH channel multiplexing from a session you established previously, and some protected environments limit the number of channels per SSH connection (often, to one). Handling a text terminal emulator is a lower common denominator for sure than elisp to fulfill those functions. I'd also like to point out that emacs has been praised by those with issues with their eyesight for its textual interface working with screen readers far better in practice. Other applications inevitably break their accessibility far more often, because their programming model makes it more expensive to do and keep in good order. I don't mean to suggest this is how "text editors oughta be," but it's good at least one editor is this way, in regard to its relationship to UI elements and text.

michaelcampbell 3y ago
> > And I think terminal support is one of the things that holds Emacs back. Think about it - why do you even need a terminal if you’re already using Emacs? > Because I'm doing non-trivial (but probably not extensive) work on a server that does not have windowing. Indeed, of the ~7 machines I work on regularly, 5 of them are via ssh and need no GUI. `emacs -nw` is so much quicker and efficient than having to deal with an X server (or equivalent). And the GUI provides me with really no benefit.

jpmattia 3y ago

> 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.

erksa 3y ago
I'd imagine the average age of emacs users is younger than emacs itself at this point.
cmrdporcupine 3y ago
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

palmy 3y ago

This post just made me check out XWidget support in Emacs, and oh my bejebus is this amazing. Yes, it's not like running an actual browser, but this is so much better than anything I expected. https://macowners.club/posts/using-xwidgets-on-macos/ https://macowners.club/posts/using-xwidgets-on-macos/ gave me a quick and nice overview of how it looked.

e40 3y ago
Just tried the install given in the above blog and the resulting emacs wouldn't take any input. All of it was read by the Terminal where I started emacs-mac.

ParetoOptimal 3y ago

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.

whartung 3y ago

I 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 < 10s. I've tested it across Mac/Ubuntu/Windows, and it all seems to work. (JavaFX does not support Wayland, so I don't know what the real impact of that is.) 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.

pjmlp 3y ago

It is surprising how after all these years, Emacs still doesn't have the all the GUI capabilities as Zmacs, or Interlisp Executive/SEdit.

spiralpolitik 3y ago

A future for Emacs would be to separate out the underlying engine from the ui layer. That way the TUI and a more GUI based Emacs could evolve separately without one being hamstrung by the other.

agumonkey 3y ago

if kept sensible[0], this could lead to great many talks and projects [0] be sure to review lisp culture of homoiconicity, so not to add too many layers, a bit like M-x customize.. but be a bit crazy too :)

BeetleB 3y ago

> It’s easy to forget about it, and use such things like Treemacs, Customize, heck, even Org Mode, thinking that you’re interacting with UI elements (file nodes in Treemacs, text-boxes in Customize, Org Modes sub-trees and drawers). However, it is an illusion, though neatly crafted. It’s still text. Org mode, in particular, is a real pain to script. It's a tree based workflow, but behind the scenes it is all text parsing. There's no "node" structure. When you compare it with Leo[1], the elisp to manage org mode nodes is horrible. Nevertheless, I am not in favor of this post's primary thesis. The fact that you can attempt forward-sexp in a Magit buffer is a good thing. One of the joys with Emacs is utilizing commands from one Emacs package in another without either author intending it. I, for one, would be very upset if the Magit buffer disabled forward-sexp without a good reason. [1] https://leo-editor.github.io/leo-editor/ https://leo-editor.github.io/leo-editor/

radarsat1 3y ago
> behind the scenes it is all text parsing. There's no "node" structure. But I feel like this is one of the strongest things about org mode and something that keeps it really apart from similar tools. Rather than being forced to think in "org" and manipulate its "objects", you just manipulate text, and if you happen to shape that text into something org recognizes, then it knows how to work with it. This is amazingly inviting because you never feel "stuck" like you converted something to the wrong type of thing and now can't get it back, or whatever. Instead if you make a mistake you just.. change it to what it should be. It feels very fluid and you learn it quickly because you're not presented with trying to fit your thoughts into someone else's abstractions. You just write what you want and progressively learn more and more how to naturally shape your work into something that org can help you with.
- BeetleB 3y ago
  > But I feel like this is one of the strongest things about org mode and something that keeps it really apart from similar tools. Having manipulated nodes in both Leo and Org mode, the former is one to two orders of magnitude easier (no exaggeration!), and I did not find anything lacking in it compared to text parsing org nodes in elisp. I'm not arguing that text parsing should not work, or not be available. But there really should be a solid, robust API to do simple things like: 1. Move a node from one place to another. 2. Get the body of the node (sans any children, drawers, and other metadata). 3. Traverse nodes in whatever order you want (DFS, BFS, random, etc). The underlying implementations of these functions can handle the text parsing. I shouldn't have to do it every time.

JoeyBananas 3y ago

Many have tried to have a GUI in emacs, but it is always doomed to fail. In Emacs, the tyranny of the text buffer is real. There is just not much you can do to escape it.

iLemming 3y ago

You boomers who are screaming that Emacs doesn't need a GUI layer perhaps need to wake up. It's 2023 and we're constantly dealing with an enormous amount of data. The data that's begging to be visualized. Lisp (especially Clojure) is one of the best tools to deal with data. You can slice it, dice it, chunk it up, measure it, convert it, analyze it, etc. Having a composable, extensible graphics layer in Emacs is only the natural next step in its evolution. When it finally gets added, you will happily be using its awesome features while shaking your heads, remembering that at some point you were against them.

ticviking 3y ago
Emacs pretty clearly needs to be split into 3 layers. Elisp The editor - written in elisp GUI/TUI - Also in elisp that call back to the editor functions.

BaculumMeumEst 3y ago

i wish so badly that ccl was ported to ARM mac so that you could build GUI programs with the cocoa interface on a newer machine

dkarl 3y ago

> Lately, my Magit buffer broke once again because of something weird going on with major mode It's 2023, and emacs still sucks in exactly the same way as it did when I first used it in 1995, and when I last used it for everyday coding in 2009-2010. Every time I tried to buff emacs with extra functionality, I found it constantly breaking. I would post to mailing lists about code changes I had to make to get modes working, and I found that other users treated it as a totally normal part of the user experience to have to rewrite some code to get things working in your setup. Comments like this let me know that it happens even to the emacs gurus; they just don't mind it as much and (presumably) can fix it faster than the rest of us. Emacs doesn't need a GUI library. It needs a rewrite with a different architecture for modern times, and people who love emacs should keep trying despite the many past failures. Correction: emacs doesn't need anything. It can continue in its present form for decades, but I think it would be nice if it had a bigger, brighter future that might bring me back to it someday.

deafpolygon 3y ago

Unpopular take; let's move beyond this and ditch Emacs - invest in newer things (glad I can only get downvoted to -4, which I fully expect with this comment).

nequo 3y ago
For better or for worse, Emacs is in a unique spot with package availability and with how easy it is to extend. Do you have a good copyleft alternative that its maintainers can't just turn into closed source, or one that is fully open source and isn't injected with telemetry?
- deafpolygon 3y ago
  Emacs is also very old, rooted in antiquity, and has cruft that really needs to be jettisoned. What prevents us from creating copyleft alternatives to Emacs that are rooted in a modern paradigm?
  - nequo 3y ago
    What prevents us is probably the willingness to put in the hours and the coordination to do so. It is not easy to write an alternative that improves on it but is also capable of running Org and Magit which are two nontrivial packages that make people stick with Emacs.

smitty1e 3y ago

Among the array or reasons to hold tight to text: Emacs really doesn't care if there is a desktop or not. If one wanders headless in the clouds over SSH, the same configuration works fine; lasts a long time. "Pixels to those that require them", say I.