Browsing of SuperTXT is possible with out of the box tools, such as cat and ssh. The lightweight markup is designed in this way where the source representation is meant to be as readable as any rendered form. However, the manual assembly of commands from previous commands and path names on link lines is something that can and should be automated as long as it is not hidden from the user. This is where shells can push the state of the user experience into the realm of a browser capable of navigating links with ease.
On the surface a browser is based on a simple command and execution pattern much like an interactive shell with some superficial differences. The command is either a URL or search engine query instead of a shell command, and it's generally (but not always) typed into the top of the window instead of the bottom. Historical navigation is done using scrolling instead of back/forward buttons. What's missing from a typical operating system shell is the ability to gesture on a hyperlink in output and assemble a command that will fetch it.
Let's start from a shell screen that looks like this.
When you gesture on the link it creates a new command to fetch it.
Before the new command is run the shell gives you an opportunity to see what is run. SuperTXT values this kind of transparency. If a site tries to assemble an unexpected command, such as rm, you'll be seeing that before it can cause problems.
Finally, upon completion the screen might look something like this.
This is the typical browsing flow and it's something that a traditional shell might support someday. Meanwhile, there is the browsing shell (brsh) that can do this today. You an install it using [:@homebrew] and a tap to give it a try.
brew tap supertxt/tap ssh://nobody@supertxt.net/git/st-brew brew install supertxt/tap/cats supertxt/tap/brsh brsh # Start the browsing shell into a new window
Navigating links is accomplished via a special Alt-click gesture in brsh. There are more detailed usage instructions in the built-in help command.
A shell can run any command available on the system, even user defined ones. The shell cannot know about the argument structure and input of all commands. What's needed in a way for the shell to ask a command to perform certain operations, such as the redirection of an initial set of arguments to a link that came from its output. This sort of operation is called reflection. It works with a special command-line flag called "--srefl" and the type of reflection being requested. The shell will run these sorts of operations on the command to see if it is able to compute a redirection. In the typical flow above this is how the shell reflects on the command to get the redirection.
echo "doc-xyz.s.txt" | cats --srefl=redirect nobody@somesite.net:doc-1.s.txt
If the command supports this kind of reflection and can calculate the new command then it outputs the result to standard out so that the shell puts that in the next command-line.
cats nobody@somesite.net:doc-xyz.s.txt
There are other types of reflective operations too, such as the expected file extension for a command. The brsh uses that to decide what kind of viewer to use for the output. There is a command reflection [:@specification] with more details about how each type works.
HAVE SOME FEEDBACK ON THIS DOCUMENT?
You can provide a conventional comment on this document.
ssh nobody@supertxt.net ccmnt browsing.s.txt <<EOF suggestion: Here's my actionable suggestion. EOF