In my sci-fi novel, when characters speak with their home automation system, they always have to follow the same format: "Tau, <insert request here>, please." It's that "please" at the end that solves the stopped speaking problem.
Am looking for alpha readers! (See profile for contact details.)
Dang that just planted the visual in my head of talking to AI over walkie talkie. Not a bad interface. Push to talk, if it takes a few seconds or even a few minutes for a response to come back, not a big deal.
> [Fort Langley] dates from a time when the boundary between British and American possession of the trans-mountain west, known as the Columbia District had not yet been decided.
> With the creation of the Crown Colony on the British mainland north of the then-Washington Territory in 1858, Queen Victoria chose to use Columbia District as the basis for the name Colony of British Columbia, i.e. the remaining British portion of the former Columbia District.
The first four parts of my Typesetting Markdown blog describes improving the user-friendliness of bash scripts. In particular, you can use bash to define a reusable script that allows isolating software dependencies, command-line arguments, and parsing.
In effect, create a list of dependencies and arguments:
#!/usr/bin/env bash
source $HOME/bin/build-template
DEPENDENCIES=(
"gradle,https://gradle.org"
"warp-packer,https://github.com/Reisz/warp/releases"
"linux-x64.warp-packer,https://github.com/dgiagio/warp/releases"
"osslsigncode,https://www.winehq.org"
)
ARGUMENTS+=(
"a,arch,Target operating system architecture (amd64)"
"o,os,Target operating system (linux, windows, macos)"
"u,update,Java update version number (${ARG_JAVA_UPDATE})"
"v,version,Full Java version (${ARG_JAVA_VERSION})"
)
The build-template can then be reused to enhance other shell scripts. Note how by defining the command-line arguments as data you can provide a general solution to printing usage information:
If you want further generalization, it's possible to have the template parse the command-line arguments automatically for any particular script. Tweak the arguments list slightly by prefixing the name of the variable to assign to the option value provided on the CLI:
ARGUMENTS+=(
"ARG_JAVA_ARCH,a,arch,Target operating system architecture (amd64)"
"ARG_JAVA_OS,o,os,Target operating system (linux, windows, macos)"
"ARG_JAVA_UPDATE,u,update,Java update version number (${ARG_JAVA_UPDATE})"
"ARG_JAVA_VERSION,v,version,Full Java version (${ARG_JAVA_VERSION})"
)
If the command-line options require running different code, it is possible to accommodate that as well, in a reusable solution.
* The ordered list isn't the best way to write numbered lists. Numbered lists can be: 1. 1. 1., etc. The computer will auto-increment.
* Typographic quotes are an extension. I wrote KeenQuotes[0] to solve the quote curling problem and integrated it into KeenWrite[1].
* Document header. I fundamentally disagree with putting formatting instructions into plain text documents, in either AsciiDoc or Markdown. I wrote KeenWrite to completely separate the two. Documents are typeset using ConTeXt[2] and a theme[3].
* Admonitions. Pandoc (and KeenWrite) supports annotations in Markdown. I used them on page 5 of my Impacts Project[4] to insert the spectra. I'd say that annotations are more flexible than admonitions because admonitions are often canned (TIP, WARNING, etc.); whereas, annotations are user-defined.
* Sidebars and block titles imply presentation. These are also handled by annotations.
* Includes. You can use R Markdown to get includes. Or write an extension. Fair point that it isn't bundled, though.
* Custom CSS. Again, avoid mixing presentation and content. Specific presentation logic can be applied by annotating the content, rather than trying to format plain text as though it was HTML.
* Definition lists. Supported by Markdown, I use them for a glossary in a novel I'm writing.
* Tables. While perhaps not CommonMark, basic tables are widely supported by almost all Markdown implementations.
There's a fair amount of incorrect, biased, or outdated information on that page.
Here's an example page written in Markdown and made into a PDF:
With that architecture, the source document format doesn't matter. Take any input document, transform it into a structured document format (such as XML), and then typeset it. Pandoc has a similar architecture.
The last screenshot shows a single source file having multiple themes applied, one being a manuscript theme.
The editor integrates variables in an external file so that if I want to change a character's name, I can do so in one place. Even diagrams (e.g., family tree) are updated.
In my novel (see profile), there are stories within the story as well as simultaneous actions. I wanted to typeset simultaneous events set within a sub-story. Using Markdown, a natural way to do this would be:
> ::: simul
> Simultaneous section 1.
> :::
>
> ::: simul
> Simultaneous section 2.
> :::
One of my minor bug bears is why we humans have to enter time into input fields in such rigid formats when there's a straightforward algorithm to make such inputs far more natural.
> One of my minor bug bears is why we humans have to enter time into input fields in such rigid formats when there's a straightforward algorithm to make such inputs far more natural.
GNU date supports very human-oriented date input, some examples:
$ date --date "today"
$ date --date "next sunday"
$ date --date "now + 3 hours"
$ date --date "3 months" # same as "now + 3 months"
$ date --date "5 december 2020"
$ date --date "oct 19 2007"
$ date --date "08:00"
$ date --date "8:00"
$ date --date "0800"
$ date --date "0800 UTC"
Does that mean that in your country, the day is considered to start at 1:00 AM rather than midnight? That choice is very strange when combined with the choice to call midnight "0:00" rather than "12:00 PM".
No, we just don't use AM/PM. In written language, the 24 hour format is used exclusively. When the 12 hour format is used in spoken language, we either leave it out entirely when clear from context, or use "in the morning" vs "in the evening".
So noon is "12 in the morning", which is an hour after "11 in the morning"; and midnight is "12 in the evening", which is an hour after "11 in the evening".
That's not really compatible with your comment about the US. By your own description, you do exactly the same thing that the US does,† but it's only strange when the US does it?
† That is, you follow 11:00 PM with 12:00 AM, and you don't actually refer to "AM" or "PM". Both of those are normal US practice. You are different in the use of 24-hour formats in writing, but that has no bearing on the question of whether the hour following 11 PM is 12 AM; you just assured me that that's true in both countries.
In my sci-fi novel, when characters speak with their home automation system, they always have to follow the same format: "Tau, <insert request here>, please." It's that "please" at the end that solves the stopped speaking problem.
Am looking for alpha readers! (See profile for contact details.)
reply