where to put user editable css-like file for ease of editing

[KevinH]

Quick question:

Should it be okay for plugins to store things into the Sigil's Preferences folder at its root level or should it only write files to its own prefs folder?

I am designing a PrettyPrinter plugin for Sigil where users will need easy access to change/edit a css-lile file that controls how specific tags are handled when prettyprinting.

This prettyprinter.pcss (extention is short for pseudo css) of course uses braces "{" "}" everywhere (as these are selectors) making storing it inside a json file a bit of a pain that would also inhibit easy editing with any text editor.

I could of course write a gui editor for the plugin to directly edit that pcss file but I am really do not want to make this tool user interactive but instead be an auto-open auto-close plugin quick and silent tool that can reformat any number of selected xhtml files (just like an internal Sigil tool).

So my first thought was tp put the prettyprinter.pcss file at the root of the Sigil Preferences folder but now feel that it may be setting a dangerous precedent for plugins.

Should I just store this file in the plugins_prefs folder inside the plugin's folder?

It would be easy to do based on code I found in a number of existing plugins:

 prefs_folder = os.path.join(os.path.dirname(bk._w.plugin_dir), "plugins_prefs", bk._w.plugin_name)

But would most users be able to find it?

Where should non-json files that the plugin user needs to easily access be stored?

Thoughts?

[JSWolf]

I suggest making a button in the plugin to access the non-jason file.

[KevinH]

Unfortunately, the whole goal of this project was to create a fast tool that was NOT to use a gui (as I said, ... "really do not want to make this tool user interactive") so there can be no button.

[theducks]

Why not follow Kovids lead and put them in the sigil config / plugin folder?

That way, There is only 1 Sigil folder backup that is needed to take everything with you.
FWIW I just did that when My W10 SSD popped errors. I installed Linux Mint, Sigil, then copied the old config folder over. Sigil was up and running again in less time than it took to replace the drive (and install Linux)

[DiapDealer]

I don't know of any specific dangers, but I do feel that having plugins that write configs to anywhere other than their own prefs folder could potentially lead to naming clashes. Probably pretty rare, but still.

[KevinH]

@theducks,
We kinda already do that as each plugin has its own folder inside the Sigil Preferences folder inside its plugins folder. Each plugin also has its own preferences folder in the folder plugins_prefs (again inside the Sigil Preferences folder). So if the user wants to create a full backup, then all they need do is zip up Sigil's Preferences folder. They will get all plugins, all preferences, all ini files, all checkmark repos, ... everything.

@DiapDealer,
Okay that makes sense and what I thought.

So for right now I have just placed the prettyprinter.pcss file inside the plugins own prefs folder.

I have created an alpha of the plugin just to play with. I will attach it to this thread.

So if a user installs it and runs it they can then look in its Sigil Preferences folder for the plugins_prefs/PrettyPrinter/prettyprinter.pcss file.

Here is the default version of that file. It uses css-like tag selectors and a limited set of properties to control things. It is a simplification of that gitee/sigil-modified codebase that does its prettify.

/* global settings */
  @indent 2;

  /* block-level elements */
  html, body, p, div, h1, h2, h3, h4, h5, h6, ol, ul, li, address, blockquote, dd, dl, fieldset, form, hr, nav, menu, pre, table, tr, td, th, article {
      opentag-br : 1 0;
      closetag-br: 0 1;
  }
  p, div {
      opentag-br : 1 0;
      closetag-br: 0 2;
  }

  /* head elements */
  head, meta, link, title, style, script {
      opentag-br : 1 0;
      closetag-br: 0 1;
  }

  /* xml header */
  ?xml {
      opentag-br: 0 1;
  }

  /* doctype */
  !DOCTYPE {
      opentag-br  : 1 2;
      attr-fm-resv: true;
  }

  /* xhtml element */
  html {
    inner-ind-adj:-1;
  }

  /* comment */
  !-- {
      attr-fm-resv: true;
  }

  /* main */
  body {
      opentag-br : 2 1;
      closetag-br: 1 1;
  }

  h1, h2, h3, h4, h5, h6 {
      opentag-br : 2 0;
      closetag-br: 0 2;
  }

  pre, script, style {
    text-fm-resv: true;
  }

/*

  The prettyprinter.pcss is a pseudo-CSS file whose selectors may only
  include element (tag) names and immediate child-descendant combinators that
  are also element names.

  There is a single global parameters that must appear at the top of the file before
  any selectors.  It is *not* used inside braces '{'.

     @indent: int1;            # number of spaces per indentation level.
                               # Range 0–4, default 2.

  There are 6 possible per-selector properties:

     opentag-br: int1 int2;     # new lines before(int1) and after (int2)
                                # an opening tag.  Each 0–9, default 0.

     closetag-br: int1 int2;    # new lines before (int1) and after (int2)
                                # a closing tag.  Each 0–9, default 0.

     ind-adj: int1;             # adjusts the indent level of the node.
                                # Range -9 to 9.

     inner-ind-adj: int1;       # adjusts the indentation level within a node
                                # but excluding the node itself.  Range -9 to 9.

     attr-fm-resv: true|false;  # preserve spaces/newlines inside the opening
                                # tag.  Default false.

     text-fm-resv: true|false;  # preserve spaces/newlines in the node's text.
                                # Default false.

*/

I still want to figure out an easy way for user's to see and edit the file! Maybe adding a ControlPrettyPrinting plugin that uses a gui - but that seems extreme.

I am thinking of hard coding some of this to prevent the user from making a bad mistake.

Particularly this snippet:

  pre, script, style {
    text-fm-resv: true;
  }

That snippet prevents text from being condensed inside of pre tags (kinda defeats the entire purpose for pre), script tags (not a good idea for javascripts) and for all css code inside style tags in the xhtml file (again not a great idea to change return and whitespace in css as it might impact combinator selectors).

I should probably hard code that somehow.

Also if you use the css property white-space anyplace in your style attributes, css files, or inline style tags, you will not want to run this PrettyPrinter as it can not detect those cases.

[KevinH]

Okay, for those following along, I have attached PrettyPrinter_v030.zip to this post. I still have not solved the issue of how to make the prettyprinter.qcss file easily discoverable and editable (yet).

But I have added code to make best efforts to detect use of white-space and white-space-collapse properties anywhere in the xhtml's style tags, or in its style attributes, and of course anyplace is its linked stylesheets.

If any of these properties are detected condenseText() is never called to prevent PrettyPrinting from doing actual damage.

So it should be safe to use the PrettyPrinter plugin as it is to use Prettify in Sigil master (Sigil master uses the same tests).

I am sure that someway, somehow someone could import another css file (not linked to the xhtml) into a css file that is directly linked to the xhtml and hide a white-space or white-space-collapse property there but ... all the more reason to make a checkpoint *BEFORE* running any Prettify/PrettyPrinter.

The only alternative is to walk all of the epubs css files no matter is they are linked to this xhtml for not, or parse each linked css file fully looking for an @import someplace and process it as well recursively if needed!

[BeckyEbook]

I’ve been testing this plugin for a few days now and I still have mixed feelings about it.
I really like the concept, but ‘something’ isn’t quite right
I’ve experimented quite a bit, but I’m still coming across some errors. I hope we can sort this out. The strange behaviour after running the plugin a few times is particularly frustrating – that’s when the problem becomes really obvious.

Note! I’m well aware that I could just run "Mend and Prettify Code", but my dream would be to have exactly the kind of configurable custom-Prettify that this plugin offers.

Run the plugin a few times on a test file – you’ll surely see what I mean.

I’m keeping my fingers crossed for this plugin!

I’ve prepared an icon for the PrettyPrinter plugin, but I might come up with something better. It’ll definitely be ready before the official release.

[KevinH]

Originally Posted by BeckyEbook

I’ve been testing this plugin for a few days now and I still have mixed feelings about it.
I really like the concept, but ‘something’ isn’t quite right
I’ve experimented quite a bit, but I’m still coming across some errors. I hope we can sort this out. The strange behaviour after running the plugin a few times is particularly frustrating – that’s when the problem becomes really obvious.

Note! I’m well aware that I could just run "Mend and Prettify Code", but my dream would be to have exactly the kind of configurable custom-Prettify that this plugin offers.

Run the plugin a few times on a test file – you’ll surely see what I mean.

I’m keeping my fingers crossed for this plugin!

I’ve prepared an icon for the PrettyPrinter plugin, but I might come up with something better. It’ll definitely be ready before the official release.

I will take a look at it.

Also for what it is worth, we have made the internal Sigil Prettify use a user customizable prettprint.xml more customization as well, and that is in master.

[DNSB]

The extra blank lines on first run and adding an extra blank line after the <?xml version="1.0" encoding="utf-8"?> line on each run are the two nits I've noticed so far.

[KevinH]

Hmm, here is what Checkpoint compare is showing after the initial run is done once as compared to the state after the second run of the plugin.

See attached image.

But further runs show no changes after that to the one before it.

So I am not seeing any space change before or after the xml header at all.

I am gaining a space before the closing head, closing tr, and closing thead, closing tbody, closing tfoot and closing body and closing html.

Is this what you re referring to?

Would you please post a copy of your prettyprinter.pcss file that can be found inside the PrettyPrinter Prefs folder?

[KevinH]

And this change to the plugin's PrettyPrinter.py file seems to have solved that issue:

--- PrettyPrinter.py.keep	2026-04-14 16:21:58
+++ PrettyPrinter.py	2026-04-14 16:23:24
@@ -240,8 +240,8 @@
                 else:
                     indent = ''
 
-                previous_text = source[last_tag_end_pos:ti.pos]
                 if props.text_fm_resv:
+                    previous_text = source[last_tag_end_pos:ti.pos]
                     pre_br = ''
                 else:
                     if not keep_whitespace:

In other words, do not go back to the untrimmed version of the previousText unless we are preserving whitespace.

Please make this change in the plugin and let me know if it fixes your issues.

Thanks!

Kevin

[KevinH]

Actually,that works but then the keep_whitespace logic for safety is using the wrong (trimmed) previousText.

So I reworked the code a bit:

Please try the following new version.

[KevinH]

Please let me know if this fixes the issues you are seeing as there could be other corner cases that need to be addressed.

[DNSB]

Originally Posted by KevinH

Hmm, here is what Checkpoint compare is showing after the initial run is done once as compared to the state after the second run of the plugin.

See attached image.

But further runs show no changes after that to the one before it.

So I am not seeing any space change before the xml header at all.

I am gaining a space before the closing head, closing tr, and closing thead, closing tbody, closing tfoot and closing body and closing html.

Is this what you re referring to?

Would you please post a copy of your prettyprinter.pcss file that can be found inside the PrettyPrinter Prefs folder?

I've attached images of the original file and then after 1 run, 2 runs and after 10 runs. I haven't modified the prettyprinter.pcss file from what was created when PP 0.30 was installed.