9 ms·

I posted a link here to a Reddit post that said “if you could change one thing about emacs what would it be?” It had almost 200 comments. Some answers definitel

I posted a link here to a Reddit post that said “if you could change one thing about emacs what would it be?” It had almost 200 comments. Some answers definitely touched on these points. But for the most part, what Emacs users wanted was for the Gnu Emacs maintainers to do was… 1. Switch out Elisp for a Common Lisp or Scheme 2. Update the way Emacs Ui Core so it used standard GTK or something better. (The current implementation uses a lot of ugly hacks to support a subset of GTK) 3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off. 4. Improve threading so that things like TRAMP didn’t freeze when you were connecting 5. Fast/Arbitrary graphics support I think for most Emacs users it’s a performance thing. Though the improvements to the GUI code would go a long way to making it easier to make Emacs be more user friendly. In terms of this article. I think all of this is possible in a separate distribution of Emacs right now. Emacs will never turn on most of these things by default. But maybe if a version of Emacs that makes these changes becomes wildly popular, the current maintainers would be more amenable to it. https://old.reddit.com/r/emacs/comments/padv22/if_you_could_change_one_thing_about_emacs_what/ https://old.reddit.com/r/emacs/comments/padv22/if_you_could_...

clircle 5y ago
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!
Finnucane 5y ago
Yes, if you ask people who know how to use emacs what they would change, the answer is going to be very different from the answer you’d get asking people who have tried to use emacs and gave up. The documentation does really suck. The terminology makes no sense to users not used to it. It does not explain that to make this into a functional system, some configuration needs to be done. It is terrible out-of-the-box. ‘Because this is how rms did it 45 years ago’ is not really a good excuse.
- Abhinav2000 5y ago
  The documentation does _not_ suck. It it literally the most well documented software in existence, a reason for which it has been used for many different things outside its original purpose of text editing. Yes, it may not be for everyone. But just say that, that it uses certain conventions that are likely outdated for a reasonable set of the population. But you can't say the documentation sucks when you have the below: https://www.gnu.org/software/emacs/manual/html_node/emacs/index.html https://www.gnu.org/software/emacs/manual/html_node/emacs/in... https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html https://www.gnu.org/software/emacs/manual/html_node/elisp/in...
  - cge 5y ago
    That documentation is thorough does not mean that it is good. If anything, one might argue that Emacs documentation being so extensive while buing built around idiosyncratic conventions makes it worse, not better, for many cases: it means it is even harder for people to actually find relevant parts of the documentation.
    - otabdeveloper4 5y ago
      Emacs itself is idiosyncractic. Being cute and using "standard" terminology would just confuse users.
      - Avamander 5y ago
        This must be the funniest way to justify archaic terminology I've seen so far.
guessbest 5y ago
I've seen all these before and it makes me wonder why someone doesn't just make a different version of emacsen like guile-emacs. There must be a lot of inertia behind emacs and substantial amount of development effort to make all these changes that keeps competitors to gnu emacs from progressing to replace it.
- slightwinder 5y ago
  Because of GNU Emacs biggest strenght, which is also it's biggest flaw: the mountains of existing code. Any new emacs must support what emacs already offers. And this means not just to be able to run the code, but to also support the huge amount of special and exotic features that Emacs offers. Guile-emacs for example has a pretty long history on fighting emacs-strings and it's special features. There is the general believe that users don't wanna change from emacs away and any new emacs should be ~100% compatible to old emacs. But history has shown, people will not settle with inferiour clones. So many work will be neccessary, whatever someone will build to replace emacs.
slightwinder 5y ago
Be aware that this are comments from people who use emacs. It does'nt mean that implementing these wishes will also lead to more users coming to emacs. Even the low hanging fruits from the article are barely something that will bring in new users. Though, distributions like spacemacs and doom-emacs have shown that they are bait working well to get new users. Investing more in that directions should pay out to some degree.
pjmlp 5y ago
For me Emacs was only something I used when I couldn't have access to XEmacs, which was the best workaround for the lack of IDEs in 1990's UNIX. Nowadays I just use IDEs.
908B64B197 5y ago
> 3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off. https://ftp.gnu.org/old-gnu/Manuals/emacs-20.7/html_chapter/emacs_12.html https://ftp.gnu.org/old-gnu/Manuals/emacs-20.7/html_chapter/... > 4. Improve threading so that things like TRAMP didn’t freeze when you were connecting You really want this, as well as the low level functions to support TRAMP to be written in C. https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview
- rusk 5y ago
  > 3. Ability to scroll without bringing point You could probably do this with a transparent indirect buffer with a special “scroll only” mode that reverts once you start typing again.
  - vvillena 5y ago
    Well, yes, it's Emacs, we can probably do anything we can imagine, but that's beside the point. This particular behavior is stupidly annoying for both newbies and old-timers. Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.
    - rusk 5y ago
      > It's about time Emacs adopts the concept I find this kind of thinking interesting. Like Emacs is a bold child that needs to shape up … rather than a conintiually evolving codebase developed by enthusiasts. If it doesn’t do “this thing” it’s probably because it doesn’t need to. There’s probably better ways to do this that experienced users are comfortable with. For the newbies then you only need workarounds to make them comfortable, such as that which I described.
      - 5y ago
creamytaco 5y ago
I've been using Emacs for more than 20 years, these are all (for the most part) non-issues, brought up by folks who either are new to Emacs or never read the documentation / dived below the surface. 1. Emacs Lisp is great (for the problem domain), exists and works. Common Lisp could work but then given how close Emacs Lisp and CL are, there's no clear benefit, especially with Emacs getting native compilation. Scheme was proposed, some POC code written and failed because nobody was interested. It doesn't fit and fragmenting one of Emacs's greatest strengths (consistent ecosystem of working Emacs Lisp code) is a terrible idea. 2. The Emacs UI core is completely toolkit-agnostic. It doesn't use GTK on Windows. It doesn't use GTK on macOS. You can run _graphical_ Emacs without GTK or any toolkit whatsoever on Linux, and not lose any functionality. Therefore what you write makes no sense (ugly hacks to support a subset of GTK). 3. There are multiple ways to do this. Read up on setting the mark. 4. Threading has nothing to do with TRAMP freezing, bad configuration does. TRAMP documentation (does anyone that bring up these points ever read it?) has multiple sections on improving performance. Check "SSH control master" and "Improving performance of asynchronous remote processes". 5. SVG support is already there and more is on the pipeline. What I've noticed during my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out. Spoonfed knowledge is the order of the day, and the folks doing the spooning are usually not far from clueless themselves (the blind leading the blind). This leads to generational gaps and rapid propagation of erroneous ideas amidst the newbie masses, very similar to what you laid out. Emacs mastery requires commitment and time investment in order to understand (at least) the basic models and the trade-offs involved. If that doesn't take place, one can start going down paths that are entirely irrelevant ("Emacs needs threads so that it doesn't freeze!", "Let's use JavaScript so we can do non-blocking IO!", "Let's rewrite Emacs in Rust!")
- CJefferson 5y ago
  2. What you wrote makes no sense. If linking to gtk provides nothing at all, why is the code even there? 3. Why is the default config for TRAMP so bad? It isn't spoonfeeding for everyone to not want to reconfigure it.

clircle 5y ago

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!

Finnucane 5y ago

Yes, if you ask people who know how to use emacs what they would change, the answer is going to be very different from the answer you’d get asking people who have tried to use emacs and gave up. The documentation does really suck. The terminology makes no sense to users not used to it. It does not explain that to make this into a functional system, some configuration needs to be done. It is terrible out-of-the-box. ‘Because this is how rms did it 45 years ago’ is not really a good excuse.

Abhinav2000 5y ago
The documentation does _not_ suck. It it literally the most well documented software in existence, a reason for which it has been used for many different things outside its original purpose of text editing. Yes, it may not be for everyone. But just say that, that it uses certain conventions that are likely outdated for a reasonable set of the population. But you can't say the documentation sucks when you have the below: https://www.gnu.org/software/emacs/manual/html_node/emacs/index.html https://www.gnu.org/software/emacs/manual/html_node/emacs/in... https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html https://www.gnu.org/software/emacs/manual/html_node/elisp/in...
- cge 5y ago
  That documentation is thorough does not mean that it is good. If anything, one might argue that Emacs documentation being so extensive while buing built around idiosyncratic conventions makes it worse, not better, for many cases: it means it is even harder for people to actually find relevant parts of the documentation.
  - otabdeveloper4 5y ago
    Emacs itself is idiosyncractic. Being cute and using "standard" terminology would just confuse users.
    - Avamander 5y ago
      This must be the funniest way to justify archaic terminology I've seen so far.

guessbest 5y ago

I've seen all these before and it makes me wonder why someone doesn't just make a different version of emacsen like guile-emacs. There must be a lot of inertia behind emacs and substantial amount of development effort to make all these changes that keeps competitors to gnu emacs from progressing to replace it.

slightwinder 5y ago
Because of GNU Emacs biggest strenght, which is also it's biggest flaw: the mountains of existing code. Any new emacs must support what emacs already offers. And this means not just to be able to run the code, but to also support the huge amount of special and exotic features that Emacs offers. Guile-emacs for example has a pretty long history on fighting emacs-strings and it's special features. There is the general believe that users don't wanna change from emacs away and any new emacs should be ~100% compatible to old emacs. But history has shown, people will not settle with inferiour clones. So many work will be neccessary, whatever someone will build to replace emacs.

slightwinder 5y ago

Be aware that this are comments from people who use emacs. It does'nt mean that implementing these wishes will also lead to more users coming to emacs. Even the low hanging fruits from the article are barely something that will bring in new users. Though, distributions like spacemacs and doom-emacs have shown that they are bait working well to get new users. Investing more in that directions should pay out to some degree.

pjmlp 5y ago

For me Emacs was only something I used when I couldn't have access to XEmacs, which was the best workaround for the lack of IDEs in 1990's UNIX. Nowadays I just use IDEs.

908B64B197 5y ago

> 3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off. https://ftp.gnu.org/old-gnu/Manuals/emacs-20.7/html_chapter/emacs_12.html https://ftp.gnu.org/old-gnu/Manuals/emacs-20.7/html_chapter/... > 4. Improve threading so that things like TRAMP didn’t freeze when you were connecting You really want this, as well as the low level functions to support TRAMP to be written in C. https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview

rusk 5y ago
> 3. Ability to scroll without bringing point You could probably do this with a transparent indirect buffer with a special “scroll only” mode that reverts once you start typing again.
- vvillena 5y ago
  Well, yes, it's Emacs, we can probably do anything we can imagine, but that's beside the point. This particular behavior is stupidly annoying for both newbies and old-timers. Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.
  - rusk 5y ago
    > It's about time Emacs adopts the concept I find this kind of thinking interesting. Like Emacs is a bold child that needs to shape up … rather than a conintiually evolving codebase developed by enthusiasts. If it doesn’t do “this thing” it’s probably because it doesn’t need to. There’s probably better ways to do this that experienced users are comfortable with. For the newbies then you only need workarounds to make them comfortable, such as that which I described.
    - 5y ago

creamytaco 5y ago

I've been using Emacs for more than 20 years, these are all (for the most part) non-issues, brought up by folks who either are new to Emacs or never read the documentation / dived below the surface. 1. Emacs Lisp is great (for the problem domain), exists and works. Common Lisp could work but then given how close Emacs Lisp and CL are, there's no clear benefit, especially with Emacs getting native compilation. Scheme was proposed, some POC code written and failed because nobody was interested. It doesn't fit and fragmenting one of Emacs's greatest strengths (consistent ecosystem of working Emacs Lisp code) is a terrible idea. 2. The Emacs UI core is completely toolkit-agnostic. It doesn't use GTK on Windows. It doesn't use GTK on macOS. You can run _graphical_ Emacs without GTK or any toolkit whatsoever on Linux, and not lose any functionality. Therefore what you write makes no sense (ugly hacks to support a subset of GTK). 3. There are multiple ways to do this. Read up on setting the mark. 4. Threading has nothing to do with TRAMP freezing, bad configuration does. TRAMP documentation (does anyone that bring up these points ever read it?) has multiple sections on improving performance. Check "SSH control master" and "Improving performance of asynchronous remote processes". 5. SVG support is already there and more is on the pipeline. What I've noticed during my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out. Spoonfed knowledge is the order of the day, and the folks doing the spooning are usually not far from clueless themselves (the blind leading the blind). This leads to generational gaps and rapid propagation of erroneous ideas amidst the newbie masses, very similar to what you laid out. Emacs mastery requires commitment and time investment in order to understand (at least) the basic models and the trade-offs involved. If that doesn't take place, one can start going down paths that are entirely irrelevant ("Emacs needs threads so that it doesn't freeze!", "Let's use JavaScript so we can do non-blocking IO!", "Let's rewrite Emacs in Rust!")

CJefferson 5y ago
2. What you wrote makes no sense. If linking to gtk provides nothing at all, why is the code even there? 3. Why is the default config for TRAMP so bad? It isn't spoonfeeding for everyone to not want to reconfigure it.