If you are all such experts, why don't you "fix it" and then pull request it in.
There it is right there.
Vim's 400 line function to wait for keyboard input
41–50 of 239 posts
Re: Vim's 400 line function to wait for keyboard input
#42But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.
I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html From the article: "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive…
It doesn't acquire bugs just by sitting around on your hard drive.
Except when sometimes it does. That is, external factors reveal old bugs or introduce new ones. Like when you use it after installing a new package/driver/OS and it blows up. Or after years you give it to a new crazy user which somehow succeeds it hitting 20 keys at a time and your code doesn't handle that. I'm not saying occasions like those require a complete rewrite, just that it's not because code has been fine for 10years that it is bugfree and needs no more work ever. (though in cases like this switching to a proven lib for handling key input if such a thing even exist might be a solution - which then introduces new problems like more dependencies and bugs in that lib making your own software not working properly and so on and so on:)
Re: Vim's 400 line function to wait for keyboard input
#43But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.
"There is nothing to be gained." Not completely true, you could argue that it would be more maintainable in the future but I don't think that outweigh the risk of making changes here while it's still fully functional and nothing really needs it to change.
Yes, maintainability / extensibility is good. But I'd be wary of refactoring code purely for the sake of potential maintainability / extensibility, as it's work for no gain. You're trying to predict the future for the code, and that's a losing game.
If someone has a reason to extend the code, then you have the choice of hacking in the new feature, or refactoring the code to make it nicer. Each case really needs to be considered on its merits. But IMO it's almost always better to prefer to keep the code as-is rather than making big rewrites. Tiny refactoring is the way to go.
Re: Vim's 400 line function to wait for keyboard input
#44First glance at the headline had me wondering, "Is this a good thing?"
Re: Vim's 400 line function to wait for keyboard input
#45But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.
In that best result you also end up with code that is smaller and easier to extend in the future. Considering that Vim is still extremely common that is a win.
Re: Vim's 400 line function to wait for keyboard input
#46ncurse is similar with a lot of legacy code to support old terminals.
Re: Vim's 400 line function to wait for keyboard input
#47Do one thing and do it well
Re: Vim's 400 line function to wait for keyboard input
#48But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.
I made the page as a companion piece to a blog post[1]. The code works, but it's quite buggy. Also, it is almost certainly broken on outdated OSes. It's just that nobody uses the latest Vim on IRIX or VMS, so no bug reports get filed.
A quick glance shows some obvious errors in RealWaitForChar(). For example: with typical preprocessor defines, it uses gettimeofday() in a select() loop. This will break if the system clock changes, either from user intervention or ntpd. The correct solution is to use a monotonically-increasing timer, such as Linux's clock_gettime() or OS X’s mach_absolute_time().
Vim's UI is powerful, but its codebase is a nightmare. My blog post explains why in more detail.
1. http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...
Re: Vim's 400 line function to wait for keyboard input
#49If you are all such experts, why don't you "fix it" and then pull request it in.
Please, you can critique something even if you lack the skills to fix it, or the desire to fix it, or the time to fix it.
Also, you can point out that something is broken even if you have no suggestions on how to fix it.
Re: Vim's 400 line function to wait for keyboard input
#50But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.
I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html From the article: "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive…
Absolutely. As a vim user, one of my favorite things about it is how it is on virtually every platform -- it's similar to what the article says about Netscape. Is the code pretty? Probably not. But I would rather have my text editor be compatible with any OS I may need to use it on than it have a readable codebase.