You are looking for cmd.pager.nextBuffer/prevBuffer, which the about:chawan screen lists as , (comma) or . (period). Looks like I forgot to add these to the docs; thanks for reporting.

(BTW, it's not just a stack, it's a full-blown tree. There are even nextSiblingBuffer, prevSiblingBuffer, and parentBuffer commands; however, there is currently no way to display the tree, so actually trying to use it as one gets very disorienting.)

I was worried there this may be a rtfm moment. Do you have any ideas for the visualisations? I've yet to make use of undo trees & the like myself yet but it's nice to know this is in place.

Would displaying the tree via html, or possibly gemtext seeing as this is supported be preferable as opposed to a tui overlay?

Ah, I see you made mention of this on your todo. I think a w3m style approach would be ideal as the existing can be leveraged for search & navigation. I suppose that just leaves the protocol.

w3m has SELECT and SELECT_MENU. SELECT is a custom screen with its own event loop & hardcoded keybindings; SELECT_MENU is the same thing but with the menu widget.

The former kinda sucks; the latter is pretty good (because w3m's menu widget is pretty good).

Chawan has a menu widget too, BUT:

• It's only used for <select> tags, so I hardly ever use it. Therefore it's not as good as w3m's.
• I recently coupled it together with the container module; that was a mistake which must be undone first.
• w3m's SELECT_MENU is linear, but we have a tree. So we either have to linearize it, or find a way to stuff a tree into the menu widget. (How?)

It's an option, but seems hard.

The other one as you say is to do it "in HTML" i.e. with local CGI. Perhaps this is a bit less painful:

• pager sends a POST request to a local CGI program with a serialized buffer tree (say, in JSON) - for each buffer it includes buffer name, PID and children
• CGI program returns an HTML page with a nested list of buffers (see below), each linking to a URL like cha-cmd:select-buffer?pid=1234
• in gotoURL, special-case "cha-cmd:select-buffer" URLs to jump to the selected buffer when a link is clicked

This way, we can also extend it in the future to do other stuff, e.g. delete/move buffers.

As for the actual UI... it's a tree, so maybe nested lists? A nice thing about doing it in a buffer is that we don't have to worry about the tree overflowing the screen, so we can nest as much as we want.

Something like this would be nice:

<Chawan browser 0.1> about:chawan
└<Redirecting...> https://sr.ht/~bptato
│└<~bptato> https://sr.ht/~bptato/
│ └<chawan sources - sourcehut> https://sr.ht/~bptato/chawan/sources
│ │└<chawan: TUI Web Browser> https://sr.ht/~bptato/chawan/
│ │ └<chawan — sourcehut todo> https://todo.sr.ht/~bptato/chawan
│ │ └<chawan mailing lists> https://sr.ht/~bptato/chawan/lists
│ └<chawan sources - sourcehut> https://sr.ht/~bptato/chawan/sources
└<DuckDuckGo> https://lite.duckduckgo.com/lite/

(re gemtext: it's just autoconverted to HTML. You could use it, but drawing a clickable tree in gemtext sounds hard.)

I've since moved to a simple C program for managing my bookmarks. It's nothing fancy & has a tonne of edge cases unaddressed but I its a start for my use case & haven't had the need to hack on it more just yet.

I'm more inclined now to think that global bookmarking is a good way forwards, though it could be useful to include some example keybound / cmd bound scripts that showcase ideas for integrating global bookmarks.

I'm still unsure on how to structure TUI based programs to allow for embedding terminal overlays into programs, & at the moment I'm using slmenu in the tty to display bookmarks, grep through shell history, etc. It's nice not being dependent on a display server when working remote, but oddly doesn't seem very compatible with a tui programs (I probably need to learn more curses).

Do you think that allowing the user to pass in co-ordinates for embedded terminal be a sound way of piping inputs from other tui / interactive tty programs without loosing history of current buffer?

It's a little tangential & not much of an issue as I currently bind in my multiplexer a script which switches to then next available tag, & runs my bookmark selector & pipes the output to cha, but I do something think of other instances where it'd be nice to fetch output from other tui programs.

I'm interested to know if you're using a similar / different solution to bookmarking.

~tydes wrote:

I've since moved to a simple C program for managing my bookmarks. It's nothing fancy & has a tonne of edge cases unaddressed but I its a start for my use case & haven't had the need to hack on it more just yet.

I'm more inclined now to think that global bookmarking is a good way forwards, though it could be useful to include some example keybound / cmd bound scripts that showcase ideas for integrating global bookmarks.

I don't know what global bookmarks mean, maybe I'll have some ideas if you enlighten me :)

I'm still unsure on how to structure TUI based programs to allow for embedding terminal overlays into programs, & at the moment I'm using slmenu in the tty to display bookmarks, grep through shell history, etc. It's nice not being dependent on a display server when working remote, but oddly doesn't seem very compatible with a tui programs (I probably need to learn more curses).

I either use shell job control or CGIify programs (see bonus/git.cgi). The latter does need a CLI interface, though.

It hasn't occurred to me to use an external menu, that's an interesting approach.

Do you think that allowing the user to pass in co-ordinates for embedded terminal be a sound way of piping inputs from other tui / interactive tty programs without loosing history of current buffer?

What exactly do you mean by "embedded terminal"?

On piping: you will want to keep stdout as the tty, so I'd just use a temp file:

pager.extern(`printf 'give me a URL: '; read url; printf '%s\n' "$url" > /tmp/my_cha_url`);
pager.gotoURL(readFile("/tmp/my_cha_url"));

You could also use externFilterSource and redirect stdin to /dev/null, then you get a buffer with the command's output. I admit that's not an ideal solution; I'll add a separate externRead some time.

It's a little tangential & not much of an issue as I currently bind in my multiplexer a script which switches to then next available tag, & runs my bookmark selector & pipes the output to cha, but I do something think of other instances where it'd be nice to fetch output from other tui programs.

I'm interested to know if you're using a similar / different solution to bookmarking.

I temporarily switch over to w3m :P that's why M-b leads to the w3m bookmark file.

FWIW I've tried to port w3mbookmark to Chawan before, but stalled when I couldn't figure out how its security model works. (W3M_COOKIE is an eternal mystery.)

Switching browsers just to save a bookmark is somewhat annoying, so I might try my hand at it again soon.

This is the shell script i'm using for example (first one > 20 lines or so). https://git.sr.ht/~tydes/marksh A bunch of things that need to be addressed when I rewrite. Currently wrapping with a lazy alias using slmenu to select a filename from $BOOKMARKSDIR & export $BOOKMARKS before launching a marksh cmd. Still needs a lot of work but I still find this very primitive thing to be quite handy despite not being able to use it inside of other programs yet.

Nice. I'll take a further look into that approach.

When I say embedded teminal, perhaps what I mean is an interface for declaring either coordinates or tui ui snippets as means of extending the ui of an existing tui program in an arbitary way, primarily for forking a vt buf to launch sh scripts which have an element of interactive selection & also need to be ran within the context of the parent program to utilize it's state.

That said, I suppose the better option might be to take a few steps back, & launch a script in given tui that passes a state envar to a multiplexer to offload the vt forking & tui specifics & have the stdout be written to a tmp as you suggested.

Despite my bookmark script being very primitive I have been using to gen & launch a html page in cha for search & select using the -p flag. It's when I want interactive selections that I've been either closing chawan or jumping to another tag as to not lose the previous one's history. It means I end up with a bunch of tags & lose track of the history of each, so this will be a nice improvement.

I could use display service selections to sidestep this problem I suppose, but that'd be no good when remoting back home as I often do.

I've been making steady steps towards moving program/plugin specific things further back for portabilites sake (& fun / woe). I should be more clued up next time around.

Sorry for the ticket spam, & thanks for the suggestion. That does the trick in this case!

~tydes wrote:

This is the shell script i'm using for example (first one > 20 lines or so). https://git.sr.ht/~tydes/marksh

A bunch of things that need to be addressed when I rewrite. Currently wrapping with a lazy alias using slmenu to select a filename from $BOOKMARKSDIR & export $BOOKMARKS before launching a marksh cmd. Still needs a lot of work but I still find this very primitive thing to be quite handy despite not being able to use it inside of other programs yet.

As a small improvement to your make_page, you could use mailcap:

• add some extension to your bookmark file, e.g. "my_bookmark.book"
• add the extension to ~/.mime.types, like "text/x-my-bookmark book"
• add an option so that "marksh -p" prints the HTML to stdout
• add to ~/.mailcap an entry like

text/x-my-bookmark; BOOKMARK=%s marksh -p; x-htmloutput"

(You can also remove BOOKMARK=%s, then marksh will receive the bookmark file on stdin.)

Then, you could open it like

pager.gotoURL("file:/path/to/my_bookmark.book")

This turns your bookmark format into a first-class file type (like gemtext or markdown), so you can use U to reload the file after changing it, and sE or \ (backslash) to edit/view its source. Also, the browser will stream the input.

When I say embedded teminal, perhaps what I mean is an interface for declaring either coordinates or tui ui snippets as means of extending the ui of an existing tui program in an arbitary way, primarily for forking a vt buf to launch sh scripts which have an element of interactive selection & also need to be ran within the context of the parent program to utilize it's state.

If you mean putting a VT widget in every program, that's probably better done by the multiplexer. VT emulation is very hard - every such widget I've seen has annoying deficiencies.

If you just want to YOLO draw something on top of another program... well, you can do it in Chawan (disable suspend in extern), but that only works because of a bug, and I don't think the approach would work well in general.

That said, I suppose the better option might be to take a few steps back, & launch a script in given tui that passes a state envar to a multiplexer to offload the vt forking & tui specifics & have the stdout be written to a tmp as you suggested.

Yeah, this sounds more like something that could work universally.

[...]

Sorry for the ticket spam, & thanks for the suggestion. That does the trick in this case!

No problem :) LMK if you have more questions.

(Kind of) superseded by https://todo.sr.ht/~bptato/chawan/57.