On Sun, Aug 24, 2014 at 07:37:14PM -0400, Nick wrote:
> I don't have time to test it yet. Will it also work for text within
> programs like dvtm / screen, or is that too much to ask as they
> don't expose the necessary line wrapping information to st?
It works fine with tmux and screen.
Eric
Quoth Ben Hendrickson:
> When getting selected text, lines that were wrapped because of length
> ought not include the wrapping newline in the selection.
Cool, this is a very useful fix, thanks.
I don't have time to test it yet. Will it also work for text within
programs like dvtm / screen, or i
> Good point. What is protocol here? Should I send a v2 patch without the space?
Don't worry, I will apply the commit and fix the space. Usually
the protocol is send a second version, but I think is too much
for a space,
Regards,
--
Roberto E. Vargas Caballero
On Fri, Aug 22, 2014 at 12:54:55PM -0700, Ben Hendrickson wrote:
> On Fri, Aug 22, 2014 at 12:00 PM, Silvan Jegen wrote:
> >> + if (term.line[y][i - 1].mode & ATTR_WRAP)
> >
> > The preferred style in st.c seems to be the one without a space
> > after the 'if'. There still are about 18 other p
On Fri, Aug 22, 2014 at 12:00 PM, Silvan Jegen wrote:
>> + if (term.line[y][i - 1].mode & ATTR_WRAP)
>
> The preferred style in st.c seems to be the one without a space
> after the 'if'. There still are about 18 other places where this
> convention is broken however.
Good point. What is proto
Hi
On Fri, Aug 22, 2014 at 09:25:04AM -0700, Ben Hendrickson wrote:
> When getting selected text, lines that were wrapped because of length
> ought not include the wrapping newline in the selection.
>
> This comes up, for example, when copying a bash command that is long
> enough to wrap from the
When getting selected text, lines that were wrapped because of length
ought not include the wrapping newline in the selection.
This comes up, for example, when copying a bash command that is long
enough to wrap from the console and pasting it back into the console.
The extra newline breaks it.
Si
