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 console and pasting it back into the console.
> The extra newline breaks it.
This bit me in the ass a lot of times and this patch seems to fix it
according to my quick testing. Thanks!
A few comments below.
> Similiarly, changes behavior when trimming whitespace from the end of a
> physical line to only do so if the line does not wrap. Otherwise we are
> trimming whitespace from the middle of a logical line, which may change
> its meaning.
> ---
> st.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/st.c b/st.c
> index 497885b..1c34258 100644
> --- a/st.c
> +++ b/st.c
> @@ -662,6 +662,9 @@ y2row(int y) {
> static int tlinelen(int y) {
> int i = term.col;
>
> + 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.
> + return i;
> +
> while (i > 0 && term.line[y][i - 1].c[0] == ' ')
> --i;
>
> @@ -959,7 +962,7 @@ getsel(void) {
> * st.
> * FIXME: Fix the computer world.
> */
> - if(sel.ne.y > y || lastx >= linelen)
> + if((y < sel.ne.y || lastx >= linelen) && !(last->mode &
> ATTR_WRAP))
Why did you change the order in the first clause? Not that I mind too
much, just curious.
> *ptr++ = '\n';
> }
> *ptr = 0;
> --
> 1.9.1
>
>
