4 ms·

Hopefully pure-gtk branch will be merged prior to Emacs 28, addressing (2). On (1), I'm not much of a programmer, but Emacs-lisp fine, so I'm not sure what ben

Hopefully pure-gtk branch will be merged prior to Emacs 28, addressing (2). On (1), I'm not much of a programmer, but Emacs-lisp fine, so I'm not sure what benefit changing languages could bring.

slightwinder 5y ago
Is the pure-gtk-branch really working on switching the underlying UI-architecture? Or just removing the hacks for X11 and moving them to gtk?
- clircle 5y ago
  pure-gtk doesn't decouple ui process from editor, if that's what you're asking about.
  - slightwinder 5y ago
    No, I mean emacs was designed for terminals. The whole GUI is build ontop of this and is suffering from it. Is pure-gtk changing this and decouple from the terminal-design or still working with it, replicating the same hacks just in a different GUI?
    - clircle 5y ago
      Sorry, I just don't understand. I don't really use terminals except to do a system update. Is there a specific issue?
      - slightwinder 5y ago
        Terminals work with characters, meaning, lines, columns, fontsize. GUIs usually are working with pixel, meaning x/y-coordinates and free sizes. In case of emacs this means there is a bunch of hacks to translate pixel-coordinates to line/column-coordinates. This often are working well enouhg, but sometimes not. For example, with my emacs there is always a free space at the bottom when maximising the window, Resizing the window also works in terms of lines, not pixels. Positioning of completion-dialogs is linked to chars, not the pixel-coordinates of a the word which in certain cases get's ugly. It's overall not what I would call a hard issue, but still ugly. But it also kinda limits what you could do with Emacs in GUI-world. As Emacs has no understanding of z-axis, there are overlapping widgets and free-positioning of elements outside the text-flow. An additionally, it seems the too many laysers and additional complexity has some speed-impact in GUIs which the terminal-version has not.
        jolux 5y ago
        It also doesn’t offer smooth scrolling on macOS except in a third party port.
        acdw 5y ago
        FYI There /is/ `frame-resize-pixelwise` and `window-resize-pixelwise`, to help with a few of those issues.
b3morales 5y ago
There are a good number of Emacs users who also use a Lisp dialect such as Scheme for their day-to-day work. Emacs Lisp has enough small, slightly strange differences from more mainstream Lisps that I can imagine that being kind of frustrating. For myself I think that Emacs Lisp is a pretty good language for configuring a text editor. A lot of its warts actually make it easy to use in that context, in my opinion. Personally I wouldn't mind moving closer to Scheme or CL. Though I wouldn't want to lose "special" variables (with dynamic binding) no matter what happens -- they're a key tool in tweaking behavior to get it just how you want. But for people who are trying to build packages, especially large ones on the order of Org or Magit, I can see having a more, let's say production code oriented language, being a nice prospect.
- User23 5y ago
  Emacs Lisp now arguably has a better type inferencing compiler than SBCL[1]. [1] http://akrl.sdf.org/gccemacs.html#orge596749 http://akrl.sdf.org/gccemacs.html#orge596749
chriswarbo 5y ago
Would this pure-gtk branch avoid GTK's famous X11 connection bug? https://gitlab.gnome.org/GNOME/gtk/-/issues/221 https://gitlab.gnome.org/GNOME/gtk/-/issues/221 Every few years I'm tempted to try the GTK version of Emacs, but it doesn't take long before this bites me and I go back to Lucid!

Hopefully pure-gtk branch will be merged prior to Emacs 28, addressing (2). On (1), I'm not much of a programmer, but Emacs-lisp fine, so I'm not sure what benefit changing languages could bring.

slightwinder 5y ago

Is the pure-gtk-branch really working on switching the underlying UI-architecture? Or just removing the hacks for X11 and moving them to gtk?

clircle 5y ago
pure-gtk doesn't decouple ui process from editor, if that's what you're asking about.
- slightwinder 5y ago
  No, I mean emacs was designed for terminals. The whole GUI is build ontop of this and is suffering from it. Is pure-gtk changing this and decouple from the terminal-design or still working with it, replicating the same hacks just in a different GUI?
  - clircle 5y ago
    Sorry, I just don't understand. I don't really use terminals except to do a system update. Is there a specific issue?
    - slightwinder 5y ago
      Terminals work with characters, meaning, lines, columns, fontsize. GUIs usually are working with pixel, meaning x/y-coordinates and free sizes. In case of emacs this means there is a bunch of hacks to translate pixel-coordinates to line/column-coordinates. This often are working well enouhg, but sometimes not. For example, with my emacs there is always a free space at the bottom when maximising the window, Resizing the window also works in terms of lines, not pixels. Positioning of completion-dialogs is linked to chars, not the pixel-coordinates of a the word which in certain cases get's ugly. It's overall not what I would call a hard issue, but still ugly. But it also kinda limits what you could do with Emacs in GUI-world. As Emacs has no understanding of z-axis, there are overlapping widgets and free-positioning of elements outside the text-flow. An additionally, it seems the too many laysers and additional complexity has some speed-impact in GUIs which the terminal-version has not.
      - jolux 5y ago
        It also doesn’t offer smooth scrolling on macOS except in a third party port.
      - acdw 5y ago
        FYI There /is/ `frame-resize-pixelwise` and `window-resize-pixelwise`, to help with a few of those issues.

b3morales 5y ago

There are a good number of Emacs users who also use a Lisp dialect such as Scheme for their day-to-day work. Emacs Lisp has enough small, slightly strange differences from more mainstream Lisps that I can imagine that being kind of frustrating. For myself I think that Emacs Lisp is a pretty good language for configuring a text editor. A lot of its warts actually make it easy to use in that context, in my opinion. Personally I wouldn't mind moving closer to Scheme or CL. Though I wouldn't want to lose "special" variables (with dynamic binding) no matter what happens -- they're a key tool in tweaking behavior to get it just how you want. But for people who are trying to build packages, especially large ones on the order of Org or Magit, I can see having a more, let's say production code oriented language, being a nice prospect.

User23 5y ago
Emacs Lisp now arguably has a better type inferencing compiler than SBCL[1]. [1] http://akrl.sdf.org/gccemacs.html#orge596749 http://akrl.sdf.org/gccemacs.html#orge596749

chriswarbo 5y ago

Would this pure-gtk branch avoid GTK's famous X11 connection bug? https://gitlab.gnome.org/GNOME/gtk/-/issues/221 https://gitlab.gnome.org/GNOME/gtk/-/issues/221 Every few years I'm tempted to try the GTK version of Emacs, but it doesn't take long before this bites me and I go back to Lucid!