[HN Gopher] Emacs GUI Library
___________________________________________________________________
Emacs GUI Library
Author : iscream26
Score : 140 points
Date : 2023-07-11 15:52 UTC (7 hours ago)
(HTM) web link (andreyor.st)
(TXT) w3m dump (andreyor.st)
| znpy wrote:
| > 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
| giraffe_lady wrote:
| I still knead dough by hand but I don't expect kitchenaid to
| keep me in mind when designing mixer attachments.
| omnicognate wrote:
| 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.)
| gglitch wrote:
| 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...
| znpy wrote:
| 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 wrote:
| Why does that break? Tramp should basically wake up and
| reconnect on all things.
| ParetoOptimal wrote:
| It does reconnect, perhaps they've not tried it.
| gglitch wrote:
| 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]"))
| Scarbutt wrote:
| Then screen is your WM for the remote VM.
| spiralpolitik wrote:
| 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.
| whartung wrote:
| 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.
| mcpackieh wrote:
| > _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"._
|
| Have you looked at racket/gui?
| whartung wrote:
| I have heard of it, but did not look into it. As I understand
| it's rather big (deployment, memory), yet limited (in terms
| of the widget set). In fact, I hear a lot of hot and cold
| with Racket, and have for some time. Enough to be off-putting
| for me, so, no I did not consider it.
| omnicognate wrote:
| 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.
| nequo wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| alwaysbeconsing wrote:
| I don't follow. Macros are literally just vectors of
| input events; if keyboard navigation works, then so will
| a macro that replays that navigation.
| ArtWomb wrote:
| 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_install...
| jfb wrote:
| 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 wrote:
| 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 wrote:
| Yeah, it's true. And Emacs would be a _very poor_ substrate
| for this.
| iLemming wrote:
| > (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 wrote:
| 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.
| User23 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pjmlp wrote:
| XEmacs was what made me actually enjoy Emacs back in the day.
| Barrin92 wrote:
| >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.
| ParetoOptimal wrote:
| > 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?
| ifyoubuildit wrote:
| > 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)
| iLemming wrote:
| 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.
| dkarl wrote:
| > 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.
| BaculumMeumEst wrote:
| 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
| taeric wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| agumonkey wrote:
| 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 :)
| pjmlp wrote:
| It is surprising how after all these years, Emacs still doesn't
| have the all the GUI capabilities as Zmacs, or Interlisp
| Executive/SEdit.
| palmy wrote:
| 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/ gave me a
| quick and nice overview of how it looked.
| binary132 wrote:
| NYET, EMACS IS FINE.
| Koshkin wrote:
| But every decent OS must have a GUI toolkit!
| Decabytes wrote:
| 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
| User23 wrote:
| > I'd love to see a NeoEmacs that addresses some of these
| issues
|
| I believe the Nyxt browser project is eventually looking to add
| editing support. If they manage to do that robustly it might be
| just what you're looking for.
| andsoitis wrote:
| > 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 wrote:
| The ability to render pictures inline (imo).
| taeric wrote:
| Emacs can do that today, though?
| entropie wrote:
| 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 wrote:
| 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
| cmrdporcupine wrote:
| 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)
| BeetleB wrote:
| > 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/
| radarsat1 wrote:
| > 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 wrote:
| > 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 wrote:
| It's ironic how org mode is the tool of choice for computer
| geeks, yet the code quality is so poor
| throwawayflambe wrote:
| As someone immersed in the emacs project for the last several
| years, I can say with some authority the org enthusiasts are
| by and large non-programmers by trade. I can also say the
| earlier half of org code is quite good, but the latter half
| is quite bad, a direct reflection of the deterioration in
| personnel quality.
| _a_a_a_ wrote:
| 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.
| JoeyBananas wrote:
| 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.
| CalChris wrote:
| 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 wrote:
| 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 wrote:
| The bindings of emacs are the least impressive part while
| extensibility, pervasive documentation, and uniformity
| everywhere are the best.
| fdr wrote:
| > 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 wrote:
| > > 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.
| ParetoOptimal wrote:
| 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.
| NoGravitas wrote:
| 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.
| iscream26 wrote:
| > 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.
| ttepasse wrote:
| In a way Lisp and S-Expressions would are tailor-made to define
| an abstract UI structure like JSX, SwiftUI and such, which then
| gets rendered into concrete UI widgets or a TUI. Something like
| defining a common editor layout this: (def-
| frame (vertical-split ( (horizontal-split (
| (scrollview (tree-list)) (scrollview (editor-
| buffer))) (mode-line) (minibuffer))))
|
| Plus the actual data with a reactive flow, of course. And, yes,
| not a Lisp programmer. I hope I put enough parentheses there.
| cmrdporcupine wrote:
| 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
| sureglymop wrote:
| I really like this blogs ui! I think it was made with hugo.
| entropie wrote:
| 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.
| terracottalite wrote:
| Sadly, it seems it is just hugo. He mentions hugo in a
| post[1].
|
| [1]: https://andreyor.st/posts/2020-06-05-managing-
| background-pro...
| BeetleB wrote:
| 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-...
| jrockway wrote:
| 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.)
| fhd2 wrote:
| 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.
| jpmattia wrote:
| > _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 wrote:
| I'd imagine the average age of emacs users is younger than
| emacs itself at this point.
| cmrdporcupine wrote:
| 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
| MatthiasPortzel wrote:
| 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 wrote:
| Are you referring to scroll-restore[1], by any chance?
|
| [1]: http://elpa.gnu.org/packages/scroll-restore.html
| MatthiasPortzel wrote:
| Yes. If I remember correctly, selecting a region with the
| mouse would cause it to error and only resume working when
| emacs was restarted.
| michaelcampbell wrote:
| > One of the last straws for me was that when scrolling down,
| the cursor moved to stay on the screen.
|
| I mean, to each their own, but saying this like it's bad is
| just baffling to me.
| taeric wrote:
| 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 wrote:
| 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?
| mcpackieh wrote:
| Implying a dichotomy between TUI and mouse scrolling is very
| strange to me. I use my mouse to scroll in TUIs, including
| emacs, all the time. Emacs has full mouse support and
| scarcely discourages it's use.
| MatthiasPortzel wrote:
| 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.
| rgoulter wrote:
| > 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.
| akira2501 wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-11 23:02 UTC)