Kai Hendry writes:
> https://github.com/kaihendry/sg-hackandtell/blob/master/Makefile
>
> For bonus points I have a plan9 mk version here:
> https://github.com/kaihendry/sg-hackandtell/blob/master/mkfile
>
> Enjoy and I would love to hear if it could suck less or if there are
> similar projects I
> In my own tests with dbe disabled in st and with dbe; there wasn’t much
> difference in speed on my Thinkpad. So my query is to ask you comrades
> to test st with dbe disabled and see if the missing speed difference is
> not just the four cores in my laptop.
Unfortunately my ARM netbook had
> but yeah, a part from that fossil is nice, but there's little userbase and
> i doubt there are transition tools to convert a repo from/to fossil. git
> is much more widespread.
http://fossil-scm.org/index.html/help/import
After the recent round of updates for st's keyboard functionality, the
ability to delete whole words in Readline with Alt-Backspace was
lost. In config.def.h, the entry for Backspace was changed from
XK_NO_MOD to XK_ANY_MOD. So, this is just a patch to change it back,
which restores the functionali
> This is a new path series that fix some problems related to the
> keyboard, and also add the key definitions that were missed in st.
I'm glad that you're thorough and you've put a lot of work into making
st robust, but how do these patches help us in 2012-soon-to-be-2013?
-brandon
> Which languages qualify as suckless?
Only Brainfuck. Anything more is superfluous.
> You're not saying that emacs sucks right?
No, I'm not.
I forgot to add that those escape sequences for Emacs will work fine in
less and man pages and such, since they are the same as hitting the up
and down arrow keys. The only difference is in programs with a cursor.
-brandon
Gentlemen,
Because, unfortunately, you sometimes have a mouse in your hand...
Here's a patch to add support for buttons 4 and 5 on your mouse (usually
the scroll wheel). Like the keyboard bindings in conf.def.h, you can
choose strings to write to the tty upon pressing these buttons (well,
upon sc
> I tried this and found that st version 386 actually does better, i.e.
> lower CPU usage, than urxvt.
To be honest, I hadn't yet tried it with urxvt. I just tried it now (on
the aforementioned quad-core x86_64) and I got:
term peak CPU %
--
st
> On 02.11.2012 20:12, Christoph Lohmann wrote:
>> * New drawing code, which is way more faster and comparable to the
>>other terminals out there.
>
> It totally is, and now im impressed. And a bit humbled, since i tried
> for some time for myself and failed ;)
It's still not perfect,
> Except that we need to learn how to use the tools thst exist instead if
> implementing our own. You shouldn't need programing ability for something
> like this
Every programming assignment you'll receive has already been written
many times over before. The point isn't to create something novel.
> I quickly overcame the assignment with:
>
> paste names.txt grades.txt
>
> My professor responded by saying "you are doing it the wrong way".
>
> It's preposterous to not use the tools given to us by unix gods.
You *were* doing it the wrong way. The assignment wasn't about the final
result, whic
> For those alternative charsets remapping some ranges of the symbols is
> required, which could be easily done using UTF=E2=80=908 characters.
But how exactly should this work? I tried naively just filling gfx[]
with the appropriate mappings (i.e. ['x'] =3D '|' (pretend that's the
unicode vertica
Line drawing seems to be broke using the latest tip of st. I've tried it
with the default config.def.h as well as using some other fonts but with
no luck. I tried changing the gfx[] array contents in config.def.h except
its use is rather opaque and I couldn't get anything to work.
Anyone else have
Crap, thanks for catching this. I just pushed it to default. Works
great, thanks again!
-brandon
Gaetan Bisson writes:
> Hi,
>
> The BORDER setting to st has recently been broken by the XDBE patch;
> this is fixed by the patch below, which also removes bufh/bufw since
> they are now redundant wi
FYI I've applied this patch to st's default branch (commit #245)
Enjoy,
-brandon
Brandon Invergo writes:
> Hi,
> As some background, I've been using st on an Arm device (Genesi Efika
> MX) which has relatively low specs compared to your average x86/amd64
> computer.
Bastien Dejean writes:
> Hi,
>
> I'm planning on writing a window manager with the following
> characteristics:
>
> - Windows are represented as the leaves of a binary tree.
You should look at herbstluftwm as it already imlements a binary tree
method for window management (manual tiling only).
On Sat, 2012-05-05 at 23:41 +0200, Aurélien Aptel wrote:
> Hi all,
>
> As I'm enrolled in Google Summer of Code until the end of summer,
> updates to st are unlikely. If someone is interested in working on it,
> ask Anselm for a write access to the repo.
Well, if no one else volunteers, I can tr
Sorry, I wasn't clear in my original message. I said that with the patch
it should be "apparently faster." What I meant is that seeing tearing or
flickering gives the impression of being slow. This patch gets rid of
that problem so it should at least appear faster.
That said, it *should* be actual
on it to try to improve further the speed if I
can.
Cheers,
Brandon Invergo
diff -r e1414acbe547 st.c
--- a/st.c Mon Feb 27 12:48:13 2012 +0100
+++ b/st.c Fri Apr 20 09:10:28 2012 +0200
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#if defined(__linux)
#include
@@ -178,7 +
20 matches
Mail list logo
