3 ms·

The C side of Emacs is pretty bad, and his description makes it sound worse, but honestly I've never seen Emacs flicker or draw white boxes at any time in my li

by db48x 10y ago

The C side of Emacs is pretty bad, and his description makes it sound worse, but honestly I've never seen Emacs flicker or draw white boxes at any time in my life.

quotemstr 10y ago
I wouldn't call it "bad". Is it different from most modern programs? Certainly. But it does a lot of clever things well. A program that I use every day can't be all bad.
- db48x 10y ago
  Bad as in hard to read, update, and maintain. It certainly achieves useful results! Congratulations on managing such a large change. BTW, I just double-checked, and I can indeed make it flicker when resizing the window as you mention in emacs-devel. I guess I've just never noticed since I never resize anything (maximized windows or nothing).
- xenobioticants 10y ago
  I think he meant bad as in this: http://geoff.greer.fm/vim/ http://geoff.greer.fm/vim/. 400 lines of code to wait for keyboard input.. sweet Jesus. Thankfully Neovim exists now. Granted, that's a VIM example, but I can't imagine Emacs being much better in terms of code.
  - quotemstr 10y ago
    FWIW, I've hacked a little bit on bash, and IMHO, Emacs internals are _much_ cleaner than bash's.
  - pdkl95 10y ago
    > 400 lines of code to wait for keyboard input.. sweet Jesus. That function isn't particularly bad. It's a little messy, but it's reasonable for legacy portable code. >> This function is over 400 lines and contains over 40 #ifdefs. This is a low-level function that is supposed to handle different platforms, so this is the function where platform-specific #ifdefs should be collected. It's mostly a giant case/switch style #ifdef wrapper around a list of platforms and features. >> Vim tries to be compatible with every OS, including dead ones such as BeOS, VMS, and Amiga. That isn't a bad thing. Unless there is an actual[1] problem with the legacy platform support, then it should be left in for the people that do use the "dead" OS. > Features that drastically change behavior are enabled/disabled with preprocessor flags. Yes, that's the point of those flags. This is to enable/disable major features like XCLIPBOARD support which isn't going to compile on non-X11 platforms, or for debug and other unusual features that shouldn't be included in standard builds. > Cross-platform libraries like libuv didn’t exist when Vim was created. Sure. Which is why this function exists. Also, libuv is nice, but it isn't a replacement for all of the features (like XCLIPBOARD) this function provides. Even if most of the function was replaced with a libuv port, some of the #ifdefs would still be necessary. [1] "It's old" doesn't count.

by db48x 10y ago

The C side of Emacs is pretty bad, and his description makes it sound worse, but honestly I've never seen Emacs flicker or draw white boxes at any time in my life.

quotemstr 10y ago

I wouldn't call it "bad". Is it different from most modern programs? Certainly. But it does a lot of clever things well. A program that I use every day can't be all bad.

db48x 10y ago
Bad as in hard to read, update, and maintain. It certainly achieves useful results! Congratulations on managing such a large change. BTW, I just double-checked, and I can indeed make it flicker when resizing the window as you mention in emacs-devel. I guess I've just never noticed since I never resize anything (maximized windows or nothing).
xenobioticants 10y ago
I think he meant bad as in this: http://geoff.greer.fm/vim/ http://geoff.greer.fm/vim/. 400 lines of code to wait for keyboard input.. sweet Jesus. Thankfully Neovim exists now. Granted, that's a VIM example, but I can't imagine Emacs being much better in terms of code.
- quotemstr 10y ago
  FWIW, I've hacked a little bit on bash, and IMHO, Emacs internals are _much_ cleaner than bash's.
- pdkl95 10y ago
  > 400 lines of code to wait for keyboard input.. sweet Jesus. That function isn't particularly bad. It's a little messy, but it's reasonable for legacy portable code. >> This function is over 400 lines and contains over 40 #ifdefs. This is a low-level function that is supposed to handle different platforms, so this is the function where platform-specific #ifdefs should be collected. It's mostly a giant case/switch style #ifdef wrapper around a list of platforms and features. >> Vim tries to be compatible with every OS, including dead ones such as BeOS, VMS, and Amiga. That isn't a bad thing. Unless there is an actual[1] problem with the legacy platform support, then it should be left in for the people that do use the "dead" OS. > Features that drastically change behavior are enabled/disabled with preprocessor flags. Yes, that's the point of those flags. This is to enable/disable major features like XCLIPBOARD support which isn't going to compile on non-X11 platforms, or for debug and other unusual features that shouldn't be included in standard builds. > Cross-platform libraries like libuv didn’t exist when Vim was created. Sure. Which is why this function exists. Also, libuv is nice, but it isn't a replacement for all of the features (like XCLIPBOARD) this function provides. Even if most of the function was replaced with a libuv port, some of the #ifdefs would still be necessary. [1] "It's old" doesn't count.