Hacker News new | past | comments | ask | show | jobs | submit login

pure-gtk doesn't decouple ui process from editor, if that's what you're asking about.



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?


Sorry, I just don't understand. I don't really use terminals except to do a system update. Is there a specific issue?


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.


FYI There /is/ `frame-resize-pixelwise` and `window-resize-pixelwise`, to help with a few of those issues.


It also doesn’t offer smooth scrolling on macOS except in a third party port.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: