Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I like the idea of cleaning up legacy cruft. I'm not crazy about the way this project is going about it. My main issues:

* ignoring C best practices:

    /* prefix macros, please */
    #define MIN(a, b)  ((a) < (b) ? (a) : (b))
* barely any comments

    /* ME: ...so it parses a string? Doesn't pretty
     * much every parser? Also, no prefix again. */
    void
    strparse(void) {
* Lack of overall project structure. Maybe some comments here would clear things up, but even some groupings like this would be nice:

    /*************************
     * X11 CALLBACKS GO HERE
     *************************/
* No tests. I think reasonable people can disagree about how testing should happen, but I'm a hard sell if you tell me your code needs absolutely no automated testing. If a new dev wants to commit a patch, how does she know her code works?

* Here's a scenario broached by the README:

    One  goal  of  st is to only support what is really
    needed. When you encounter a sequence which you
    really need, implement it.
...my problem is that there are no instructions here nor comments in the code about how start doing that ('see commit X in the repo' would even work). Again, I would hope that a dev-oriented tool like this (editing config.mk is in the installation instructions) would be a bit more friendly to developers who are stepping into the project for the first time.

My concern is that the code might suck less than xterm (I'm not familiar with that code-base), but I'm not sure "less cruft" is a good enough reason for me to want to get involved with (or even use) a project. Of course, I'm willing for the people of suckless.org to prove me wrong in my assessment.



strparse makes sense if you read the code linearly, since they also have csiparse, and deal with STREscape and CSIEscape, respectively. If you did need to add an escape sequence, it would take less than a minute to find where to add it.

While I wouldn't call it a paragon of clarity, it basically follows the same style and organization as older Unix tools. In such cases, I find starting from main() and jumping around with ctags a useful strategy (after reading the globals and type definitions).

Oh, and I strongly agree about tests. Especially escape sequence parsing could benefit from fuzzing or other property-based testing approaches.


  ...it basically follows the same style and organization
  as older Unix tools. In such cases, I find starting from
  main() and jumping around with ctags a useful strategy
 (after reading the globals and type definitions).
Oh, I know it's the same style and organization as older Unix tools. And it's the same style and organization as large one-off perl scripts. It would be a shame to replace old cruft with new stuff that doesn't the leverage lessons learned in software engineering over the last 40 years or so.


Yeah, agreed, the code is somewhat gross (also, everything is global!) and the people working on it have poor taste in coding style.

I forked it awhile back, this is the terminal I use now:

http://evilpiepirate.org/git/st.git/




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

Search: