[dev] [PATCH] Fixed copying empty lines inside selection.

The code was assuming that empty lines have implicit wrap-around attribute. --- st.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/st.c b/st.c index 6424b54..506be0f 100644 --- a/st.c +++ b/st.c @@ -949,7 +949,7 @@ getsel(void) { * st. * FIXM

Re: [dev] [st] Blank lines not preserved

2014-05-21 22:40 GMT+04:00 Eric Pruitt : > When copying text from st, all intermittent blank lines get removed. For > example, if I run "printf 'XXX\n\n\nXXX\n'" then copy and paste the > printed text, I get: > > XXX > XXX > > Instead the expected: > > XXX > > > XXX This is most a

Re: [dev] [st] Blank lines not preserved

2014-05-22 23:52 GMT+04:00 Roberto E. Vargas Caballero : >> I'm curious what non-st terminal emulator you use. On Urxvt, my all >> colors beyond #16 look the same as in Xterm without any changes to my >> Xresources file or the need to recompile Urxvt. Likewise for MinTTY and >> its parent PuTTY. Yo

Re: [dev] [st] [PATCH] Refactor xsetcolorname()

2014-05-25 14:23 GMT+04:00 FRIGN : > Hello, > > attached is a small patch to refactor xsetcolorname(). > Note the high similarity to xloadcols(). I wonder how necessary it is > to realloc if name==NULL, given dc.col[] is only read except in > xloadcols(), where exactly the same stuff is done to eac

Re: [dev] [st] Colors slightly different hue than in xterm

2014-05-22 1:57 GMT+04:00 Roberto E. Vargas Caballero : >> Read this: http://www.4p8.com/eric.brasseur/gamma.html >> >> We need to generally re-think the algorithm used here. I hate the idea >> of being conformant to this or that terminal emulator and instead >> prefer an implementation according t

Re: [dev] [surf] WebKit1 deprecated

YpN wrote: > If I'm not wrong, surf only works with WBK1 API. Do we need to stick > with <2.4? Heyho YpN, You can use http://surf.suckless.org/patches/smoothscrolling-via-GTK3 --Markus

[dev] [surf] WebKit1 deprecated

Hi, I plan to use surf as my primary browser and few weeks ago I decided to compile WebKitGTK 2.4.0. After that release, WebKit1 won't be included[1] in the tarballs. Actually, I like to compile the last WebKitGTK release for my favourite browsers. Could you tell me if it changes something for us?

Re: [dev] [st] Backspace broken?

Quoth Roberto E. Vargas Caballero on Sun, May 25 2014 08:36 +0200: You should read [0]. If you want get a correct behaviour you have to put this line into your profile: stty erase  Ah, sorry, I should have re-read that (very informative) thread. This makes perfect sense. -- Wolfgang

Re: [dev] [GENERAL] License manifest

And I'm yet to study unlicense but from the first look it appears to be the sort of legal mutant I doubt would get internal legal clearance. On the other hand, some bigger commercial product do use SQLite, but they do offer licenses too. Sticking to the MIT License is more prudent for the tim

Re: [dev] [GENERAL] License manifest

Dnia 15 maja 2014 17:44 Charlie Murphy napisał(a): > In the United States, if you say "my code has no license" it will be > the same as if you said "I reserve all rights to my code". Exactly, most countries are signatories to Berne Convention.

Re: [dev] [GENERAL] License manifest

Dnia 25 maja 2014 16:06 Aaron Burrow napisał(a): > On Fri, May 23, 2014 at 6:39 PM, Jakub Lach wrote: > > Dnia 23 maja 2014 23:18 Anders Andersson napisał(a): > > > >> > On Thu, May 22, 2014 at 6:36 PM, Nick wrote: > >> > The ISC license[0] is simpler still, and in much nicer English, > >> > w

Re: [dev] [GENERAL] License manifest

On Fri, May 23, 2014 at 6:39 PM, Jakub Lach wrote: > Dnia 23 maja 2014 23:18 Anders Andersson napisał(a): > >> > On Thu, May 22, 2014 at 6:36 PM, Nick wrote: >> > The ISC license[0] is simpler still, and in much nicer English, >> > which I like. But MIT/X is perfectly fine too for our purposes h

Re: [dev] [st] [PATCH] Refactor xsetcolorname()

On Sun, 25 May 2014 12:38:05 +0200 FRIGN wrote: > Well, I just found out I was partially wrong: Just to make it clear: It doesn't invalidate the patch in any way. It was just a false assumption over the nature of the function. -- FRIGN

Re: [dev] [st] [PATCH] Refactor xsetcolorname()

On Sun, 25 May 2014 12:23:43 +0200 FRIGN wrote: > If I'm wrong, let me know. If not, we could skip the entire if(! > name)-part. Well, I just found out I was partially wrong: With echo -e '\e]104\a' and echo -e '\e]104;1\a' you can reset certain colors to their initial values, but it just hasn't

[dev] [st] [PATCH] Refactor xsetcolorname()

Hello, attached is a small patch to refactor xsetcolorname(). Note the high similarity to xloadcols(). I wonder how necessary it is to realloc if name==NULL, given dc.col[] is only read except in xloadcols(), where exactly the same stuff is done to each array-item as repeated in xsetcolorname().