adding line hints when building blocks
[1/8] from: ammon::rcslv::com at: 22-May-2002 16:29
Hi,
Just a shot in the dark (I am still not sure what you are attempting, an
example maybe?) Have you tried placing the word 'newline in where you wanted
a new line? and I think that there is a similar one for tab IIRC.
HTH
Ammon
A short time ago, Gregg Irwin, sent an email stating:
[2/8] from: greggirwin:mindspring at: 21-May-2002 11:55
Hi Gang,
If you build a block interactively in the console, with newlines between
items, or if you blockify a string with embedded newlines, the block
contains line "hints" which are used when the block is printed, molded, etc.
Suppose I want to build a block in code, which will be written to a file,
and I want it to be formatted nicely in the file (i.e. with newlines and
indentation). Is there any way to include formatting hints when building a
block, or do you have to build a string and blockify it?
I know RT has mentioned that it's less efficient to build a string if you
want to DO it, but I haven't found a way to format a block as I build it.
Thanks!
--Gregg
[3/8] from: greggirwin:mindspring at: 24-May-2002 16:58
hi Ammon,
<< Just a shot in the dark (I am still not sure what you are attempting, an
example maybe?) Have you tried placing the word 'newline in where you
wanted
a new line? and I think that there is a similar one for tab IIRC. >>
Yup. Tried various combinations of things, reducing, composing, etc. but no
luck so far.
The goal is to write out, to a file, something like this:
item-1-id [
value 0
mail [foo--bar--com]
]
item-2-id [
value 1
mail [foo--baz--com]
]
which is an easy format to create and edit manually, and also very easy to
just LOAD for use in scripts. The format you get without line hints is much
harder to work with manually. E.g.
item-1-id [value 0 mail [foo--bar--com]] item-2-id [value 1 mail [foo--baz--com]]
item-3-id [value 1 mail [foo--baz--com]] item-4-id [value 1 mail [foo--baz--com]]
item-5-id [value 1 mail [foo--baz--com]]
The new serialized format will be fine for apps you don't want to edit
manually, and for REBOL developers, but for the average joe
(script-tinkerer, help-desk personnel), I think the native block format
might be much better.
--Gregg
[4/8] from: brett:codeconscious at: 25-May-2002 11:03
Hi Gregg,
>From memory I think the only way to add a line hint is by loading a string.
>> block-with-line-hint: load {[^/]}
== [
]
You can insert this block into another.
>> test-block: copy []
== []
>> insert/only test-block block-with-line-hint
== []
>> test-block
== [[
]]
But as far as I can tell as soon as this block is evaluated - it loses it's
hint.
I think the only feasible alternative is to form a string with the line hint
and indentation you need.
And I'd really like a pretty formatter for scripts too. Clean script is good
but I don't
want to have to add line breaks at beginings of blocks.
If I remember, Joel created style-x something
that mangled comments, but might be enough for just data blocks.
Brett.
[5/8] from: carl:cybercraft at: 25-May-2002 16:55
Hi Gregg,
I've got close to what you want by using a "do string" to create a
template for your files. This at least means you only have to do a
string once. ie...
---8<---
rebol []
template: do "[^/none[^/value none^/mail none^/]^/]"
file: []
insert file copy/deep template
file/1: 'item-1
file/2/2: 1
file/2/4: [foo--bar--com]
insert file copy/deep template
file/1: 'item-2
file/2/2: 2
file/2/4: [foo--baz--com]
insert file copy/deep template
file/1: 'item-3
file/2/2: 3
file/2/4: [foo--bat--com]
sort/skip file 2 ; (;
print mold file
---8<---
This gives...
>> do %test.r
[item-1 [
value 1
mail [foo--bar--com]
] item-2 [
value 2
mail [foo--baz--com]
] item-3 [
value 3
mail [foo--bat--com]
]]
It's not quite perfect as line-hints for the item values are lost when
you change them, ((because they're in the outer block, perhaps?), but
the others are kept so it's almost how you wanted it. This is how
the file would look with no values changed...
>> blk: [] loop 3 [insert blk copy/deep template] print mold blk
[
none [
value none
mail none
]
none [
value none
mail none
]
none [
value none
mail none
]]
So close. Grrr! (: Hope that gets you some way to where you want,
anyway.
Carl.
On 25-May-02, Gregg Irwin wrote:
> hi Ammon,
> << Just a shot in the dark (I am still not sure what you are
<<quoted lines omitted: 23>>
> format might be much better.
> --Gregg
--
Carl Read
[6/8] from: ingo:2b1 at: 25-May-2002 8:03
Hi Gregg,
Gregg Irwin wrote:
> hi Ammon,
> << Just a shot in the dark (I am still not sure what you are attempting, an
<<quoted lines omitted: 12>>
> mail [foo--baz--com]
> ]
I guess writing a pretty printer is your only chance, maybe something
like this will do:
a: [item-1-id [value 0 mail [foo--bar--com]] item-2-id [value 1 mail
[foo--baz--com]]]
parse a [
some [
set id word! (print [id "["])
into [
some [
set name word!
set val any-type!
(print [ " " name val ])
]
(print "]")
]
]
]
which gives
item-1-id [
value 0
mail [foo--bar--com]
]
item-2-id [
value 1
mail [foo--baz--com]
]
I hope that helps,
Ingo
[7/8] from: ingo::2b1::de at: 25-May-2002 14:33
Re: adding line hints when building blocks - P.S.:
Hi Gregg,
seems I have to add a little background info on my last post, at least
_I_ would have had trouble to understand what I meant, hadn't it been
written by me ...
> Gregg Irwin wrote:
> Suppose I want to build a block in code, which will be written to a
> file, and I want it to be formatted nicely in the file (i.e. with
> newlines and indentation). Is there any way to include formatting
> hints when building a block, or do you have to build a string and
> blockify it?
Well, that what I would do:
create a block, however it looks, and stringify it on save (use a pretty
printer, e.g. the one in my previous post) to create a pretty printed
output.
Kind regards,
Ingo
[8/8] from: greggirwin:mindspring at: 25-May-2002 12:45
Thanks Ingo and Carl,
It looks like we can get pretty close, and get all the way there by
stringifying the block, but no simple solution. I think, as a general
solution, the pretty printer approach could work really well. More overhead,
but that would only be an issue for large files or high throughput systems.
Thanks again!
--Gregg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted