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.