Empty string is added each time the configuration is loaded.

[Brikster]

Describe the bug New lines adds every time config loaded.

To Reproduce

TestConfig testConfig = ConfigManager.create(TestConfig.class, (it) -> {
            it.withConfigurer(new YamlBukkitConfigurer(SectionSeparator.NEW_LINE), new SerdesBukkit());
            it.withBindFile(getDataFolder().toPath().resolve("settings.yml"));
            it.withRemoveOrphans(true);
            it.saveDefaults();
            it.load(true);
        });

Each loading config will add extra empty line after header.

Expected behavior Line shouldn't be added if already exists.

Library version

    implementation 'eu.okaeri:okaeri-configs-yaml-bukkit:4.0.6'
    implementation 'eu.okaeri:okaeri-configs-serdes-commons:4.0.6'
    implementation 'eu.okaeri:okaeri-configs-serdes-bukkit:4.0.6'

[CDFN]

Can you try without using SectionSeparator setting and see if it helps?

[Brikster]

Yes, it helps, but I want to use section separator. It doesn't look like a normal behavior.

[dasavick]

I don't think SectionSeparator is actually used, probably should have been removed before 4.x release. It was intended to separate root elements, not the header only. This is probably broken since the early beginnings of the library, as this is when ConfigPostprocessor was introduced to add comments in bukkit backend manually.

You may want to look into using empty @Header/@Comment annotation if you really must have the sections separated. Empty value will result with no comment prefix being placed in the line. Header at the moment requires explicit empty string due to no default value.

@Header("welcome")
@Header("welcome")
public class TestConfig extends OkaeriConfig {

    @Comment
    @Comment("hi")
    private String val1 = "a";

    // alternative
    @Comment({"", "hello"})
    private String val2 = "b";
}

# welcome
# welcome

# hi
val1: a

# hello
val: b

[dasavick]

SectionSeparator is no more (https://github.com/OkaeriPoland/okaeri-configs/commit/e89a574317d28dde3e09b85958439a5ecdf53d34). Further discussion via #31.