Re: [dev] [st] strange behaviour with nano

From: Alexander Sedov <alex0player_AT_gmail.com>
Date: Mon, 25 Feb 2013 22:42:13 +0400

2013/2/25 Roberto E. Vargas Caballero <k0ga_AT_shike2.com>

> On Mon, Feb 25, 2013 at 04:44:11AM +0400, Alexander Sedov wrote:
> > Commenting on this even further:
> > - tested whether st rightfully extracts selection contents. It does,
> as
> > debug output told me, so the problem is in nano.
>
> Usually we try don't add code for fixing bugs in others programs. If you
> find such case, then it is more logical you send the patch to the bugsy
> application, in this case alpine.
>
You meant nano :P. Well, we are pasting text using keyboard emulation
(writing to fd). Keyboard sends \n, not \r. So it makes total sense.

> > Conclusion: as it is unheard of an application which can't handle
> carriage
> > returns, but some buggy applications cannot handle linefeeds well due
> to
> > mysterious and arcane reasons, and because workaround costs three
> lines of
> > code, I would propose this patch to be applied to upstream.
>
> + char *p;
> + for(p = memchr(s, '\n', n); p != NULL; p = memchr(p, '\n', s + n -
> p))
> + *p = '\r';
>
> I would prefer something like:
>
>
> char *p = s, *q = s + n;
>
> while(p = memchr(p, '\n', q - p))
> *p = '\r';
>
q is kinda superfluous (or maybe call it char *end then?). But yeah,
'while' is better.
Also, I discovered that ttywrite is passed const char *, so it's invalid to
modify contents.
So, a new patch.

Received on Mon Feb 25 2013 - 19:42:13 CET

This archive was generated by hypermail 2.3.0 : Mon Feb 25 2013 - 19:48:04 CET