I didn't know about libvitapi. I'll check it.
About line editors: COME ON.
About compatibility/portability: I want the library to work for me. I don't
care about anyone else. So it's gonna be compatible with xterm and st. Not even
urxvt!
I don't know if it has to be graphical or text.
What do y
On 2014-01-31 01:47, Lee Fallat wrote:
I say line editors are most suitable because they can be used with
anything that supports displaying 2 or even 1 line, and doesn't need
to be stuck to old terminal technology.
[…]
who answers his own question (because of the compatibility
complexity), it i
Didn't know you had a hate for line editors. Or me. At least line
editors don't waste people's time.
I say line editors are most suitable because they can be used with
anything that supports displaying 2 or even 1 line, and doesn't need
to be stuck to old terminal technology.
Additionally, as FRI
Lee Fallat dixit:
>editor. I think some can guess where I'm coming from...
Message-ID:
^^
Not hard to guess. Go die. Elsewhere. And quiet.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine
> Writing TUI's is a PITA, let alone a new TUI-library, because there are
> so many kinds of terminals around to support.
> It certainly would require chewing a lot of manuals on this topic to
> get something which "works almost everywhere".
Sometimes the best solution is don't think about the por
Hey,
Before requesting something, I suggest you do a quick search to see if
such things already exist. Just a couple alternatives:
http://tasktools.org/projects/libvitapi.html
https://code.google.com/p/termbox/
Personally I think TUI is useless in this day and age. Even the most
unsupported opera
On Fri, 31 Jan 2014 01:35:46 +0200
Dimitris Zervas wrote:
> Shouldn't we create a new TUI library?
Writing TUI's is a PITA, let alone a new TUI-library, because there are
so many kinds of terminals around to support.
It certainly would require chewing a lot of manuals on this topic to
get somet
Hello,
I was just thinking about my beloved vim. It's old. It's big. It (kind of)
sucks. It's not suckless.
So I just gave a scan to project ideas and sandy. You use (n)curses and I
thought that it's as old, big, sucky and non-suckless as vim is.
Shouldn't we create a new TUI library?
A
On Thu, Jan 30, 2014 at 01:14:41PM -0800, Bobby Powers wrote:
> Hi,
>
> sin wrote:
> > Please pull again from tip. It should work now.
>
> Almost. It compiles after applying the attached patch.
Ok, fixed in tip.
On Thu, Jan 30, 2014 at 01:14:41PM -0800, Bobby Powers wrote:
> Hi,
>
> sin wrote:
> > Please pull again from tip. It should work now.
>
> Almost. It compiles after applying the attached patch.
Yeah I should have included util.h from those files to
automatically get util.h
Hi,
sin wrote:
> Please pull again from tip. It should work now.
Almost. It compiles after applying the attached patch.
yours,
Bobby
0001-util-undef-strl-cat-cpy-in-their-.c-files.patch
Description: Binary data
On Thu, Jan 30, 2014 at 09:38:23AM -0800, Bobby Powers wrote:
> Hello,
>
> sin wrote:
> > This is in preparation to moving tar(1) over to recurse()
> > instead of ftw().
>
> On MacOS 10.9, strlcat and strncat are defined as macros, and adding
> them to sbase breaks the builds. I'm not sure what
On Thu, Jan 30, 2014 at 09:01:59PM +0100, Szabolcs Nagy wrote:
> * Bobby Powers [2014-01-30 09:38:23 -0800]:
> > On MacOS 10.9, strlcat and strncat are defined as macros, and adding
> > them to sbase breaks the builds. I'm not sure what the easy/nice
> > solution is. Error is below.
>
> all sta
Christoph Lohmann <2...@r-36.net> wrote:
> Both of your patches have been applied. Thank you for sending them!
I'm glad to see all those patches applied upstream. It was
an exciting week for surf.
Regards
Y.
On Thu, Jan 30, 2014 at 08:39:44PM +0100, Christoph Lohmann wrote:
> Sincerely,
>
> Christoph Lohmann
OT: I'm not sure if this is intentional, but your In-Reply-To: and
References: headers are broken and breaking threading, at least on my
copy of Mutt.
Eric
* Bobby Powers [2014-01-30 09:38:23 -0800]:
> On MacOS 10.9, strlcat and strncat are defined as macros, and adding
> them to sbase breaks the builds. I'm not sure what the easy/nice
> solution is. Error is below.
all standard interfaces may be also defined as macros
so this is nothing special (
Greetings.
On Thu, 30 Jan 2014 20:39:44 +0100 Quentin Rameau wrote:
> Sorry, patches in previous mail were wrong, here are the good ones.
>
> On Wed, Jan 29, 2014 at 2:14 PM, Quentin Rameau wrote:
> > Hi, another version of the patches, with a command line option added.
> > I'll have a look on
Greetings.
On Thu, 30 Jan 2014 19:40:21 +0100 Steve Dee wrote:
> soup_message_get_flags returns a bunch of flags besides
> SOUP_MESSAGE_CERTIFICATE_TRUSTED, so the XOR check was incorrect.
>
> While I was tracking this bug, I switched from libsoup's deprecated [0]
> ssl-ca-file to its non-deprec
Hey Christoph,
On 1/30/14, Christoph Lohmann <2...@r-36.net> wrote:
> They look useful. Could you add them to the wiki? [0]
>
Done :)
--Carlos
Greetings.
On Thu, 30 Jan 2014 19:25:59 +0100 Carlos Torres wrote:
> Hello,
> I've written two tools which i'm using to bind my mouse thumb
> buttons ctrl+h and ctrl+l i use those with surf.
>
>[1] xbmouse simple binds either a ButtonPress or ButtonRelease of a
> Button (by number) to a co
Greetings.
On Thu, 30 Jan 2014 19:30:14 +0100 Carlos Torres wrote:
> Hello,
> Here is a simple patch that allows make LAYOUT=de or en or arrows
> it looks like it was meant to work that way but got overlooked.
Thank you. Your patch has been applied.
Sincerely,
Christoph Lohmann
Hello,
Here is a simple patch that allows make LAYOUT=de or en or arrows
it looks like it was meant to work that way but got overlooked.
--Carlos
allow_make_layout.patch
Description: Binary data
On Thu, Jan 30, 2014 at 09:38:23AM -0800, Bobby Powers wrote:
> Hello,
>
> sin wrote:
> > This is in preparation to moving tar(1) over to recurse()
> > instead of ftw().
>
> On MacOS 10.9, strlcat and strncat are defined as macros, and adding
> them to sbase breaks the builds. I'm not sure what
Hello,
I've written two tools which i'm using to bind my mouse thumb
buttons ctrl+h and ctrl+l i use those with surf.
[1] xbmouse simple binds either a ButtonPress or ButtonRelease of a
Button (by number) to a command
[2] xkev generates simple key events with optional modifiers
(shift,cont
On Thu, Jan 30, 2014 at 09:38:23AM -0800, Bobby Powers wrote:
> Hello,
>
> sin wrote:
> > This is in preparation to moving tar(1) over to recurse()
> > instead of ftw().
>
> On MacOS 10.9, strlcat and strncat are defined as macros, and adding
> them to sbase breaks the builds. I'm not sure what
Hello,
sin wrote:
> This is in preparation to moving tar(1) over to recurse()
> instead of ftw().
On MacOS 10.9, strlcat and strncat are defined as macros, and adding
them to sbase breaks the builds. I'm not sure what the easy/nice
solution is. Error is below.
yours
Bobby
CC util/afgets
On Thu, Jan 30, 2014 at 03:48:33PM +, Nick wrote:
> On Thu, Jan 30, 2014 at 03:35:25PM +, sin wrote:
> > I think this is probably the best course of action
> > at this point.
> > ...
> > Support for character and block devices is optional in POSIX.
> > We cannot guarantee that this will wor
On Thu, Jan 30, 2014 at 04:07:28PM +, Nick wrote:
> On Thu, Jan 30, 2014 at 04:00:10PM +, sin wrote:
> > Which means that on a system that doesn't have those macros, it will
> > ignore char/blk devices.
> >
> > I am inclined to keep the warning messages there for those cases.
>
> Is it li
On Thu, Jan 30, 2014 at 04:49:25PM +0100, Roberto E. Vargas Caballero wrote:
> PD: sin, your work with sbase is incredible
I quite agree, thanks so much sin!
On Thu, Jan 30, 2014 at 04:00:10PM +, sin wrote:
> Which means that on a system that doesn't have those macros, it will
> ignore char/blk devices.
>
> I am inclined to keep the warning messages there for those cases.
Is it likely that there are there any systems that don't have those
macros,
On Thu, Jan 30, 2014 at 03:48:33PM +, Nick wrote:
> On Thu, Jan 30, 2014 at 03:35:25PM +, sin wrote:
> > I think this is probably the best course of action
> > at this point.
> > ...
> > Support for character and block devices is optional in POSIX.
> > We cannot guarantee that this will wor
> I'm not sure I agree. We shouldn't be tethered to POSIX if it means
> losing useful functionality for no practical reason. Are there any
> systems out there that don't have support for character and block
> devices? Haiku isn't a compelling argument to me. In any case, I
> prefer the #ifdef solut
On Thu, Jan 30, 2014 at 03:35:25PM +, sin wrote:
> I think this is probably the best course of action
> at this point.
> ...
> Support for character and block devices is optional in POSIX.
> We cannot guarantee that this will work correctly and it is not
> portable, so just drop support for it
Hi,
I think this is probably the best course of action
at this point.
I'll also need to move stat(1) to ubase as it is using
major() and minor().
bye,
sin
>From c3fdef5b71fa9f78ae9322d270428eb60584528d Mon Sep 17 00:00:00 2001
From: sin
Date: Thu, 30 Jan 2014 14:51:21 +
Subject: [PATCH] Com
* Christoph Lohmann 2014-01-30 15:17
> About the modestring: The modestring is a given institution and
> won’t be extended. If more than the alphabet is needed, something is re‐
> ally going wrong in the web.
really really? how could that come!
> Any comments?
Regarding cookies: Vanil
On Thu, Jan 30, 2014 at 02:58:53PM +0100, Christoph Lohmann wrote:
> Such a file should be easily managable using scripts. Match the given
> domain name, surf would use and modify the given modestring. If no host‐
> name was found, add it’s raw value. Users should modify or shorten this
> on he
Greetings.
On Thu, 30 Jan 2014 14:58:53 +0100 Quentin Rameau wrote:
> Sorry, patches in previous mail were wrong, here are the good ones.
>
> On Wed, Jan 29, 2014 at 2:14 PM, Quentin Rameau wrote:
> > Hi, another version of the patches, with a command line option added.
> > I'll have a look on
Hi,
This is in preparation to moving tar(1) over to recurse()
instead of ftw().
The caller of recurse() doesn't need to prepare a full path
manually anymore.
cheers,
sin
>From 0697ac3a64dca3f4a3857784f1e1a15dd82827ee Mon Sep 17 00:00:00 2001
From: sin
Date: Thu, 30 Jan 2014 12:37:35 +
Subje
38 matches
Mail list logo
