update debian.sur5r.net keyring

[i3/i3.github.io] / docs / layout-saving.html
diff --git a/docs/layout-saving.html b/docs/layout-saving.html

index d699715cab1a1064e5598e3e3fc2d388034e3196..cddd5827d792e05e643425d93f3df872c6d0c00d 100644 (file)
--- a/docs/layout-saving.html
+++ b/docs/layout-saving.html
@@ -4,7 +4,7 @@
  <head>\r
  <link rel="icon" type="image/x-icon" href="/favicon.ico">\r
  <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />\r
  <head>\r
  <link rel="icon" type="image/x-icon" href="/favicon.ico">\r
  <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 8.6.9" />\r
+<meta name="generator" content="AsciiDoc 8.6.10" />\r
  <title>i3: Layout saving in i3</title>\r
  <link rel="stylesheet" href="/css/style.css" type="text/css" />\r
  <link rel="stylesheet" href="/css/xhtml11.css" type="text/css" />\r
  <title>i3: Layout saving in i3</title>\r
  <link rel="stylesheet" href="/css/style.css" type="text/css" />\r
  <link rel="stylesheet" href="/css/xhtml11.css" type="text/css" />\r
@@ -90,7 +90,7 @@ it will be placed in the corresponding placeholder window. We say it gets
  <strong>swallowed</strong> by the placeholder container, hence the term.</p></div>\r
  <div class="paragraph"><p>Note: Swallowing windows into unsatisfied placeholder windows takes precedence\r
  over\r
  <strong>swallowed</strong> by the placeholder container, hence the term.</p></div>\r
  <div class="paragraph"><p>Note: Swallowing windows into unsatisfied placeholder windows takes precedence\r
  over\r
-<a href="http://i3wm.org/docs/userguide.html#_automatically_putting_clients_on_specific_workspaces">assignment\r
+<a href="https://i3wm.org/docs/userguide.html#_automatically_putting_clients_on_specific_workspaces">assignment\r
  rules</a>. For example, if you assign all Emacs windows to workspace 1 in your i3\r
  configuration file, but there is a placeholder window on workspace 2 which\r
  matches Emacs as well, your newly started Emacs window will end up in the\r
  rules</a>. For example, if you assign all Emacs windows to workspace 1 in your i3\r
  configuration file, but there is a placeholder window on workspace 2 which\r
  matches Emacs as well, your newly started Emacs window will end up in the\r
@@ -202,7 +202,7 @@ a Chrome window:</p></div>
  </a>\r
  </span></p></div>\r
  <div class="paragraph"><p>The structure of this JSON file looks a lot like the <tt>TREE</tt> reply, see\r
  </a>\r
  </span></p></div>\r
  <div class="paragraph"><p>The structure of this JSON file looks a lot like the <tt>TREE</tt> reply, see\r
-<a href="http://build.i3wm.org/docs/ipc.html#_tree_reply">http://build.i3wm.org/docs/ipc.html#_tree_reply</a> for documentation on that. Some\r
+<a href="https://build.i3wm.org/docs/ipc.html#_tree_reply">https://build.i3wm.org/docs/ipc.html#_tree_reply</a> for documentation on that. Some\r
  properties are excluded because they are not relevant when restoring a layout.</p></div>\r
  <div class="paragraph"><p>Most importantly, look at the "swallows" section of each window. This is where\r
  you need to be more or less specific. As an example, remember the section about\r
  properties are excluded because they are not relevant when restoring a layout.</p></div>\r
  <div class="paragraph"><p>Most importantly, look at the "swallows" section of each window. This is where\r
  you need to be more or less specific. As an example, remember the section about\r
@@ -253,23 +253,25 @@ the window which matches any of the criteria. As an example:</p></div>
  <div class="olist arabic"><ol class="arabic">\r
  <li>\r
  <p>\r
  <div class="olist arabic"><ol class="arabic">\r
  <li>\r
  <p>\r
-Layout files contain multiple “JSON documents” on the top level, whereas the\r
-   JSON standard only allows precisely one “document” (array or hash).\r
+Layout files contain multiple “JSON texts” at the top level. The JSON\r
+   standard doesn&#8217;t prohibit this, but in practice most JSON parsers only\r
+   allow precisely one “text” per document/file, and will mark multiple texts\r
+   as invalid JSON.\r
  </p>\r
  </li>\r
  <li>\r
  <p>\r
  </p>\r
  </li>\r
  <li>\r
  <p>\r
-Layout files contain comments which are not standardized, but understood by\r
-   many parsers.\r
+Layout files contain comments which are not allowed by the JSON standard,\r
+   but are understood by many parsers.\r
  </p>\r
  </li>\r
  </ol></div>\r
  </p>\r
  </li>\r
  </ol></div>\r
-<div class="paragraph"><p>Both deviations from the JSON standard are to make manual editing by humans\r
+<div class="paragraph"><p>Both of these deviations from the norm are to make manual editing by humans\r
  easier. In case you are writing a more elaborate tool for manipulating these\r
  layouts, you can either use a JSON parser that supports these deviations (for\r
  example libyajl), transform the layout file to a JSON-conforming file, or\r
  easier. In case you are writing a more elaborate tool for manipulating these\r
  layouts, you can either use a JSON parser that supports these deviations (for\r
  example libyajl), transform the layout file to a JSON-conforming file, or\r
-<a href="http://cr.i3wm.org/">submit a patch</a> to make <tt>i3-save-tree(1)</tt> optionally\r
-output standard-conforming JSON.</p></div>\r
+<a href="https://github.com/i3/i3/blob/next/.github/CONTRIBUTING.md">submit a patch</a>\r
+to make <tt>i3-save-tree(1)</tt> optionally output standard-conforming JSON.</p></div>\r
  </div>\r
  </div>\r
  </div>\r
  </div>\r
  </div>\r
  </div>\r