Hi Edison,

They work for me, so this is odd. See
https://github.com/dmbaturin/baturin.org/blob/master/soupault.conf#L102-L109

I'll need to see your config to tell anything and reproduce the issue.

On 4/19/21 11:17 PM, Edison Orellana wrote:
> Hi,
> I'm trying to setup my index.views but my triple quote multi line
> string isn't working for the index_item_template setting.
> When I run ./soupault it gives errors about control characters needing
> to be escaped. Any advice?
> Best,

Hi everyone,

Today I've released soupault 2.6.0:
https://soupault.app/blog/soupault-2.6.0-release/

Then I remembered about the mailing list. The list has been completely
silent for the last five months.
All communication happened elsewhere.

Does anyone still plan to use the list as a release notification and
discussion mechanism?
If not, I suppose it's better to archive it and remove its mention from
the website.

Hi everyone,

Soupault 2.2.0 release is now available for download and from OPAM. Read
the full announce at:
https://soupault.neocities.org/blog/soupault-2.2.0-release

Highlights:

* The global soupault config is now availble to plugins as `soupault_config`
I think it was Aoirthoir's idea originally.

* There's a new config section named "custom options" that is exempt
from option validity checks.
You can put arbitrary settings there and use them from plugins.

On 10/29/20 12:34 AM, Tom Browder wrote:
> The glossary mentions "jingoo" as a template processor. How would that
> be used in the "soupault" processing flow?
>
> Best regards,
>
> -Tom

Hi Tom,

There are two ways to use it.

Soupault can extract metadata from the pages using CSS selectors and
configurable fields—a bit like scraping your own site

Hi everyone,

Soupault has definitely grown, but I wouldn't call its current state
"maturity".
It's more like "coming of age": it avoided parental^W maintainer
abandonment,
survived a few childhood diseases, and got its first jobs.

However, the decisions of what it wants and doesn't want to be aren't
final yet,
and the question how to make it grow is not answered either.

It would be cool to have a meetup with early adopters (and everyone
interested)

Do you think it's the global config that should be exposed, including
configs of other widgets?

I think earlier you suggested to add a special section for shared plugin
settings. I think a sensible approach would be to create a new
[settings.custom] section where anything goes, and then expose the
entire [settings] section to plugins.

This way plugins will have access to the fundamental settings like
directory paths, clean URLs flag etc. and to user-defined options.


On 8/26/20 3:33 PM, Aoirthoir wrote:
> There are definitely use cases. If I'm not driving this weekend I'll

Hi Aoirthoir,

The _complete_ config is not available to plugins yet. However, it's
doable now, and not even hard to do.

If you think there are use cases for it, I can add it and either make a
build for you or make a new beta.

On 8/25/20 2:50 PM, Aoirthoir wrote:
> This is very exciting news. I'll be driving all week so will look at
> it on the weekend.
>
> All i correct in understanding that all data in the config is
> available to plugins?

Hi everyone,

Soupault 2.0.0-beta1 is available. It makes breaking changes to the
config format in order to unblock some useful improvements and clean up
the format before it's too late (as in, while the community is still small).

Please read the blog post carefully:
https://soupault.neocities.org/blog/soupault-2.0.0-beta1-release/

I also wrote a convertor from the old to the new syntax:
https://soupault.neocities.org/1-to-2
Its only issue is that it cannot preserve original formatting and
comments, so instead I made it output a details log of its actions so
that you can use it as a guide, if you choose to edit the config by hand.

Hi everyone,

I've already been talking about planned incompatible changes for
soupault 2.0 release, and no one actively objected.

Now it's time to make precise migration plans.

First, a quick recap of the issues:
1. index options like index_date_selector etc. duplicate the custom
fields functionality but are less flexible than custom fields
2. settings.default_template option duplicates the functionality of
custom templates
3. breadcrumbs widget's breadcrumb_template option should better be a
template string rather than a base HTML string with implicit "a" selector

Hi everyone,

Recently I noticed that HTML standard still doesn't allow an <ul> or
<ol> element to have another <ul> or <ol> inside.
They can only have <li> elements for children, and nested lists should
be inside those <li>'s.

Then I noticed that a lot of table of contents (and nested lists in
general) around the web are non-compliant as well.
However, HTML-compliant nesting in fact has advantages for automated
rewriting.
It's also quite a bit harder to produce if you work with a flat list of
headings, which may be the reason why so many ToC's use invalid HTML.