From 4ea1360db4eca349ab37dfd3a16831e93c5b4ff9 Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Sat, 2 Nov 2024 00:45:24 +0000 Subject: [PATCH] build based on e4c9e8e --- dev/index.html | 2 +- dev/lib/internals/index.html | 4 ++-- dev/lib/public/index.html | 2 +- dev/man/extending_ls/index.html | 2 +- dev/man/functionalities/index.html | 2 +- dev/man/ls+lit/index.html | 2 +- dev/search/index.html | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/dev/index.html b/dev/index.html index a77f3a0..6cd5871 100644 --- a/dev/index.html +++ b/dev/index.html @@ -21,4 +21,4 @@ │   └── TestImage.png ├── index.html └── pages - └── blah.html

Calling serve() from within this directory starts a file server. It serves the contents of the directory as a static site, with the folder structure defining the paths of the URLs. That is, the file blah.html can be viewed at /pages/blah.html. When a directory is specified instead of a file, the server checks whether there is a file index.html in this directory and serves it if available.

Visiting http://localhost:8000/ makes your browser send a standard HTTP GET request to the server. The server, running a listener loop, receives this request, looks for index.html in the root folder, and serves it. After serving it, LiveServer adds this file to the list of watched files. That is, whenever this file changes, a callback is fired (see below). The HTML page may also contain references to style sheets or pictures, which are then requested by your browser as well. The server sends them to the browser, and also adds them to the list of watched files.

But what about the live reloading?

Triggering a page refresh in the browser is achieved by a WebSocket connection. The WebSocket API, according to MDN, is

an advanced technology that makes it possible to open a two-way interactive communication session between the user's browser and a server.

LiveServer injects a small piece of JavaScript code into every HTML file before serving it. This snippet is executed by the browser and opens a WebSocket connection to the server, which in turn adds it to a list of viewers of this page.

The server can now send the message "update" to all viewers of a page whenever the page is changed. The code snippet reacts to this message by triggering a page reload. The update is triggered by the callback mentioned above. When the file is not an HTML file, the viewers of any HTML file are updated, since LiveServer currently does not keep track of which HTML files reference what other files.

+ └── blah.html

Calling serve() from within this directory starts a file server. It serves the contents of the directory as a static site, with the folder structure defining the paths of the URLs. That is, the file blah.html can be viewed at /pages/blah.html. When a directory is specified instead of a file, the server checks whether there is a file index.html in this directory and serves it if available.

Visiting http://localhost:8000/ makes your browser send a standard HTTP GET request to the server. The server, running a listener loop, receives this request, looks for index.html in the root folder, and serves it. After serving it, LiveServer adds this file to the list of watched files. That is, whenever this file changes, a callback is fired (see below). The HTML page may also contain references to style sheets or pictures, which are then requested by your browser as well. The server sends them to the browser, and also adds them to the list of watched files.

But what about the live reloading?

Triggering a page refresh in the browser is achieved by a WebSocket connection. The WebSocket API, according to MDN, is

an advanced technology that makes it possible to open a two-way interactive communication session between the user's browser and a server.

LiveServer injects a small piece of JavaScript code into every HTML file before serving it. This snippet is executed by the browser and opens a WebSocket connection to the server, which in turn adds it to a list of viewers of this page.

The server can now send the message "update" to all viewers of a page whenever the page is changed. The code snippet reacts to this message by triggering a page reload. The update is triggered by the callback mentioned above. When the file is not an HTML file, the viewers of any HTML file are updated, since LiveServer currently does not keep track of which HTML files reference what other files.

diff --git a/dev/lib/internals/index.html b/dev/lib/internals/index.html index f6a53a1..5d2b94f 100644 --- a/dev/lib/internals/index.html +++ b/dev/lib/internals/index.html @@ -1,4 +1,4 @@ -Internals · LiveServer.jl
Edit on GitHub

Internal Interface

Documentation for LiveServer.jl's internal interface

File watching

There are two key types related to file watching:

  1. one to wrap a file being watched (LiveServer.WatchedFile),
  2. one for the file watcher itself wrapping the list of watched files and what to do upon file changes ("callback" function)

Any file watcher will be a subtype of the abstract type LiveServer.FileWatcher with, for instance, the default watcher being LiveServer.SimpleWatcher.

WatchedFile

LiveServer.WatchedFile — Type
WatchedFile

Struct for a file being watched containing the path to the file as well as the time of last modification.

source
LiveServer.has_changed — Function
has_changed(wf::WatchedFile)

Check if a WatchedFile has changed. Returns -1 if the file does not exist, 0 if it does exist but has not changed, and 1 if it has changed.

source

FileWatcher

Key types

LiveServer.SimpleWatcher — Type
SimpleWatcher([callback]; sleeptime::Float64=0.1) <: FileWatcher

A simple file watcher. You can specify a callback function, receiving the path of each file that has changed as an AbstractString, at construction or later by the API function set_callback!. The sleeptime is the time waited between two runs of the loop looking for changed files, it is constrained to be at least 0.05s.

source
LiveServer.start — Function
start(fw::FileWatcher)

Start the file watcher and wait to make sure the task has started.

source
LiveServer.stop — Function
stop(fw::FileWatcher)

Stop the file watcher. The list of files being watched is preserved and new files can still be added to the file watcher using watch_file!. It can be restarted with start. Returns a Bool indicating whether the watcher was running before stop was called.

source
LiveServer.set_callback! — Function
set_callback!(fw::FileWatcher, callback::Function)

Set or change the callback function being executed upon a file change. Can be "hot-swapped", i.e. while the file watcher is running.

source
LiveServer.file_watcher_task! — Function
file_watcher_task!(w::FileWatcher)

Helper function that's spawned as an asynchronous task and checks for file changes. This task is normally terminated upon an InterruptException and shows a warning in the presence of any other exception.

source

Additional helper functions:

LiveServer.is_watched — Function
is_watched(fw::FileWatcher, f_path::AbstractString)

Checks whether the file specified by f_path is being watched.

source

Live serving

The serve method instantiates a listener (HTTP.listen) in an asynchronous task. The callback upon an incoming HTTP stream decides whether it is a standard HTTP request or a request for an upgrade to a websocket connection. The former case is handled by LiveServer.serve_file, the latter by LiveServer.ws_tracker. Finally, LiveServer.file_changed_callback is the function passed to the file watcher to be executed upon file changes.

LiveServer.serve_file — Function
serve_file(fw, req::HTTP.Request; inject_browser_reload_script = true)

Handler function for serving files. This takes a file watcher, to which files to be watched can be added, and a request (e.g. a path entered in a tab of the browser), and converts it to the appropriate file system path.

The cases are as follows:

  1. FILE: the path corresponds exactly to a file. If it's a html-like file, LiveServer will try injecting the reloading <script> (see file client.html) at the end, just before the </body> tag. Otherwise we let the browser attempt to show it (e.g. if it's an image).
  2. WEB-DIRECTORY: the path corresponds to a directory in which there is an index.html, same action as (1) assuming the index.html is implicit.
  3. PLAIN-DIRECTORY: the path corresponds to a directory in which there is not an index.html, list the directory contents.
  4. 404: not (1,2,3), a 404 is served.

All files served are added to the file watcher, which is responsible to check whether they're already watched or not. Finally the file is served via a 200 (successful) response. If the file does not exist, a response with status 404 and message is returned.

source
Missing docstring.

Missing docstring for LiveServer.ws_upgrade. Check Documenter's build log for details.

LiveServer.ws_tracker — Function
ws_tracker(ws::HTTP.WebSockets.WebSocket, target::AbstractString)

Adds the websocket connection to the viewers in the global dictionary WS_VIEWERS to the entry corresponding to the targeted file.

source
LiveServer.file_changed_callback — Function
file_changed_callback(f_path::AbstractString)

Function reacting to the change of the file at f_path. Is set as callback for the file watcher.

source

Additional helper functions:

LiveServer.get_fs_path — Function
get_fs_path(req_path::AbstractString; silent=false)

Return the filesystem path corresponding to a requested path, or an empty String if the file was not found.

Cases:

  • an explicit request to an existing index.html (e.g. foo/bar/index.html) is given –> serve the page and change WEB_DIR unless a parent dir should be preferred (e.g. foo/ has an index.html)
  • an implicit request to an existing index.html (e.g. foo/bar/ or foo/bar) is given –> same as previous case after appending the index.html
  • a request to a file is given (e.g. /sample.jpeg) –> figure out what it is relative to, reconstruct the full system path and serve the file
  • a request for a dir without index is given (e.g. foo/bar) –> serve a dedicated index file listing the content of the directory.
source
LiveServer.update_and_close_viewers! — Function
update_and_close_viewers!(wss::Vector{HTTP.WebSockets.WebSocket})

Take a list of viewers, i.e. WebSocket connections from a client, send a message with data "update" to each of them (to trigger a page reload), then close the connection. Finally, empty the list since all connections are closing anyway and clients will re-connect from the re-loaded page.

source

Helper functions associated with servedocs

LiveServer.servedocs_callback! — Function
servedocs_callback!(args...)

Custom callback used in servedocs triggered when a file is modified.

If the file is docs/make.jl, the callback will check whether any new files have subsequently been generated in the docs/src folder and add them to the watched files, it will also remove any file that may have been deleted or renamed.

If the file is either in docs/src, a pass of Documenter is triggered to regenerate the documentation, subsequently the LiveServer will render the pages produced in docs/build.

Arguments

See the docs of the parent function servedocs.

source
LiveServer.scan_docs! — Function
scan_docs!(dw::SimpleWatcher, args...)

Scans the docs/ folder and add all relevant files to the watched files.

Arguments

See the docs of the parent function servedocs.

source

Miscellaneous

LiveServer.example — Function
example()

Simple function to copy an example website folder to the current working directory that can be watched by the LiveServer to get an idea of how things work.

Example

LiveServer.example()
+Internals · LiveServer.jl
Edit on GitHub
Internal Interface
Documentation for LiveServer.jl's internal interface
File watching
There are two key types related to file watching:
  1. one to wrap a file being watched (LiveServer.WatchedFile),
  2. one for the file watcher itself wrapping the list of watched files and what to do upon file changes ("callback" function)
Any file watcher will be a subtype of the abstract type LiveServer.FileWatcher with, for instance, the default watcher being LiveServer.SimpleWatcher.
WatchedFile
LiveServer.WatchedFile — Type
WatchedFile
Struct for a file being watched containing the path to the file as well as the time of last modification.
source
LiveServer.has_changed — Function
has_changed(wf::WatchedFile)
Check if a WatchedFile has changed. Returns -1 if the file does not exist, 0 if it does exist but has not changed, and 1 if it has changed.
source
FileWatcher
Key types
LiveServer.SimpleWatcher — Type
SimpleWatcher([callback]; sleeptime::Float64=0.1) <: FileWatcher
A simple file watcher. You can specify a callback function, receiving the path of each file that has changed as an AbstractString, at construction or later by the API function set_callback!. The sleeptime is the time waited between two runs of the loop looking for changed files, it is constrained to be at least 0.05s.
source
LiveServer.start — Function
start(fw::FileWatcher)
Start the file watcher and wait to make sure the task has started.
source
LiveServer.stop — Function
stop(fw::FileWatcher)
Stop the file watcher. The list of files being watched is preserved and new files can still be added to the file watcher using watch_file!. It can be restarted with start. Returns a Bool indicating whether the watcher was running before stop was called.
source
LiveServer.set_callback! — Function
set_callback!(fw::FileWatcher, callback::Function)
Set or change the callback function being executed upon a file change. Can be "hot-swapped", i.e. while the file watcher is running.
source
LiveServer.file_watcher_task! — Function
file_watcher_task!(w::FileWatcher)
Helper function that's spawned as an asynchronous task and checks for file changes. This task is normally terminated upon an InterruptException and shows a warning in the presence of any other exception.
source
Additional helper functions:
LiveServer.is_watched — Function
is_watched(fw::FileWatcher, f_path::AbstractString)
Checks whether the file specified by f_path is being watched.
source
Live serving
The serve method instantiates a listener (HTTP.listen) in an asynchronous task. The callback upon an incoming HTTP stream decides whether it is a standard HTTP request or a request for an upgrade to a websocket connection. The former case is handled by LiveServer.serve_file, the latter by LiveServer.ws_tracker. Finally, LiveServer.file_changed_callback is the function passed to the file watcher to be executed upon file changes.
LiveServer.serve_file — Function
serve_file(fw, req::HTTP.Request; inject_browser_reload_script = true)
Handler function for serving files. This takes a file watcher, to which files to be watched can be added, and a request (e.g. a path entered in a tab of the browser), and converts it to the appropriate file system path.
The cases are as follows:
  1. FILE: the path corresponds exactly to a file. If it's a html-like file,  LiveServer will try injecting the reloading <script> (see file  client.html) at the end, just before the </body> tag. Otherwise  we let the browser attempt to show it (e.g. if it's an image).
  2. WEB-DIRECTORY: the path corresponds to a directory in which there is an  index.html, same action as (1) assuming the index.html is implicit.
  3. PLAIN-DIRECTORY: the path corresponds to a directory in which there is not  an index.html, list the directory contents.
  4. 404: not (1,2,3), a 404 is served.
All files served are added to the file watcher, which is responsible to check whether they're already watched or not. Finally the file is served via a 200 (successful) response. If the file does not exist, a response with status 404 and message is returned.
source
Missing docstring.
Missing docstring for LiveServer.ws_upgrade. Check Documenter's build log for details.
LiveServer.ws_tracker — Function
ws_tracker(ws::HTTP.WebSockets.WebSocket, target::AbstractString)
Adds the websocket connection to the viewers in the global dictionary WS_VIEWERS to the entry corresponding to the targeted file.
source
LiveServer.file_changed_callback — Function
file_changed_callback(f_path::AbstractString)
Function reacting to the change of the file at f_path. Is set as callback for the file watcher.
source
Additional helper functions:
LiveServer.get_fs_path — Function
get_fs_path(req_path::AbstractString; silent=false)
Return the filesystem path corresponding to a requested path, or an empty String if the file was not found.
Cases:
  • an explicit request to an existing index.html (e.g.   foo/bar/index.html) is given –> serve the page and change WEB_DIR   unless a parent dir should be preferred (e.g. foo/ has an index.html)
  • an implicit request to an existing index.html (e.g. foo/bar/ or   foo/bar) is given –> same as previous case after appending the   index.html
  • a request to a file is given (e.g. /sample.jpeg) –> figure out what it   is relative to, reconstruct the full system path and serve the file
  • a request for a dir without index is given (e.g. foo/bar) –> serve a       dedicated index file listing the content of the directory.
source
LiveServer.update_and_close_viewers! — Function
update_and_close_viewers!(wss::Vector{HTTP.WebSockets.WebSocket})
Take a list of viewers, i.e. WebSocket connections from a client, send a message with data "update" to each of them (to trigger a page reload), then close the connection. Finally, empty the list since all connections are closing anyway and clients will re-connect from the re-loaded page.
source
Helper functions associated with servedocs
LiveServer.servedocs_callback! — Function
servedocs_callback!(args...)
Custom callback used in servedocs triggered when a file is modified.
If the file is docs/make.jl, the callback will check whether any new files have subsequently been generated in the docs/src folder and add them to the watched files, it will also remove any file that may have been deleted or renamed.
If the file is either in docs/src, a pass of Documenter is triggered to regenerate the documentation, subsequently the LiveServer will render the pages produced in docs/build.
Arguments
See the docs of the parent function servedocs.
source
LiveServer.scan_docs! — Function
scan_docs!(dw::SimpleWatcher, args...)
Scans the docs/ folder and add all relevant files to the watched files.
Arguments
See the docs of the parent function servedocs.
source
Miscellaneous
LiveServer.example — Function
example()
Simple function to copy an example website folder to the current working directory that can be watched by the LiveServer to get an idea of how things work.
Example
LiveServer.example()
 cd("example")
-serve()
source
Missing docstring.
Missing docstring for LiveServer.set_verbose. Check Documenter's build log for details.

+serve()
source
Missing docstring.

Missing docstring for LiveServer.set_verbose. Check Documenter's build log for details.

diff --git a/dev/lib/public/index.html b/dev/lib/public/index.html index 91bbf56..e0b113b 100644 --- a/dev/lib/public/index.html +++ b/dev/lib/public/index.html @@ -1,2 +1,2 @@ -Public · LiveServer.jl
Edit on GitHub

Public Interface

Documentation for LiveServer.jl's exported functions

LiveServer.serve — Function
serve(filewatcher; ...)

Main function to start a server at http://host:port and render what is in the current directory. (See also example for an example folder).

Arguments

  • filewatcher: a file watcher implementing the API described for SimpleWatcher (which also is the default) messaging the viewers (via WebSockets) upon detecting file changes.
  • port: integer
  • dir: string specifying where to launch the server if not the current working directory.
  • debug: bolean switch to make the server print debug messages.
  • verbose: boolean switch to make the server print information about file changes and connections.
  • coreloopfun: function which can be run every 0.1 second while the server is running; it takes two arguments: the cycle counter and the filewatcher. By default the coreloop does nothing.
  • launch_browser: boolean specifying whether to launch the ambient browser at the localhost or not (default: false).
  • allow_cors: boolean allowing cross origin (CORS) requests to access the server via the "Access-Control-Allow-Origin" header.
  • preprocess_request: function specifying the transformation of a request before it is returned; its only argument is the current request.
  • inject_browser_reload_script: boolean specifying whether the live-reloading functionality should be injected into HTML pages when served.

Example

julia LiveServer.example() serve(host="127.0.0.1", port=8080, dir="example", launch_browser=true)

You should then see the index.html page from the example folder being rendered. If you change the file, the browser will automatically reload the page and show the changes.

source
LiveServer.servedocs — Function
servedocs(; kwargs...)

Can be used when developing a package to run the docs/make.jl file from Documenter.jl and then serve the docs/build folder with LiveServer.jl. This function assumes you are in the directory [MyPackage].jl with a subfolder docs.

Keyword Arguments

  • verbose=false: boolean switch to make the server print information about file changes and connections.
  • literate=nothing: see literate_dir.
  • literate_dir=nothing: Path to a directory containing Literate scripts if these are not simply under docs/src. See also the docs for information about how to work with Literate.
  • skip_dir="": a path starting with docs/ where modifications should not trigger the generation of the docs, this is useful for instance if you're using Weave and Weave generates some files in docs/src/examples in which case you should set skip_dir=joinpath("docs","src","examples").
  • skip_dirs=[]: same as skip_dir but for a list of such dirs. Takes precedence over skip_dir.
  • skip_files=[]: a vector of files that should not trigger regeneration.
  • include_dirs=[]: extra source directories to watch (in addition to joinpath(foldername, "src")).
  • include_files=[]: extra source files to watch. Takes precedence over skip_dirs so can e.g. be used to track individual files in an otherwise skipped directory.
  • foldername="docs": specify a different path for the content.
  • buildfoldername="build": specify a different path for the build.
  • makejl="make.jl": path of the script generating the documentation relative to foldername.
  • host="127.0.0.1": where the server will start.
  • port=8000: port number.
  • launch_browser=false: specifies whether to launch a browser at the localhost URL or not.
source
+Public · LiveServer.jl
Edit on GitHub

Public Interface

Documentation for LiveServer.jl's exported functions

LiveServer.serve — Function
serve(filewatcher; ...)

Main function to start a server at http://host:port and render what is in the current directory. (See also example for an example folder).

Arguments

  • filewatcher: a file watcher implementing the API described for SimpleWatcher (which also is the default) messaging the viewers (via WebSockets) upon detecting file changes.
  • port: integer
  • dir: string specifying where to launch the server if not the current working directory.
  • debug: bolean switch to make the server print debug messages.
  • verbose: boolean switch to make the server print information about file changes and connections.
  • coreloopfun: function which can be run every 0.1 second while the server is running; it takes two arguments: the cycle counter and the filewatcher. By default the coreloop does nothing.
  • launch_browser: boolean specifying whether to launch the ambient browser at the localhost or not (default: false).
  • allow_cors: boolean allowing cross origin (CORS) requests to access the server via the "Access-Control-Allow-Origin" header.
  • preprocess_request: function specifying the transformation of a request before it is returned; its only argument is the current request.
  • inject_browser_reload_script: boolean specifying whether the live-reloading functionality should be injected into HTML pages when served.

Example

julia LiveServer.example() serve(host="127.0.0.1", port=8080, dir="example", launch_browser=true)

You should then see the index.html page from the example folder being rendered. If you change the file, the browser will automatically reload the page and show the changes.

source
LiveServer.servedocs — Function
servedocs(; kwargs...)

Can be used when developing a package to run the docs/make.jl file from Documenter.jl and then serve the docs/build folder with LiveServer.jl. This function assumes you are in the directory [MyPackage].jl with a subfolder docs.

Keyword Arguments

  • verbose=false: boolean switch to make the server print information about file changes and connections.
  • literate=nothing: see literate_dir.
  • literate_dir=nothing: Path to a directory containing Literate scripts if these are not simply under docs/src. See also the docs for information about how to work with Literate.
  • skip_dir="": a path starting with docs/ where modifications should not trigger the generation of the docs, this is useful for instance if you're using Weave and Weave generates some files in docs/src/examples in which case you should set skip_dir=joinpath("docs","src","examples").
  • skip_dirs=[]: same as skip_dir but for a list of such dirs. Takes precedence over skip_dir.
  • skip_files=[]: a vector of files that should not trigger regeneration.
  • include_dirs=[]: extra source directories to watch (in addition to joinpath(foldername, "src")).
  • include_files=[]: extra source files to watch. Takes precedence over skip_dirs so can e.g. be used to track individual files in an otherwise skipped directory.
  • foldername="docs": specify a different path for the content.
  • buildfoldername="build": specify a different path for the build.
  • makejl="make.jl": path of the script generating the documentation relative to foldername.
  • host="127.0.0.1": where the server will start.
  • port=8000: port number.
  • launch_browser=false: specifies whether to launch a browser at the localhost URL or not.
source
diff --git a/dev/man/extending_ls/index.html b/dev/man/extending_ls/index.html index fd46470..664bcf3 100644 --- a/dev/man/extending_ls/index.html +++ b/dev/man/extending_ls/index.html @@ -17,4 +17,4 @@ # cleanup ... end return nothing -end

That is, the coreloopfun is called roughly every 100 ms while the server is running. By default the coreloopfun does nothing.

An example where this mechanism could be used is when your code handles the processing of files from one format (say markdown) to HTML. You want the FileWatcher to trigger browser reloads whenever new versions of these HTML files are produced. However, at the same time, you want another process to keep track of the markdown files and re-process them as they change. You can hook this second watcher into the core loop of LiveServer using the coreloopfun. An example for this use case is JuDoc.jl.

Why not use FileWatching?

You may be aware of the FileWatching module in Base and may wonder why we did not just use that one. The main reasons we decided not to use it are:

So ultimately, our system can be seen as a poor man's implementation of FileWatching that is robust, simple and easy to customise.

+end

That is, the coreloopfun is called roughly every 100 ms while the server is running. By default the coreloopfun does nothing.

An example where this mechanism could be used is when your code handles the processing of files from one format (say markdown) to HTML. You want the FileWatcher to trigger browser reloads whenever new versions of these HTML files are produced. However, at the same time, you want another process to keep track of the markdown files and re-process them as they change. You can hook this second watcher into the core loop of LiveServer using the coreloopfun. An example for this use case is JuDoc.jl.

Why not use FileWatching?

You may be aware of the FileWatching module in Base and may wonder why we did not just use that one. The main reasons we decided not to use it are:

So ultimately, our system can be seen as a poor man's implementation of FileWatching that is robust, simple and easy to customise.

diff --git a/dev/man/functionalities/index.html b/dev/man/functionalities/index.html index f9a7616..cf76b6d 100644 --- a/dev/man/functionalities/index.html +++ b/dev/man/functionalities/index.html @@ -29,4 +29,4 @@ ... Rest of configuration within your make.jl file =#
  1. Finally the user should start the LiveServer session with an additional

argument to watch the package src/ folder for changes. This additional argument will force LiveServer to watch the src/ folder for changes and re-render the documentation site once LiveServer notices a change.

using LiveServer
-servedocs(include_dirs=["src/"])

Once these change are completed, changes to a function's docstring will trigger a re-rendering of the documentation website in the user's browser.

Additional keywords

The servedocs function now takes extra keywords which may, in some cases, make your life easier:

Note that in latter two cases these keywords are there for your convenience but would be best not used. See also the discussion in this issue. In the first case, doing

julia --project=docs -e 'using LiveServer; servedocs()'

is more robust.

In the second case, it would be best if you made sure that all generated files are saved in docs/build/....

+servedocs(include_dirs=["src/"])

Once these change are completed, changes to a function's docstring will trigger a re-rendering of the documentation website in the user's browser.

Additional keywords

The servedocs function now takes extra keywords which may, in some cases, make your life easier:

Note that in latter two cases these keywords are there for your convenience but would be best not used. See also the discussion in this issue. In the first case, doing

julia --project=docs -e 'using LiveServer; servedocs()'

is more robust.

In the second case, it would be best if you made sure that all generated files are saved in docs/build/....

diff --git a/dev/man/ls+lit/index.html b/dev/man/ls+lit/index.html index 1100d4e..a8d9691 100644 --- a/dev/man/ls+lit/index.html +++ b/dev/man/ls+lit/index.html @@ -41,4 +41,4 @@ └── literate_script.md

in this case we can call 

servedocs(
     literate=joinpath("foo", "literate"),
     skip_dir=joinpath("docs", "src", "generated")
-)

since

  1. the literate scripts are under a dedicated folder,
  2. the generated markdown files do not have exactly the same relative path (since there is the added generated in the path).
+)

since

  1. the literate scripts are under a dedicated folder,
  2. the generated markdown files do not have exactly the same relative path (since there is the added generated in the path).
diff --git a/dev/search/index.html b/dev/search/index.html index d601fe6..b0fe2c5 100644 --- a/dev/search/index.html +++ b/dev/search/index.html @@ -1,2 +1,2 @@ -Search · LiveServer.jl

Loading search...

    +Search · LiveServer.jl

    Loading search...