aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorMiguel Ángel Moreno <mail@migalmoreno.com>2022-03-05 18:55:25 +0100
committerMiguel Ángel Moreno <mail@migalmoreno.com>2022-03-05 18:55:25 +0100
commitf016c394ca38b3859323a65f27a5ef7c8f96e4dc (patch)
tree948c2e8a8e4f75788d3f45cb8442747ef474e944 /README
parent13f2324eb38da86acdb8f683d42ba38db867b0a0 (diff)
README: Provides more documentation steps
Diffstat (limited to 'README')
-rw-r--r--README52
1 files changed, 38 insertions, 14 deletions
diff --git a/README b/README
index 7ea84e5..0ac4b5e 100644
--- a/README
+++ b/README
@@ -16,33 +16,57 @@ Then, one would have to refresh the ASDF cache via =asdf:clear-source-registry=.
However, by default Nyxt won't read the custom source registry path we provided, so one has to ensure to include a =reset-asdf-registries= invocation in their Nyxt's initialization file too.
-Then, in the init file, one should include what follows.
+Then, in the init file, ensure to include what follows.
#+begin_src lisp
(asdf:load-after-system :nx-mapper (nyxt-init-file "/path/to/mapper.lisp"))
+
+(define-configuration buffer
+ ((default-modes
+ (append
+ ;; Either of them or both, depending on what functionality you want
+ '(nx-mapper/stylor-mode:stylor-mode
+ nx-mapper/stylor-mode:rural-mode)
+ %slot-default%)))
#+end_src
Where =/path/to/mapper.lisp= is a custom file that should be created to provide the extension settings after the =nx-mapper= system has been successfully loaded. Inside this file, one can take two approaches when it comes to supplying the extension options, as described by the following.
+#+name: mapper.lisp
#+begin_src lisp
(define-configuration nx-mapper:settings
- ((nx-mapper/stylor-mode:scripts
- ;; provide all the mappings
- )
- ;; one can provide the additional extension slots
- ))
+ ;; provide all the mapping types
+)
#+end_src
-As one might notice from the above, one can bundle everything into the global =nx-mapper:settings= class, but optionally one can configure everything per sub-extension too.
+As one might notice from the above, one can bundle everything into the global =nx-mapper:settings= class, but optionally one can configure everything per sub-extension too, which is useful if you want to split the configuration of each mode per file, such as by having a =style.lisp= for =stylor-mode= and a =url.lisp= for =rural-mode=. The next section gives examples of how to structure and configure each.
+
+#+name: stylor.lisp
+#+begin_src lisp
+(define-configuration nx-mapper/stylor-mode:stylor-mode
+ ((nx-mapper/stylor-mode:auto-p t))) ;; Whether to set the browser theme according to system settings
-#+begin_src elisp
(define-configuration nx-mapper/stylor-mode:settings
- ;; stylor-mode slots
- )
+ ((nx-mapper/stylor-mode:scripts
+ ;; user script mappings
+ )
+ (nx-mapper/stylor-mode:external-themes
+ ;; user styles mappings
+ )
+ (nx-mapper/stylor-mode:internal-thems
+ ;; browser theme mappings
+ )))
+#+end_src
+
+#+name: rural.lisp
+#+begin_src lisp
+(define-configuration nx-mapper/rural-mode:rural-mode
+ ((nx-mapper/rural-mode:banner-p nil))) ;; Whether to show a blocked page when encountering a block rule
(define-configuration nx-mapper/rural-mode:settings
- ;; rural-mode slots
- )
+ ((nx-mapper/rural-mode:url-mappings
+ ;; URL associations mappings
+ )))
#+end_src
* Configuration
@@ -107,7 +131,7 @@ Therefore, using these three concepts, one could include the following configura
The above configuration initially defines a script mapping called =FSF= which matches on the =fsf.org= domain, thereby triggering the script provided by the =:script= initarg, which in this case will simply change the page's internal contents to effectively just show the string "/This was invoked by some sample JavaScript/".
-The next set of rules involve external themes, which carry the same principle as scripts in that it maps a set of predicates to an external style specified by the =:style= initarg. As previously outlined, this style can be in the form of a CSS string, such as the one specified by the =GitHub= mapping (which uses the library =cl-css= that compiles Common Lisp into a CSS string). This first mapping, for instance, gets rid of the number specifying how many people are watching a repository. It can also take a function that has the current active theme as argument, such as the example provided in the =Lisp Documentation= mapping, which will essentially provide the same background and text color as the current internal theme for the whole site. If the style sheet becomes too big or one would like to use their favorite editor to tweak it, one can optionally also provide a pathname pointing to the CSS file. Finally, if one has their styles remotely backed up or they stumble upon one they like, they can point to their URL and it will be applied.
+The next set of rules involve external themes, which carry the same principle as scripts in that it maps a set of predicates to an external style specified by the =:style= initarg. As previously outlined, this style can be in the form of a CSS string, such as the one specified by the =GitHub= mapping (which uses the library =cl-css= that compiles Common Lisp into a CSS string). This first mapping, for instance, gets rid of the number specifying how many people are watching a repository. The =style= slot can also take a function that has the current active theme as argument, such as the example provided in the =Lisp Documentation= mapping, which will essentially provide the same background and text color as the current internal theme for the whole site. If the style sheet becomes too big or one would like to use their favorite editor to tweak it, one can optionally also provide a pathname pointing to the CSS file. Finally, if one has their styles remotely backed up or they stumble upon one they like, they can point to their URL and it will be applied.
Finally, there's the internal themes rules, where as we can see from the above we have to issue a name for the mapping, and then a set of theme attributes which are built into the =nyxt/theme= library that ships with the browser as of version =2.2.4=. In addition to these, each internal theme can take a "/stylist/", described as a custom style /crafter/ that allows one to style specific elements of the browser's interface if they aren't satisfied with a given one, such as the layout of the mode line. A stylist effectively aims at reducing the complexity associated with having to manually define the =style= slot of many user classes, and can be defined as follows.
@@ -238,7 +262,7 @@ Finally, there's the internal themes rules, where as we can see from the above w
:z-index #.(1- (expt 2 31))))))))
#+end_src
-This is an example stylist which I use in my configuration for a more compact and minimal interface to the browser, which looks like the following, but one is welcome to change each style slot as they see fit.
+This is an example stylist which I use in my configuration for a more compact and minimal interface to the browser, which looks like the following, but one is welcome to change each style slot as they see fit. Also, worth noting is that this is the default stylist, but one can pass any stylist object to an internal theme to tweak the appearance per theme.
[[file:assets/stylist-dark.jpg]]