octobanana

The majority of the program has been redesigned and rewritten since the initial post 50 days ago, so I thought it would be alright to make another one. The Show HN rules say that 'A major overhaul is probably ok'. Would that still classify this as a dupe? Honestly, I was just excited of the progress made and what I had learned, and wanted to share/discuss it with others.

I didn't engage in any kind of promotional voting. It's free software given away under the MIT license. I don't gain anything from other people using it.

Hello! My name is Brett. For the past couple years I've been teaching myself how to program and engineer software, with a focus on C++ and Linux.

Lately, I've been interested in learning how text-based user interface (TUI) programs such as vi, vim, or less are implemented. I decided the best way to learn would be to build and implement my own TUI program, without relying on existing TUI frameworks/libraries. I went with the core idea of the program being a text reader, and decided to call it Fltrdr.

Fltrdr, or flat-reader, is a TUI text reader that runs in the terminal. It is flat in the sense that the reader is word-based. New line characters and sequential whitespace is stripped from the input text, leaving the reader with a stream of words. The words are then presented one or more at a time, moving one word forward at a user defined words per minute (WPM) variable speed.

For the past two months, I've continued to build upon Fltrdr, learning much along the way. It's written in C++17 and is distributed under the MIT License. I wanted to share the progress that has been made since the initial release, and some of the challenges that I've encountered along the way.

Supporting Unicode text was the most challenging feature. At the start, I knew very little about Unicode, and even less about what a code unit, code point, or grapheme cluster was. After a lot of research, I ended up gaining a decent understanding of what needed to be done to support inputting, manipulating, and rendering UTF-8 text, including full-width CJK Unified Ideographs. I ended up using parts of the ICU library to provide certain UTF-8 algorithms to build a non-memory-owning string view class, an owning-memory string class, and a non-memory-owning string view regex iterator. A majority of the program had to be rewritten to support this, all the way down to the keyboard/mouse input handler.

Another highly requested feature was the ability to save and restore where when last left off reading a piece of text, which is now implemented in the latest release. It works by taking an SHA256 hash of the content, and uses the hash as the file name. The current reader state is then dumped as regular commands into the file. These commands are the same ones that may be placed in the configuration file, or inputted into the programs command prompt. This process reuses the existing command parser. When that same content is opened again, Fltrdr will automatically check to see if a state file exists using a hash of the content, and loads the state if a matching file is found. This allows the ability to load and save the state whether the content came from a file, or stdin.

Lastly, more configuration options are available, with nearly everything being able to be customized.

I'm open to any feedback or suggestions, and I'd be happy to answer any questions!

For more details on what has changed, check out the release notes here: https://github.com/octobanana/fltrdr/releases/tag/0.3.0

It can be found here on GitHub: https://github.com/octobanana/fltrdr

It can also be found here on my personal site: https://octobanana.com/software/fltrdr

This looks neat, I'll give it a go later today.

One of the features I use Ranger for is to visually select multiple music files and then open them with mpv to play. Would that be something Hunter supports, or would support in the future?

What has been the most challenging aspect you've encountered so far while building this?

Thanks for sharing!

> I thought you were only talking about the click to expand the tree.

That makes sense. It would have been an interesting stat to compare, but the metrics only come from resource requests, as those pages don't run any scripts.

It's all server-side rendered. I've been considering open sourcing the site, but there's some cleaning up to be done first.

> Do you mean that your metrics showed that few people were expanding the tree, so you made it expanded by default?

Correct, after it became expanded by default, the hit rate for project files was dramatically higher, showing that users did care about viewing the files. Perhaps the UI could better indicate that it can be collapsed/expanded, but it could also be that it doesn't match the common UX found on the big sites like GitHub that users have become accustomed with.

> When I'm working with a GitHub project, I commonly want to load up the page and navigate to some files. If not, it's usually not much scrolling to get down to the README.

The solution I'm using currently for the git repos hosted on my personal site [0] is to show the projects file tree above the README, but allow it to be collapsed by clicking on the projects root directory. Originally, the project tree was collapsed by default, but the click through rate was quite low, so the expanded view became the default.

[0] https://octobanana.com/software/fltrdr

It works best with any plain ASCII text. What I've been doing is taking PDF's and using `pdftotext` and `iconv` to convert documents into plain text. I'll add more information on this in the README.md to make it more clear what it reads.

I'd be stoked if you did, It would be interesting to see how the program would look in Rust.

That's a good idea, thanks! I'll make an updated video of it and add a link to it in the README.md.

This blog post from last week has two videos of it in action. The first one demos some of the features, while the second reads a bit of a book uninterrupted for 2 minutes.

https://octobanana.com/blog/terminal-text-reader-demo

For the past month, I've been working on this terminal text reader project for fun. It started out as a project to learn more about how to structure and implement a text-based user interface with vi inspired features. It's written in C++17 and is released under the MIT license. I wanted to share it here in case someone may find it interesting.

Fltrdr, or flat-reader, is an interactive text reader for the terminal. It is flat in the sense that the reader is word-based. It creates a horizontal stream of words, ignoring all newline characters and reducing sequential whitespace. Its purpose is to facilitate reading, scanning, and searching text. The program also has a play mode that moves the reader forward one word at a time, along with a configurable words per minute (WPM) setting.

It is highly customizable, with a configuration file to persist your settings. The colourscheme can be changed to match your environments theme using either 24-bit, 8-bit, or 4-bit colours, depending on what your terminal supports. The characters used for the text border and progress bar can be set to a character or unicode-character of your choice. Some of the UI elements, such as the border, progress bar, and status bar can be individually shown/hidden to create a more minimalistic display.

I'm open to any feedback or suggestions!

This blog post from the other week contains videos of it in action: https://octobanana.com/blog/terminal-text-reader-demo

It can be found here on GitHub: https://github.com/octobanana/fltrdr

It can also be found here on my personal site: https://octobanana.com/software/fltrdr

Hello there!

For a weekend project, I wanted to write a program that would use the C++ HTTP client library I've been working on recently. I was curious to put it to the test in a real scenario and see what works and find any pain points. I decided on making a CLI program that utilized GitHub's HTTP API to perform search queries.

Stig is a CLI tool for searching GitHub from your terminal. It has all the same sorting and filter options that are present on GitHub, and outputs coloured, formatted results to stdout.

Feedback and thoughts are welcomed!

View on my personal website - https://octobanana.com/software/stig

View on GitHub - https://github.com/octobanana/stig

Hello HN!

About a year ago, I wanted to build a personal website in C++ to host projects and blog posts. I experimented with multiple C++ web libraries and went through several complete rewrites. Like the authors of all the other web libraries, I decided to write my own. The result of that endeavor is the Belle library. It has been powering my personal website since it went live two months ago. Its goal is to have an intuitive API, reasonable defaults, and great performance.

Any comments, questions, or feedback is welcomed!

Hello HN!

I've noticed lately that I tend to jump into the comment section on hacker news and reddit before reading the associated article. To prevent this, I wrote ireadit, a browser extension that hides the comment section if the article link has not been viewed. This is my first time writing an extension, so I am open to any and all comments or feedback.

It can currently be installed manually. The option to download from browser stores is coming soon.

You can check out a short video linked in the README.md that demonstrates how it functions.