substitutions...

[mwoehlke]

First off, let me say I think I am in love :-).

I have been keeping a (private) journal for several years, started in M
$ Word (before I ditched that awful OS ;-) ), then OpenOffice.org, but
OOo has some strange issue that, after a document is open a while (as
in, just leave OOo running), it loses the ability to save it... and it
happens faster with my 85-page journal. So I recently decided to move
it to a blog format.

BlazeBlogger is *ideal* for this, since I neither need nor want a
server, and I am already enjoying it immensely and planning other
uses. However... one thing I miss is the ability to easily add
emoticons. It wasn't all that easy in OOo either, but now that I am
not dealing with a monolithic document, it is harder to copy/paste
from previous posts.

So... I would like to see a new feature that would, in addition to
%root%, replace arbitrary %foo% with user-specified replacements. I've
already hacked this into my own copy of blaze-make, so I can provide a
patch, but I don't know what to do with it :-). Would this be a
feature worth adding, and if so, where do I send the patch?

(And... if BlazeBlogger only supported some non-HTML markup syntax (as
an addition, not replacing HTML), preferably MoinMoin or MediaWiki, it
would be just about perfect ;-).)

[Jaromir Hradilek]

Thank you very much for your e-mail and please excuse my late response
-- regrettably, I was not paying much attention to my mailbox lately.

> (And... if BlazeBlogger only supported some non-HTML markup syntax (as
> an addition, not replacing HTML), preferably MoinMoin or MediaWiki, it
> would be just about perfect ;-).)

I am glad I can say that this has been already done in the latest
development version and will be included in the next release pretty
soon! :-) Support for another markup language was one of the features
I wanted there from the very beginning, but kept postponing it,
because I was not sure how to implement it best. I hope you will like
it.

Since I wanted it to be as flexible as possible, I decided to
implement it in a form of another configuration option,
core.processor; if set, both blaze-add and blaze-edit let you edit the
raw file in whatever markup you choose and then call the processor to
convert it to HTML. The main advantages of this particular solution
are as follows:

1. blaze-make is not slowed down at all, because it works with
already converted files.
2. Old posts are not affected and you are still able to edit them in
the HTML directly.
3. You can choose whatever markup you want and not only that!
core.processor has many other uses: you can use it to replace your own
placeholders, validate/fix the input, add some automatic content like
contact form etc.

So, to write your posts in Markdown, all you have to do is type:

$ blaze-config core.processor 'markdown --html4tags %in% > %out%'

Similar approach applies to other markups.

> So... I would like to see a new feature that would, in addition to
> %root%, replace arbitrary %foo% with user-specified replacements. I've
> already hacked this into my own copy of blaze-make, so I can provide a
> patch, but I don't know what to do with it :-). Would this be a
> feature worth adding, and if so, where do I send the patch?

Once again, this is perfect candidate for core.processor option rather
than hacking it to the blaze-make, and can be easily done using sed or
awk. I really don't think that this is something that ought to be
implemented in core BlazeBlogger. As an external application, it can
be much more sophisticated: you can even make it replace ordinary text
smileys. Nevertheless, if you disagree, you can send me your patch
(either to my personal e-mail or add it as an issue to the bugtracker
on Google Code) and I will take a look at your solution.

Anyway, if you are interested and do not want to wait for official
release, you can find the latest development version (as well as not
yet announced bash completion and quick reference card ;-)) at
http://gitorious.com/blazeblogger In case you decide to test it,
please, let me know what you think about it, user feedback is always
most helpful.

[mwoehlke]

On Sep 28, 4:24 pm, Jaromir Hradilek wrote:
> Thank you very much for your e-mail and please excuse my late response
> -- regrettably, I was not paying much attention to my mailbox lately.

Meh, two days isn't "late", especially over a weekend :-).

> > (And... if BlazeBlogger only supported some non-HTML markup syntax (as
> > an addition, not replacing HTML), preferably MoinMoin or MediaWiki, it
> > would be just about perfect ;-).)
>
> I am glad I can say that this has been already done in the latest
> development version and will be included in the next release pretty
> soon! :-) Support for another markup language was one of the features
> I wanted there from the very beginning, but kept postponing it,
> because I was not sure how to implement it best. I hope you will like
> it.
>
> Since I wanted it to be as flexible as possible, I decided to
> implement it in a form of another configuration option,
> core.processor; if set, both blaze-add and blaze-edit let you edit the
> raw file in whatever markup you choose and then call the processor to
> convert it to HTML.

This, oddly enough, is how I would have suggested to do it. However...

> The main advantages of this particular solution
> are as follows:
>
>   1. blaze-make is not slowed down at all, because it works with
> already converted files.
>   2. Old posts are not affected and you are still able to edit them in
> the HTML directly.

...this I am not so sure of. I'd rather the posts be kept in the
original format. It's fine to convert them immediately and cache them,
but I want to be able to edit the originals. Discarding the source
doesn't seem like a good idea.

I guess this means the processor would need to be stored as a property
on the post. That should be do-able; use the config value to
initialize the property in edit copy. That way you can even decide to
change the processor when writing a post.

> > So... I would like to see a new feature that would, in addition to
> > %root%, replace arbitrary %foo% with user-specified replacements. I've
> > already hacked this into my own copy of blaze-make, so I can provide a
> > patch, but I don't know what to do with it :-). Would this be a
> > feature worth adding, and if so, where do I send the patch?
>
> Once again, this is perfect candidate for core.processor option rather
> than hacking it to the blaze-make, and can be easily done using sed or
> awk. I really don't think that this is something that ought to be
> implemented in core BlazeBlogger.

I'll hold off on that until the above problem (loss of the "source")
is addressed :-). Meanwhile...

> Nevertheless, if you disagree, you can send me your patch
> (either to my personal e-mail or add it as an issue to the bugtracker
> on Google Code) and I will take a look at your solution.

...I think I'll go ahead and send you the patch for consideration,
especially as I have a second, small patch to go with it.

--
Matthew

[Jaromir Hradilek]

> ...this I am not so sure of. I'd rather the posts be kept in the
> original format. It's fine to convert them immediately and cache them,
> but I want to be able to edit the originals. Discarding the source
> doesn't seem like a good idea.

You are absolutely right, it would be disasterous behaviour, that's
why it does not do that. :-) I should have mentioned before that both
source (i.e. what you typed in) and processed output are of course
stored and whenever you call blaze-edit, the source is opened by
default and then re-converted.

> I guess this means the processor would need to be stored as a property
> on the post. That should be do-able; use the config value to
> initialize the property in edit copy. That way you can even decide to
> change the processor when writing a post.

It is in fact much simpler than that. If you take a look at .blaze/
posts, you will see a couple of directories: ``head'', where post
metadata are kept, and ``body'' with the actual HTML content. Having
core.processor enabled introduces third directory, ``raw'', where the
source files are kept. Now, as long as the core.processor is enabled,
blaze-edit looks to the ``raw'' directory: if the particular entry is
there, it is opened in the editor, if it isn't, you are presented with
choice to either edit the HTML form directly, or force creation of
new, empty raw file. When core.processor is disabled, blaze-edit looks
directly to ``body''. However, you can allways enforce adding/editing
particular entry in HTML directly using ``--html'' command-line
option.

I think this is quite reasonable approach. I am also afraid making it
possible to use different processor for every individual post would
eventually lead to confusion.

> ...I think I'll go ahead and send you the patch for consideration,
> especially as I have a second, small patch to go with it.

Thank you, I will take a look at that!

[mwoehlke]

On Sep 29, 4:29 pm, Jaromir Hradilek wrote:
> > I guess this means the processor would need to be stored as a property
> > on the post. That should be do-able; use the config value to
> > initialize the property in edit copy. That way you can even decide to
> > change the processor when writing a post.
>
> It is in fact much simpler than that. If you take a look at .blaze/
> posts, you will see a couple of directories: ``head'', where post
> metadata are kept, and ``body'' with the actual HTML content. Having
> core.processor enabled introduces third directory, ``raw'', where the
> source files are kept. Now, as long as the core.processor is enabled,
> blaze-edit looks to the ``raw'' directory: if the particular entry is
> there, it is opened in the editor, if it isn't, you are presented with
> choice to either edit the HTML form directly, or force creation of
> new, empty raw file.

Unfortunately, this means that old posts are apparently "missing"
their source. Plus if you decide you want to change processors in the
future... well, you can't.

> I think this is quite reasonable approach. I am also afraid making it
> possible to use different processor for every individual post would
> eventually lead to confusion.

Maybe, but only if someone chose to use that ability. Personally I'd
be nervous of omitting that possibility :-). Old posts (i.e. before
you had the option of a processor) aren't quite as big an issue,
though I think ability to specify a processor would result in cleaner
handling... but as above, /not/ storing the processor as a property of
the post effectively means you can't change it in the future (without
either losing, or having to re-do, all your old sources, anyway).

Note I'm not talking about changing flags (that's why the suggestion
to store processor on the post as an identifier that is referenced in
a config), but completely changing the processor... say, from markdown
to mediawiki.

--
Matthew

[Jaromir Hradilek]

> Unfortunately, this means that old posts are apparently "missing"
> their source.

Fortunately, there is nothing unfortunate about that. If you have
written your old pages and posts directly in HTML, it is only logical
that you either edit them in it, or that you provide the `source'
additionally. And that is exactly what BlazeBlogger do whenever the
source is `missing'.

> Plus if you decide you want to change processors in the
> future... well, you can't.

Why not? Well, see below.

> but as above, /not/ storing the processor as a property of
> the post effectively means you can't change it in the future (without
> either losing, or having to re-do, all your old sources, anyway).

No. Actually, since blaze-make works with already processed files
only, you are free to change the processor whenever and to whatever
you want. The problem arise only when you decide to edit old entry,
that was initially written in different markup. Then you have
generally two options: (1) update it to the current markup, or (2)
edit the entry in HTML directly. You do not lose anything nor you have
to redo a single post. Unless you want, of course.

In its current form, processor is not only the way how to make writing
entries in different markup possible, but it is an universal, multi-
purpose solution; we have already discussed the possibility to use it
for replacing plain-text emoticons with proper IMG elements,
substituting user-supplied placeholders, or validating the input.
Turning any of the mentioned utilities on or off should be as simple
as changing one particular, general configuration option. From my
point of view (and not only mine, as I have discussed this issue
privately with some of my other users), the gain of storing current
processor setting as a property of every individual entry would be
minimal, but the pain possibly much bigger.

[john tocher]

Awesome.

I was going to suggest markdown as it's what I used with blosxom and pyblosxom. I thought I was going to have to implement it with bash (that's what I did before) but I see now it's just a configuration step.

This rocks. Thanks Jaromir!

John