>except one tiny thing: the background color of the text in Vim would not
>fill in anything that wasn't a character. In Vim I have it set to a gray
>and my term is black. Any ideas to properly fix this instead of changing
>my term color? I would try and fix this myself but I have no
On Sun, Jan 06, 2013 at 09:43:49PM +0400, p37si...@lavabit.com wrote:
> This patch "fixes" it for me. Don't know how to fix it correctly yet.
Please take a look to this message in the list:
http://lists.suckless.org/dev/1212/13848.html
Maybe we should add the information in the FAQ.
Hello,
Using the latest st from the git repository, I decided to see how well Vim
and st would play together. After messing around a bit I see that
everything works properly (I was impressed mouse scrolling still worked),
except one tiny thing: the background color of the text in Vim would not
fil
This patch "fixes" it for me. Don't know how to fix it correctly yet.
141,142c141,142
< { XK_KP_Delete, XK_ANY_MOD, "\033[P", -1,0,0},
< { XK_KP_Delete, XK_ANY_MOD, "\033[3~", +1,0,0},
---
> /*{ XK_KP_Delete, XK_ANY_MOD, "\033[P",
On Sun, Jan 06, 2013 at 04:39:57PM +0100, ilf wrote:
> For me, in st (current git) the Pos1 and Del keys don't work in an
> interactive zsh. End and Backspace work though.
>
> In bash, Pos1 works, but Del doesn't.
>
> In vim, everything works.
>
> Can anyone reproduce this? Any hint on how to de
On Sun, Jan 06, 2013 at 04:39:57PM +0100, ilf wrote:
> For me, in st (current git) the Pos1 and Del keys don't work in an
> interactive zsh. End and Backspace work though.
>
> In bash, Pos1 works, but Del doesn't.
>
> In vim, everything works.
>
> Can anyone reproduce this? Any hint on how to de
For me, in st (current git) the Pos1 and Del keys don't work in an
interactive zsh. End and Backspace work though.
In bash, Pos1 works, but Del doesn't.
In vim, everything works.
Can anyone reproduce this? Any hint on how to debug/fix?
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole
On 01/06/2013 05:51 AM, Christoph Lohmann wrote:
Does freetype appear in the ldd(1) output? Does it appear when you leave
out ‐lfreetype?
Yes, even without -lfreetype. I think one of the other shared libraries
is pulling it in.
I renamed my libfreetype.a to libfreetype.a.bak and the bloati
On 06/01/2013, pancake wrote:
> Didnt checked, but i guess that ls -s show size in bytes and du in block
> bytes, which depends on filesystem.
Nope. Both show size in blocks [1].
It seems proper to do so in ls alone, with a flag of whether to add
sizes of all files below; thus we could drop du.
Greetings.
On Sun, 06 Jan 2013 14:51:43 +0100 Charlie Kester wrote:
> Interesting. I get much a much bigger executable with the latest git.
>
> So I dug a little deeper and the problem seems to occur when pkg-config
> adds -lfreetype to the linker flags.
>
> Omitting that linker flag gets me
Didnt checked, but i guess that ls -s show size in bytes and du in block bytes,
which depends on filesystem.
ls -s : file size
du : disk used
On Jan 6, 2013, at 13:02, markus schnalke wrote:
> [2013-01-05 18:55] Christoph Lohmann <2...@r-36.net>
>>
>>% ls -hs st-0.3/st
>>126K st
>
>
This patch fix ctrl+pgup in mc.
st-fix_ctrl+pgup.patch
Description: Binary data
[2013-01-05 18:55] Christoph Lohmann <2...@r-36.net>
>
> % ls -hs st-0.3/st
> 126K st
I wondered why 20h did not use `du -h st-0.3/st' instead.
Then I wondered why ls(1) has `-s' at all.
Even in 1st Edition Unix, ls(1) has `-s' although du(1) is available.
http://man.cat-v.o
13 matches
Mail list logo
