txr-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Txr-users] matching blank lines


From: Daniel Lyons
Subject: Re: [Txr-users] matching blank lines
Date: Wed, 24 Feb 2010 15:15:49 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Feb 24, 2010 at 11:52:58AM -0800, Kaz Kylheku wrote:
> > Thanks for txr! This is an immensely helpful program and I'm looking forward
> > to using it in all sorts of situations where awk/sed/etc. are
> > unpleasant.
> 
> This program sucks now, but I have some ideas about improving it. :)

I think it has a lot of potential. I am always looking for new
utilities for processing text. I often have to convert data from
obscure formats to CSV and general purpose languages often make it
wordier than it has to be. Conversely, using sed and awk often
produces unmaintainable code overly dependent on the shell for extra
help. Txr isn't perfect but it does do a good job of straddling these
two domains. Plus, with my Prolog background, I appreciate the
unification-like behavior and the function semantics.

> I see that you are trying to collect the code/price pairs like
> A and 47.50 using a freeform collect.
> 
> Unfortunately, in investigating this problem, I've found
> that freeform is buggy. :(
> 
> It looks like you might be expecting @(freeform "\n\n") to stop
> when it sees two newlines, but in fact "\n\n" simply means
> that the character sequence "\n\n" will separate the lines
> when they are considered to be a big virtual string.

I guess I'm having trouble visualizing the difference. The two sound
almost the same to me.

> The @(coll) will keep going over the entire virtual line,
> gathering all matching inputs, skipping over nonmatching
> stuff.
> 
> To terminate on two newlines, you can add an @(until)
> like this:
> 
> @(freeform)
> @(coll) ... <your collect logic>..... @(until)@address@hidden@(end)
> 
> Problem is, that due to bugs in the implementation
> of @(freeform) this won't work; there are multiple issues
> with the logic that reverts the unmatched tail of
> the virtual string back to a list of lines, so that continued
> outer collect over multiple records doesn't work.
> 
> One small fix (commit 68e5c54c9fc4f1ac27a1f4e8ad787feb4868c19c)
>  is already in GIT---that's not it, though!

So, the method you're describing will _eventually_ work? Is this how
you'd approach the problem with txr?

-- 
Daniel
http://www.storytotell.org -- Tell It!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]