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.

Hi John,

No, it can be done without any widgets. There's a content_selector
option under settings that takes a CSS selector of the element in
template where content should be inserted. It default to "body", but can
be any valid selector.

On my own site I use a <div id="content">, so I have it setup like this:
https://github.com/dmbaturin/baturin.org/blob/master/soupault.conf#L17-L18

For your template you will need:

[settings]
  content_selector = "div.container"

On 4/29/20 4:22 AM, Aoirthoir An Broc wrote:
> will the following create any operating system issues, such as with
> windows:
>
> addClass.lua being called with widget="addClass"
>
> vs
>
> add-class.kua being called with widget="add-class"

I used hyphenated names in part to make them OS-independent indeed.

Also, I somewhat intentionally use hyphens instead of underscores in my
plugin file names to make them visually different from built-in widgets

I've made a point to break compatibility as rarely as possible, but I
fear soon it will be time for a 2.0 release.

Some design decisions didn't pass the test of time, and changing the
config syntax and/or behaviour can make some thing more logical and
flexible.
If we are going to do it, it's a good idea to make as many incompatible
changes at once as possible so that people will only need one big migration.
Small incompatible changes in every release is a horrible practice.

My plan how to make that migration simpler: write a script for
converting old configs to the new format. That can even be a client-side
web app where you can paste your config.

On 4/27/20 6:02 AM, Aoirthoir An Broc wrote:
> I think the best option would be an is_element test... so we can just
> continue through our loops. knowing which kind of data we are dealing
> with gives us options that just altering the add_class would not give
> us. As that would only work on add_class. Whereas in my case i was
> doing something else entirely and only used the add_class since it was
> the example code.
>
Ok, making HTML.add_class etc. work as a no-op for non-element nodes
turned out a bit harder than I thought. It will still fail for document
and text nodes—with a better error message than before.
However, it now works correctly with element nodes returned by
HTML.children and friends.

On 4/27/20 6:02 AM, Aoirthoir An Broc wrote:
> I think the best option would be an is_element test... so we can just
> continue through our loops. knowing which kind of data we are dealing
> with gives us options that just altering the add_class would not give
> us. As that would only work on add_class. Whereas in my case i was
> doing something else entirely and only used the add_class since it was
> the example code.
>
> on the bright side i did finish my plugin which is called
> block-maker.lua despite the appearance of restrictions with lua, so
> far everything I have ever tried to do, i found a way to accomplish
> with lua-ml and soupault. next step is going to be a
> create_gallery.lua plugin.. that will search a directory and create
> img elements for all the images there. That, is for tomorrow...