This has also gotten too much for me . I hereby unsubscribe. Officially.
On Wed, Aug 19, 2009 at 4:40 PM, Nils wrote:
> You guys make me wanna unsubscribe, too. ;)
>
>
On Thu, Aug 20, 2009 at 03:48:46PM +0200, Dieter Plaetinck wrote:
> What are you missing?
> I think cookie_daemon.py is pretty nice (it's in uzbl mainline git).
> It uses pythons cookie lib for correct cookie handling and it uses a socket
> for fast communication.
> If you want "policies" or white
On Wed, Aug 19, 2009 at 09:42:56AM -0500, Kurt H Maier wrote:
>
> This message, including any attachments, contains confidential
> information intended for a specific individual and purpose, and is
> protected by The Word of God. If you are not the intended recipient,
> please close your eyes -now
I'm not actually facing a very specific problem. (Well, I am,
but it's easy to solve without a parser.) I just have seen many
situations where such parser could be usefull. I'll try some
examples.
(1) You have a programming language you want to write a compiler
for. You write a grammar for it. To
On Thu, Aug 20, 2009 at 1:37 PM, Kurt H Maier wrote:
> On Thu, Aug 20, 2009 at 3:43 AM, David Tweed wrote:
[snipped]
> No matter how hard you try, I'm not going to turn this into a pissing
> match. Just keep in mind you're not the only one in the world -- or
> even on this list -- who turns out m
Can you expose a practical example of this? Maybe taking use cases as
design roots we can catch a better idea of how to implement this or
how to solve the problem you are facing.
--pancake
Maurício wrote:
(2/2 - I believe these messages didn't went to
the list. Sorry if they actually did.)
(.
(2/2 - I believe these messages didn't went to
the list. Sorry if they actually did.)
(...) If you had such "shell yacc", how would you like it to be
or behave?
(...) So the important thing is being able to whip something up
quickly; this isn't parser "specs" that's going to be carefully
deve
(1/2 - I believe these messages didn't went to
the list. Sorry if they actually did.)
I've always been a fan of using the unix text input and output
to connect simple tools to achieve complex results, but I think
there's a missing piece in the tool set: parsers.
There are *many* ways you coul
On Thu, 20 Aug 2009 08:11:27 +
Jacob Todd wrote:
> I could never get vimpression to compile. I've been using uzbl for a
> while now and have never had problems with it, the only thing it's
> really missing for me is good cookie support.
>
What are you missing?
I think cookie_daemon.py is pr
On Thu, Aug 20, 2009 at 3:43 AM, David Tweed wrote:
> I'm comparing the viewpoint that you're going to whip up one-off
> parsers by piping in inputs and patterns and piping out output versus
> a setup where you assemble the input into a file, quite probably using
> piping, and then run on that. IMO
On Wed, Aug 19, 2009 at 02:06:05PM +0200, pancake wrote:
> if you add jk to move up/down, i would prefer hl to move left/right and
> H/L for history.
>
That makes sense. I'll try it.
On Wed, Aug 19, 2009 at 03:36:00PM +0200, Valentin wrote:
> It almost sounds like you want vimpression [1] ;)
>
On Wed, Aug 19, 2009 at 6:18 PM, Kurt H Maier wrote:
> On Wed, Aug 19, 2009 at 11:49 AM, David Tweed wrote:
>> what would be most effective in tracking
>> down the inevitable problems when there's a bug in the user input
>> and/or mismatched input, particularly if it happens in the middle of a
>> p
12 matches
Mail list logo