On Thu, Oct 02, 2014 at 04:47:48PM +0200, q...@c9x.me wrote: > On Wed, Oct 01, 2014 at 04:03:34PM -0700, Eric Pruitt wrote: > > I'm considering making a sic fork called "nssic" or "not so simple irc > > client" and integrating libreadline or libedit. > > My post points to an existing project that is too close > to what you describe to be ignored. Why writing one more > client? Just strip the multichan thing and you get what > you want.
Most of the sic code would remain unchanged if I were to integrate libreadline directly to eliminate the output munging problem. The only reason for forking sic is because I'm sure my patches would not be accepted. That being said, there's no point in using something "close" to what I want when I can have exactly what I want without much work. After all, there are plenty of IRC clients out there yet you chose to make another. Pretty much every single curses IRC client out there has a superset of your client's features. Furthermore, no, it's not close in that I actually _like_ the output style of sic including the all-channels-one-stream feature. At one point, I was working on a program called "REPLplex" that multiplexed various REPL's into a single terminal and functioned much like sic. My input problems have been mostly solved with srw (Ctrl+Y doesn't paste, but the rlwrap author intends to implement the feature I requested, so I'll eventually have _all_ the readline-goodness again), I always use tmux or screen, so I don't need a curses-implemented scrollback buffer, and if I used your client, I would also lose my syntax highlighting and the ability to format or restrict the displayed output of sic in general while simultaneously being able to to log everything by sticking in tee(1) before the filtering and formatting part of the pipeline. Also, your emacs/readline-esque bindings also missing Ctrl+Y to paste which I use quite often; in that way, your program falls even further from what I want. Eric
