blogpost.py: empty line inserted into ListingBlock

34 views
Skip to first unread message

learnr

unread,
Jun 28, 2009, 2:33:09 PM6/28/09
to asciidoc
I am having problems uploading blogposts containing ListingBlocks -
namely at some point in the process an empty line gets inserted
between the lines surrounded by <pre> tags, and I am not able to
figure out why this is happening.

The blogpost.py output below suggests that the uploaded file does
contains the proper code, i.e. there are no line breaks, however once
the file has been uploaded there is an empty line after the first and
second line.

Could somebody confirm whether you experience the same problem, or
suggest a workaround to what seems to be a WordPress.com auto-
formatting issue!

Thanks.


1) blogpost_test.txt file used to create the output

blogpost_test
=============

----
First Line
Second Line
Other Line
----


2) blogpost.py output

executing: python26 c:\asciidoc_b\asciidoc.py --no-header-footer --
doct
ype article --backend wordpress --out-file - C:\blogpost_test
\blogpost_test.txt
<table border="0" bgcolor="#e8e8e8" width="100%"
cellpadding="10"><tr><td><pre>
First Line
Second Line
Other Line</pre>
</td></tr></table>
updating unpublished post 'blogpost_test'...

Stuart Rackham

unread,
Jun 29, 2009, 12:42:56 AM6/29/09
to asci...@googlegroups.com
learnr wrote:
> I am having problems uploading blogposts containing ListingBlocks -
> namely at some point in the process an empty line gets inserted
> between the lines surrounded by <pre> tags, and I am not able to
> figure out why this is happening.
>
> The blogpost.py output below suggests that the uploaded file does
> contains the proper code, i.e. there are no line breaks, however once
> the file has been uploaded there is an empty line after the first and
> second line.
>
> Could somebody confirm whether you experience the same problem, or
> suggest a workaround to what seems to be a WordPress.com auto-
> formatting issue!

This seems to be WordPress, caused by <td> padding and <pre> margins.
The solution is to explicitly set them in the listingblock template in
wordpress.conf file. I've added this to the trunk (and fixed other
similar blocks, for example sidebars):
http://hg.sharesource.org/asciidoc/rev/3f8045f30944

Things are rendered much better, here's the AsciiDoc User Guide:
http://srackham.wordpress.com/asciidoc-user-guide/

One potential problem with these hardwired styles is that stylesheets
(less specificity) cannot override them unless the use the CSS
!important directive.

For now the pragmatic approach wins (because it makes my blogs look
better), yell out if it interferes with yours.

Cheers, Stuart

learnr

unread,
Jun 29, 2009, 2:19:08 AM6/29/09
to asciidoc


On Jun 29, 8:42 am, Stuart Rackham <srack...@gmail.com> wrote:
> learnr wrote:
> > I am having problems uploading blogposts containing ListingBlocks -
> > namely at some point in the process an empty line gets inserted
> > between the lines surrounded by <pre> tags, and I am not able to
> > figure out why this is happening.
>
> > The blogpost.py output below suggests that the uploaded file does
> > contains the proper code, i.e. there are no line breaks, however once
> > the file has been uploaded there is an empty line after the first and
> > second line.
>
> > Could somebody confirm whether you experience the same problem, or
> > suggest a workaround to what seems to be a WordPress.com auto-
> > formatting issue!
>
> This seems to be WordPress, caused by <td> padding and <pre> margins.
> The solution is to explicitly set them in the listingblock template in
> wordpress.conf file. I've added this to the trunk (and fixed other
> similar blocks, for example sidebars):http://hg.sharesource.org/asciidoc/rev/3f8045f30944
>
> Things are rendered much better, here's the AsciiDoc User Guide:http://srackham.wordpress.com/asciidoc-user-guide/
>
> One potential problem with these hardwired styles is that stylesheets
> (less specificity) cannot override them unless the use the CSS
> !important directive.
>
> For now the pragmatic approach wins (because it makes my blogs look
> better), yell out if it interferes with yours.

Hmm, even after using these hardwired styles I still get the empty
lines.
http://learnr.wordpress.com/?p=867

Could this be caused by the Wordpress template in use?

Thanks.

Stuart Rackham

unread,
Jun 29, 2009, 3:56:28 AM6/29/09
to asci...@googlegroups.com
The above URL leads me to a blank page (page with header and sidebar but
no content).

Cheers, Stuart

learnr

unread,
Jun 29, 2009, 6:27:42 AM6/29/09
to asciidoc
Sorry, did not realise I would need to publish the post as well for it
to be accessible.

A new link with a published post, different host though.
http://blog.learnr.dreamhosters.com/?p=4

The second Listingblock has been edited manually to show the expected
result.

Stuart Rackham

unread,
Jun 29, 2009, 5:44:30 PM6/29/09
to asci...@googlegroups.com
Ah, now I see what you were talking about, I had assumed (and this is
what the patch I did fixed) that the problem was just the top and bottom
padding in the listing.

The problem is that there really are blank lines in your listing, it's
not a CSS problem. What puzzles me is why I don't get the same problem
(see http://srackham.wordpress.com/blogpost_test/)

Are the blank lines in the output when you generate the HTML from asciidoc?

asciidoc -s -b wordpress -o - blogpost_test.txt

Should generate:

<table border="0" bgcolor="#e8e8e8" width="100%" style="margin:0.2em 0;">
<tr><td style="padding:0.5em;">
<pre style="margin:0; padding:0;">First Line
Second Line
Other Line</pre>
</td></tr>
</table>

i.e. no blank lines.


Cheers, Stuart

Phillip Lord

unread,
Jun 30, 2009, 10:50:31 AM6/30/09
to asci...@googlegroups.com


Stuart

I've taken the liberty of writing another patch for blogpost which adds
a small amount of additional functionality; it can now read the blogpost
categories from the asciidoc file, specified as attributes in the file.
You specify the option (I picked -a for attributes!) on the command
line, and post, create or update and it all works.

The reason that this would be really nice is that I can now stick all my
blog posts in a directory and then use a very simple makefile (comparing
the asciidoc to the .blogpost file) to autopost any changed files.

This makes life easier when on the road; you don't have to remember what
you have posted and what not.

I'm afraid that I couldn't get your current version hg version working;
this is due to a problem in asciidocapi.py, which I couldn't figure out
(cause I am about off on holiday!). So this patch is against 0.9.1 with
the last patch I sent applied. Sorry for making your life harder; I
promise to learn mercurial before sending more patches!

Cheers

Phil


diff.attributes.txt

Phillip Lord

unread,
Jul 3, 2009, 6:12:04 AM7/3/09
to asci...@googlegroups.com

Stuart

Okay, last time, I promise. I've patched the last patch to allow
blogpost to read the status (published, unpublished) from the asciidoc
file also. This turns out to be the last piece that I needed for me
"post everything with make" plan.

The diff includes the last one; but is after the changes for "post".

I really will learn mercurial, when I get back from holiday!

Phil

diff.status.txt

Stuart Rackham

unread,
Jul 5, 2009, 7:10:55 PM7/5/09
to asci...@googlegroups.com
Hi Phillip

Thanks for the patches.
The categories and status information (along with all other blog
specific parameters) are in the corresponding .blogpost cache file so
putting them in the AsciiDoc source file is only useful when setting
them for the first time or changing them, which you currently do with
the --categories, --publish and --unpublish command options. So I can't
see any real benefit in repeating the same (blogpost specific)
information in the AsciiDoc source, or am I missing something here?

Cheers, Stuart
> ------------------------------------------------------------------------
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups "asciidoc" group.
>> To post to this group, send email to asci...@googlegroups.com
>> To unsubscribe from this group, send email to asciidoc+u...@googlegroups.com
>> For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
>> diff -r blogpost-0.9.1-patched-post/blogpost.py blogpost-0.9.1-patched/blogpost.py
>> 559a560,577
>>> def set_categories_from_blog_file(self):
>>> """
>>> Set categories from the categories attribute in blog file.
>>> """
>>> if not self.is_html():
>>> # asciidoc blog file.
>>> for line in open(self.blog_file):
>>> line.strip()
>>> match = re.match( r':categories: (.*)', line )
>>> if ( match ):
>>> ## set the catories, by faking the command line
>>> OPTIONS.categories = match.group( 1 )
>>> self.set_categories()
>>> return
>>> die('unable to find blog categories, as requested to in %s' %self.blog_file)
>>> else:
>>> die('unable to find blog categories in HTML, as requested for %s' %self.blog_file)
>>>
>> 676a695,697
>>> parser.add_option('-a', '--read-categories', action='store_true',
>>> dest='read_categories', default=False,
>>> help='Read categories as attribute from asciidoc file')
>> 717a739,743
>>> if OPTIONS.read_categories:
>>> if command not in ('create', 'update', 'categories', 'post'):
>>> parser.error('--read-categories is inappropriate')
>>> if not blog_file:
>>> parser.error('must specify blog file with --read-categories')
>> 795d820
>> <
>> 798d822
>> <
>> 802d825
>> <
>> 806,807d828
>> <
>> <
>> 809a831,832
>>> if OPTIONS.read_categories:
>>> blog.set_categories_from_blog_file()
>> diff -r blogpost-0.9.1-patched-post/doc/blogpost.1.txt blogpost-0.9.1-patched/doc/blogpost.1.txt
>> 126a127,134
>>> *-a, --read-categories
>>> Read the categories from the asciidoc file, set as the 'categories'
>>> attribute. Prefixing 'CATEGORIES' with a plus or minus character
>>> adds or removes the categories from an existing post. Category names
>>> are case insensitive. If an assigned category does not already exist
>>> it will be created.
>>> Applicable to 'categories', 'create, 'update' or 'post' commands.
>>>
>

Philli...@newcastle.ac.uk

unread,
Jul 6, 2009, 3:48:49 AM7/6/09
to asci...@googlegroups.com

If I am travelling, then I will write blogposts offline. When I get back
I'll have a number of files in my blog directory, some posted, some not.
By putting all the information the blog post file, when I get back I can
just use make (with a single command) to post anything that it outdated.

In a way, you can could ask the same thing about the title, which is
read from the asciidoc file; I would guess that this is also in the
.blogpost file.

Finally, I think that there is a big convienience issue. I can type the
categories in at the time that I am writing, not posting (which may be
very different) and, with the status and categories patch) I can judge by
looking at the asciidoc source how the post will be; I don't need the blog
online to know.

For me, it's a great convienience; I was going to write a tool over the
top of blogpost which uses it as a library to achieve the same end (which
is trivial to do). But having it in blogpost seems more sensible.

Your call, obviously. Either way works for me.

Phil

Stuart Rackham

unread,
Jul 9, 2009, 11:58:17 PM7/9/09
to asci...@googlegroups.com
Philli...@newcastle.ac.uk wrote:
>
> If I am travelling, then I will write blogposts offline. When I get back
> I'll have a number of files in my blog directory, some posted, some not.
> By putting all the information the blog post file, when I get back I can
> just use make (with a single command) to post anything that it outdated.
>
> In a way, you can could ask the same thing about the title, which is
> read from the asciidoc file; I would guess that this is also in the
> .blogpost file.

You are correct, but the title is always in the AsciiDoc file, is not
specific to blogpost and the syntax is not likely to change.

>
> Finally, I think that there is a big convienience issue. I can type the
> categories in at the time that I am writing, not posting (which may be
> very different) and, with the status and categories patch) I can judge by
> looking at the asciidoc source how the post will be; I don't need the blog
> online to know.
>
> For me, it's a great convienience; I was going to write a tool over the
> top of blogpost which uses it as a library to achieve the same end (which
> is trivial to do). But having it in blogpost seems more sensible.
>
> Your call, obviously. Either way works for me.

I can see that it would be convenient, but it pushes a blogpost related
coupling into Asciidoc. I think the place for blogpost specific
information is the .blogpost file not the AsciiDoc source. Here are some
random thoughts:

- If the .blogpost files were YAML instead of the pickled format they
could be easily edited alongside the AsciiDoc source files.

- Alternatively a --cache-only (--local ?) option that would update the
local .blogpost file but would suppress the upload.

- Or more simply, if the upload fails then continue and update the
.blogpost file (but not the created_at or updated_at fields) -- but this
doesn't give you the ability to hold back the upload.

What do you think?


Cheers, Stuart

Phillip Lord

unread,
Jul 20, 2009, 11:52:13 AM7/20/09
to asci...@googlegroups.com
Stuart Rackham <srac...@gmail.com> writes:

> Philli...@newcastle.ac.uk wrote:
>> In a way, you can could ask the same thing about the title, which is
>> read from the asciidoc file; I would guess that this is also in the
>> .blogpost file.
>
> You are correct, but the title is always in the AsciiDoc file, is not
> specific to blogpost and the syntax is not likely to change.

Sorry for delay! Been away.

I've reused a piece of asciidoc syntax (just added additional semantics)
to encode the status and categories of the blogpost; as far as I know,
there's no particular reason this syntax should change either.

It also has the virtue that if you want you can refer to the categories
in text (as they are asciidoc attributes). A small virtue, I guess, as I
can see no reason why you would want to do this:-)

>> Finally, I think that there is a big convienience issue. I can type the
>> categories in at the time that I am writing, not posting (which may be
>> very different) and, with the status and categories patch) I can judge by
>> looking at the asciidoc source how the post will be; I don't need the blog
>> online to know.
>>
>> For me, it's a great convienience; I was going to write a tool over the
>> top of blogpost which uses it as a library to achieve the same end (which
>> is trivial to do). But having it in blogpost seems more sensible.
>>
>> Your call, obviously. Either way works for me.
>
> I can see that it would be convenient, but it pushes a blogpost related
> coupling into Asciidoc.

In a sense, yes. It's still valid asciidoc syntax; if you asciidoc
(rather than blogpost) an article using this feature, then the just
disappear.

Also, my patch required use of a command-line option; so this coupling
is not required or even the default behaviour.

> I think the place for blogpost specific information is the .blogpost
> file not the AsciiDoc source. Here are some random thoughts:
>
> - If the .blogpost files were YAML instead of the pickled format they
> could be easily edited alongside the AsciiDoc source files.

That might make sense, but the .blogpost file does require procedural
generated information (ID, dates, what's been uploaded and the like).
So, I don't think you are going to get away from having a picked
.blogpost file.

I did at one point think about providing a metadata file with the
information in it. So, you'd have had post.adoc, post.meta, and
post.blogpost (generated). But, ultimately, I can't see that this a big
advantage, given that the asciidoc syntax provides a naturalistic
extension point. And I have to open two files to get a complete picture
of the blogpost.

> - Alternatively a --cache-only (--local ?) option that would update the
> local .blogpost file but would suppress the upload.
>
> - Or more simply, if the upload fails then continue and update the
> .blogpost file (but not the created_at or updated_at fields) -- but this
> doesn't give you the ability to hold back the upload.

Both of these would work. Again, from my perspective, it's easier to
have the info with the source; for me, the categories are part of the
blogpost. I want to read them both at the same time.

As it happens for my specific use case, this would also not work,
because the date of the .blogpost file would not longer be an accurate
reflection of the last blog update. So, make wouldn't work. Perhaps this
doesn't make any odds because blogpost works out for itself whether it
needs to repost; it probably does a better job of the dependency
analysis than make.

Phil

Phillip Lord

unread,
Sep 10, 2009, 10:41:17 AM9/10/09
to asci...@googlegroups.com


Stuart

Just wondering whether you'd had chance to think about the patch that I
sent for categories (and status) in blog post.

My general impression is that you weren't keen, which is fine; this is
fine, as I can always take the code for reading categories and status
out of blogpost, then call it independently.

Cheers

Phil
--
Phillip Lord, Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk
School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, msn: m...@russet.org.uk
NE1 7RU

Stuart Rackham

unread,
Sep 11, 2009, 9:10:33 PM9/11/09
to asci...@googlegroups.com
Phillip Lord wrote:
>
>
> Stuart
>
> Just wondering whether you'd had chance to think about the patch that I
> sent for categories (and status) in blog post.
>
> My general impression is that you weren't keen, which is fine; this is
> fine, as I can always take the code for reading categories and status
> out of blogpost, then call it independently.

Hi Phil

Apologies for not getting back sooner. I'm rereading the posts and am warming to
your ideas :-) This is why I like email discussions, they give me days and days
to mull things over (some would say procrastinate) -- I'm no good at thinking on
my feet.

Anyway, here are some more thoughts:

Why not have the post command simply check for a :categories: attribute entry in
the AsciiDoc source file and update the categories automatically? This would
eliminate the need for a separate --read-categories command.

Take it to the logical extreme and allow all .blogpost meta-data attributes (id,
url, status, categories, type, created) to optionally reside in the AsciiDoc source.

A single e.g. -m, --meta-data option would signal blogpost to create/update/read
attributes at the start of the AsciiDoc source file (warning the user if there's
an existing .blogpost meta-data file).

This option would obviate the need for separate .blogpost cache files. I must
admit that having separate files is always irritating and error prone, maybe the
default behavior should be to store meta-data in the AsciiDoc source.


Cheers, Stuart

Phillip Lord

unread,
Sep 14, 2009, 6:00:00 AM9/14/09
to asci...@googlegroups.com
Stuart Rackham <srac...@gmail.com> writes:
> Phillip Lord wrote:
>>
>>
>> Stuart
>>
>> Just wondering whether you'd had chance to think about the patch that I
>> sent for categories (and status) in blog post.
>>
>> My general impression is that you weren't keen, which is fine; this is
>> fine, as I can always take the code for reading categories and status
>> out of blogpost, then call it independently.
>
> Hi Phil
>
> Apologies for not getting back sooner. I'm rereading the posts and am warming to
> your ideas :-) This is why I like email discussions, they give me days and days
> to mull things over (some would say procrastinate) -- I'm no good at thinking on
> my feet.

One of the great things with free software that you are not paid to do,
is that you get the right to do things whenever you want (or not at
all). For me, this tends to mean that I get the chance to think about
new features rather than rush them out; my experience is that the
software is better as a result. Looks like you feel the same way!

> Anyway, here are some more thoughts:
>
> Why not have the post command simply check for a :categories: attribute entry in
> the AsciiDoc source file and update the categories automatically? This would
> eliminate the need for a separate --read-categories command.

This is a good idea. I think that the only disadvantage is that
--read-categories, as well as suggesting to blogpost that it should look
for the attribute also forces an error if it's not there. I have
--read-categories in my make file; if I forget, the post is aborted. I
like this behaviour.


> Take it to the logical extreme and allow all .blogpost meta-data attributes (id,
> url, status, categories, type, created) to optionally reside in the AsciiDoc source.

This would make sense, yes, with the previous caveat of error
conditions. I don't want to give id and url; am happy for wordpress to
just assign those (in most cases anyway); so an error condition in this
case would not be idea for me.

> A single e.g. -m, --meta-data option would signal blogpost to create/update/read
> attributes at the start of the AsciiDoc source file (warning the user if there's
> an existing .blogpost meta-data file).
>
> This option would obviate the need for separate .blogpost cache files. I must
> admit that having separate files is always irritating and error prone, maybe the
> default behavior should be to store meta-data in the AsciiDoc source.

For me, the .blogpost files serve a useful purpose; they time stamp the
latest version, which make uses to work out what needs to be posted. Of
course, blogpost knows this also from the cache file, but make is
quicker.

But adding a pile of command line switches for all the metadata would be
a pain in the ass. Perhaps, instead, you could do something like


blogpost --metadata=status,type,categories post thing.adoc

Blogpost would then look for only those items after --metadata and
signal errors if they were not there.

Sounds reasonable?

Phil


Tong

unread,
Sep 14, 2009, 9:53:55 AM9/14/09
to asciidoc


On Sep 14, 6:00 am, Phillip Lord <phillip.l...@newcastle.ac.uk> wrote:

> > Anyway, here are some more thoughts:
>
> > Why not have the post command simply check for a :categories: attribute entry in
> > the AsciiDoc source file and update the categories automatically? This would
> > eliminate the need for a separate --read-categories command.
>
> This is a good idea. I think that the only disadvantage is that
> --read-categories, as well as suggesting to blogpost that it should look
> for the attribute also forces an error if it's not there. I have
> --read-categories in my make file; if I forget, the post is aborted. I
> like this behaviour.

I still like the idea of having a separate --read-categories command,
from the practical point of view. I.e., beside Phil's good point:

- no need to hack core AsciiDoc functionality, thus no need to amend
AsciiDoc document.

- attributes for "external" features (like blogpost) stay external.

- when blogging, people would normally focus on a certain area at a
time, so several pre-set category files might suits over 80% needs.
Thus eliminate the need for typing repetitive categories attribute
each time.

only my 2c though.

> But adding a pile of command line switches for all the metadata would be
> a pain in the ass. Perhaps, instead, you could do something like
>
> blogpost --metadata=status,type,categories post thing.adoc
>
> Blogpost would then look for only those items after --metadata and
> signal errors if they were not there.
>
> Sounds reasonable?

yeah, very reasonable to me. I use make files as well, but not on
blogpost yet. Would you share your make file for blogpost out please,
Phil?

Thanks

Phillip Lord

unread,
Sep 14, 2009, 12:30:15 PM9/14/09
to asci...@googlegroups.com

Tong <sunto...@gmail.com> writes:
>> This is a good idea. I think that the only disadvantage is that
>> --read-categories, as well as suggesting to blogpost that it should look
>> for the attribute also forces an error if it's not there. I have
>> --read-categories in my make file; if I forget, the post is aborted. I
>> like this behaviour.
>

> - when blogging, people would normally focus on a certain area at a
> time, so several pre-set category files might suits over 80% needs.
> Thus eliminate the need for typing repetitive categories attribute
> each time.

Not quite sure what you mean by this.


>
> only my 2c though.
>
>> But adding a pile of command line switches for all the metadata would be
>> a pain in the ass. Perhaps, instead, you could do something like
>>
>> blogpost --metadata=status,type,categories post thing.adoc
>>
>> Blogpost would then look for only those items after --metadata and
>> signal errors if they were not there.
>>
>> Sounds reasonable?
>
> yeah, very reasonable to me. I use make files as well, but not on
> blogpost yet. Would you share your make file for blogpost out please,
> Phil?

Sure, they are very simple; I'm afraid it's rather specific to my
directory layout.

I have four files.

"Makefile" which is just an include.

Makefile
blogpost-inc
generate_makefile.py
extract_index.py

Stuart Rackham

unread,
Sep 15, 2009, 12:44:08 AM9/15/09
to asci...@googlegroups.com
I think the .blogpost file should be optional, mandating .blogpost files so
the timestamp can be read faster saves relatively little time and you end up
with the potential for two out of sync timestamps.


>
> But adding a pile of command line switches for all the metadata would be
> a pain in the ass.

Agreed.


> Perhaps, instead, you could do something like
>
>
> blogpost --metadata=status,type,categories post thing.adoc
>
> Blogpost would then look for only those items after --metadata and
> signal errors if they were not there.
>
> Sounds reasonable?

Yes, but I think we need two new mutually exclusive options:

-m,--metadata:
Store metadata in AsciiDoc source file instead of .blogpost
cache file.

--read-attributes=ATTRIBUTES:
Update blog using metadata from the AsciiDoc source file. ATTRIBUTES
is a comma-separated list of metadata attribute names. Valid names
are categories, status, type. An error occurs if any of the
ATTRIBUTES are missing from the AsciiDoc source file.

This scheme retains the current behavior as the default behavior.

Examples:

blogpost -m --read-categories=categories,status post mydoc.txt

Reads categories and status from mydoc.txt and updates mydoc.txt.

blogpost --read-categories=categories,status post mydoc.txt

Reads categories and status from mydoc.txt and updates mydoc.blogpost.

blogpost -m post mydoc.txt

Reads metadata attributes from mydoc.txt, assigns default values to missing
attributes and updates mydoc.txt.


Cheers, Stuart


>
> Phil
>
>
>
> >
>


Phillip Lord

unread,
Sep 15, 2009, 9:22:56 AM9/15/09
to asci...@googlegroups.com

Stuart Rackham <srac...@gmail.com> writes:
>>> A single e.g. -m, --meta-data option would signal blogpost to create/update/read
>>> attributes at the start of the AsciiDoc source file (warning the user if there's
>>> an existing .blogpost meta-data file).
>>>
>>> This option would obviate the need for separate .blogpost cache files. I must
>>> admit that having separate files is always irritating and error prone, maybe the
>>> default behavior should be to store meta-data in the AsciiDoc source.
>>
>> For me, the .blogpost files serve a useful purpose; they time stamp the
>> latest version, which make uses to work out what needs to be posted. Of
>> course, blogpost knows this also from the cache file, but make is
>> quicker.
>
> I think the .blogpost file should be optional, mandating .blogpost files so
> the timestamp can be read faster saves relatively little time and you end up
> with the potential for two out of sync timestamps.

It depends; currently I keep my asciidoc files in a "per month"
directory, but I was going to move per year; this makes about 70 or 80
files per year. If I need to check all of these files with an XML-RPC
call, it's going to be slow. I agree that the timestamps can get out of
sync, though.

Of course, this behaviour is easy to replicate -- I just touch an empty
file when blogpost exits correctly.

If blogpost is optional, though, where are you going to store the "media
I've uploaded" data? Is the plan to put ALL of this in to the asciidoc
file? This is a nice idea in some ways, but it is going to mean updating
a file that you might also be editing.

I guess I am confused about the "storing metadata"; some metadata is
user derived, some wordpress.

> -m,--metadata:
> Store metadata in AsciiDoc source file instead of .blogpost
> cache file.
>
> --read-attributes=ATTRIBUTES:
> Update blog using metadata from the AsciiDoc source file. ATTRIBUTES
> is a comma-separated list of metadata attribute names. Valid names
> are categories, status, type. An error occurs if any of the
> ATTRIBUTES are missing from the AsciiDoc source file.
>
> This scheme retains the current behavior as the default behavior.
>
> Examples:
>
> blogpost -m --read-categories=categories,status post mydoc.txt
>
> Reads categories and status from mydoc.txt and updates mydoc.txt.
>
> blogpost --read-categories=categories,status post mydoc.txt
>
> Reads categories and status from mydoc.txt and updates mydoc.blogpost.


--read-attributes, I think. Yes, this is fine, with error conditions if
missing?


>
> blogpost -m post mydoc.txt
>
> Reads metadata attributes from mydoc.txt, assigns default values to missing
> attributes and updates mydoc.txt.


Makes sense to me. One noisy, one quiet. Or one with defaults, one
without, depending on how you look at it.

Phil

Stuart Rackham

unread,
Sep 15, 2009, 4:19:54 PM9/15/09
to asci...@googlegroups.com
Yes, use neither options and you get current behavior; --metadata changes the
storage location to source file; --read-attributes specifies which post options
are read from the source file and generates the noise.

Cheers, Stuart


>
> Phil
>
> >
>

Reply all
Reply to author
Forward
0 new messages