2013/2/25 Roberto E. Vargas Caballero <k...@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.
0001-Replacing-linefeeds-with-returns-in-ttywrite.patch
Description: Binary data
