builditluc/wiki-tui

A simple and easy to use Wikipedia Text User Interface

Hello there!

wiki-tui's Issues

[FEATURE] UI-Overhaul add a better, more tui looking, default color scheme

0.4.5 and 0.4.6 is broken on crates.io

Somehow the crates.io version of wiki-tui (0.4.5) is broken.
When you tried installing 0.4.5 via cargo install, this happened: #18

Until the next version is released, you have to compile it manually :/

[FEATURE] UI-Overhaul add a floating search bar

Replace old nix-shell with devshell

Description of the feature

Currently, we use nix-shell and direnv to load the developer environment. The problem is that this is not very flexible. Because of this, we would replace the old shell.nix with a flake and then load
the environment with devshell.

How it would be used

You would load the developer environment with one simple command nix develop. Then, everything is the same es before with the exception that we can now define custom commands and other cool shit that gets
loaded into the environment.

Checklist

• replace shell.nix with a flake
• load devshell into the flake
• define some qol commands

[FEATURE] UI-Overhaul set a fixed size for the search results panel

[FEATURE] UI-Overhaul get more information about a search result

[FEATURE] Better logging messages

The current state of logging is a bit messy, to put it mildly. There is no single convention to how these messages are formatted (lowercase, uppercase, values in ' ' or not, etc.) and every part of the program has a different way of formatting them. The info log level is also not used how it should be, informing the user what the program does or has done. It shouldn't contain debug information. This is for the debug log level, which is currently spammed by the html parser, so we'll have to disable the log output of the parser. The debug log level should contain very detailed information about what the program is doing, like for example if a view is created, a log message should be printed with the message creating view {name}. When this view is added we should print another message, adding view {name} to {view}.

Note: This feature is being developed on a branch that emerges from the UI overhaul branch (#80). This means it is also merged into the UI overhaul branch and not the main branch

[FEATURE] Have wiki-tui act as a GNOME search provider

Is your feature request related to a problem? Please describe.
I'm just throwing this out there as a nice feature for the application, but having the application function as a search provider in GNOME would be a nice touch. I don't know if it would fit in the scope of the project, so it's just a suggestion. It's absolutely not necessary, but it would make searching Wikipedia just that little bit easier, as most of the time you just quickly want to search a subject, and have the result be displayed. I haven't fully dived into the possibility of this feature, because I wanted to ask it first, but from what I understand, the application should add a GTK application struct (from gtk-rs, which I've used before, so I could help implementing this), and a dbus interface that listens for the different events of a search (start search, update search, select item...). Then the application would either open with the search, or change view to the search if there was already a window.

Describe the solution you'd like
Adding the ability for wiki-tui to function as a search provider in GNOME. It would allow the user to search for something in the general search bar of GNOME, and have results displayed in the GNOME UI, that allow the user to directly open wiki-tui for the specified page. It would have to be implemented as a feature, so it can be disabled on Windows, MacOS and other Linux distros.

https://developer.gnome.org/documentation/tutorials/search-provider.html#getinitialresultset-as-as

Additional context
The results would show up like the file explorer results, after which the user could select one and wiki-tui would display it.

Checklist

• checked that this feature wasn't requested before in an issue
• read CONTRIBUTING.md

Add table support for articles

Description of the feature

Currently, tables in wikipedia articles are just ignored. It would be nice to have a way of viewing them in the
ArticleView. Because it would be a lot of pain to write a custom table view from scratch, I think it would be
best if we just used the cursive_table_view crate for
rendering.

How it would be used

There would be a button-like object in the ArticleView, which will open a new popup window with the selected
table inside of it. The user can either click on this button or select it with the keyboard.

Checklist

• implement mouse support for the ArticleView
• add the cursive_table_view crate
• add table parsing to the parser
• implement some sort of "button" with a callback
• document the changes in the readme

[BUG] Clicking in the table of contents doesn't update the article view sometimes

Describe the bug
When clicking on some parts of the table of contents on the right, the view sometimes doesn't go to that section. I don't see when it works and when it doesn't, but it seems to be pretty random.

To Reproduce

1. Open a page (I was testing with the Linux Kernel page)
2. Click on the table of contents
3. It doesn't scroll in the article view sometimes

Expected behavior
The view should follow the clicked section on the table of contents.

Additional context
Latest version, installed with Cargo (There should probably be a section in the template for this information :))

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[BUG] Documentation action fails

The action we use to automatically update the documentation no longer works, it fails with a "permission denied" error.

Migrate to new Issue Templates

GitHub recently released issue forms in beta. They are a new way of creating issues, allowing the user to interactively create an issue with buttons, drop-downs, forms, and much more. This is way more user-friendlier than the current issue templates, so we'll migrate our current issue templates over to the new issue forms. This migration can be used to update the outdated issue templates.

We’ll also add another issue template, the crash-report template. It is similar to the bug-report template, but has different fields to give us further information on the crash. Because a bug that is causing a crash to occur has to be at a higher priority than for example a small visual bug, we need to add some simple priority labels as well.

Checklist

• Update instructions in the crash message
• Rewrite feature-request issue template
• Rewrite bug-report issue template
• Add crash-report issue template
• Add different bug labels

References

• https://github.com/stevemao/github-issue-templates/blob/master/.github/ISSUE_TEMPLATE/BUG-REPORT.yml

Change branching and CI/CD

The current branching system and CI/CD pipeline aren't flexible and are hard to work with. The following changes would make these systems a lot more flexible:

• only have a master branch (no more experimental -> stable merging)
• all bug fixes and features are done via pull requests (we can then use the Github release changelog tool)
• remove the auto-generate-changelog action

The CI/CD pipeline would need to do the following things:

• generate releases and a release branch on tag creation
• build binary's for different platforms on release and add them to the release
• publish new versions to crates.io
• build, test, and format check pull requests and releases

Also, it would help a lot if there was a pull request and issue template (but that would be better done in another issue).

[BUG] Non-supported HTML elements will be excluded without notice

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS
Backend (If changed during install): default

Describe the bug
When encountering a non-supported HTML element (e.g tables, mathematical equations, special elements like citations), they will simply get excluded and hidden from the user. This is the defined behavior, however, it leads to a few visual "bugs" when opening articles or just viewing sections only containing non-supported elements, as seen in the screenshots.

To Reproduce
Steps to reproduce the behavior:

1. Open the article List of content management systems or any other article containing non-supported HTML elements
2. The visual bug is visible

Expected behavior
Instead of just excluding the element from the article, there should be some text added instead that explains what element was hidden because it isn't supported.

Screenshots

This is an example of the visual bugs occurring because the user isn't informed that some elements are excluded, for reference, here is the Wikipedia article (it shows almost only tables, which are not supported)

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[FEATURE] UI Overhaul

This new feature will completely overhaul the current convoluted and ugly UI. I've already worked on designing this in the past weeks, taking inspiration from different tui applications. Below are some screenshots (changes on these screenshots are not final) showing the new UI. Currently, planned changes are:

• #92
• #93
• #94
• #95
• #96
• #97
• #98

the new home screen

search results panel, its size doesn't change when fetching more results

the article screen has its outer border removed so we don't have a double border

[FEATURE] UI-Overhaul add multiple, configurable border types (default, round, thick, etc.)

"~./config/wiki-tui/config.toml" not created at first run

General Information
Version: 0.5.1
Installation Method: source
Operating System: FreeBSD

Describe the bug
~./config/wiki-tui/config.toml file isn't created at first run, only ~./config/wiki-tui (empty) directory is created.

Expected behavior
~./config/wiki-tui/config.toml created at first run with default configure options.

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[FEATURE] Fetch text directly from the Wikipedia JSON API

Sometime I can see big blank spaces or no white spaces after a dot or between two words. I think they are related to HTML parsing, so I was thinking that you can use the Wikipedia API that already removes HTML from an article.

The text from the API should be less problematic. Here an example.

Unfortunately the links to other articles are also removed.

Support for overriding the config temporarily via cli arguments

It would be a nice feature for wiki-tui to support overriding the config temporarily via cli arguments.

For now it's just an idea, maybe I'll implement it sometime

text is not selectable

text is not selectable in any terminal emulator

[BUG] crash on non writable directory

General Information
Version: 0.5.1
Installation Method: source
Operating System: FreeBSD

Describe the bug
Crashes when running on directory not writable (without write permission, not owner)

To Reproduce

mkdir readonly
chmod =ro,+X readonly
cd readonly
wiki-tui

thread panicked while processing panic. aborting.
Abort

Expected behavior
Run normally

Screenshots
If applicable, add screenshots to help explain your problem.

Crash report (if available)

thread panicked while processing panic. aborting.
Abort

Additional context
I suspect it's related to trying to create wiki-tui.log.

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[BUG] Error when no results are available

General Information
Version: 0.5.1
Installation Method: cargo
Operating System: macOS

Describe the bug
When entering a search term that won't return any results (for example hlskdjf or la;skdjfe), the program will return a non deescriptive error (see below) and abort the search.

To Reproduce
Steps to reproduce the behavior:

1. Open wiki-tui
2. Enter any search term that will return no results
3. Press enter and start the search

Expected behavior
A dialog that says no results could be found and maybe a suggestion for different search terms (if, for example you misspelled a word)

Screenshots

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[BUG] External links can be opened

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS
Backend (If changed during install): default

Describe the bug
Sometimes, a link in an article leads to an external website. These links however can still be "opened" and trying to do so leads to wrong formatting and an error message.

To Reproduce
Steps to reproduce the behavior:

1. Open any article with an external link (eg. Opet)
2. Try to "open" the external link
3. The bug appears

Expected behavior
The user should be informed that this link leads to an external website and as such, cannot be opened by wiki-tui when trying to open the link. It should still, however, be selectable.

Screenshots

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

crashes when scrolling during the article loading process

When trying to scroll during the article loading, wiki-tui crashes.

Crash report:

Name: wiki-tui
Version: 0.4.7
Operating System: Mac OS
Cause: called `Option::unwrap()` on a `None` value.
Panic occurred in file 'src/ui/article/view.rs' at line 59


Logs:
2022-04-17T17:49:23.550516+02:00 INFO wiki_tui::logging - successfully initialized the logging system
2022-04-17T17:49:25.267093+02:00 INFO wiki_tui::ui::search - on_search was called
2022-04-17T17:49:25.267410+02:00 INFO wiki_tui::ui::search - searching for 'github'
2022-04-17T17:49:25.267503+02:00 INFO wiki_tui::wiki::search::builder - search was called
2022-04-17T17:49:25.640374+02:00 INFO wiki_tui::wiki::search::builder - search finished successfully
2022-04-17T17:49:25.640571+02:00 INFO wiki_tui::ui::search - displaying '10' out of '7664' search results
2022-04-17T17:49:25.640938+02:00 INFO wiki_tui::ui::search - on_search finished successfully
2022-04-17T17:49:25.641097+02:00 INFO wiki_tui::ui::search - on_result_select was called with the item 'GitHub', page id: 
'18545292'
2022-04-17T17:49:25.641404+02:00 INFO wiki_tui::ui::search - on_result_select finished successfully
2022-04-17T17:49:26.346485+02:00 INFO wiki_tui::ui::article - on_article_submit was called
2022-04-17T17:49:26.346610+02:00 INFO wiki_tui::ui::article - fetching the article 'GitHub' with the id '18545292'
2022-04-17T17:49:26.346671+02:00 INFO wiki_tui::wiki::article::builder - beginning the build process
2022-04-17T17:49:26.346720+02:00 INFO wiki_tui::wiki::article::builder - making the request to 
'https://en.wikipedia.org/?curid=18545292'
2022-04-17T17:49:26.961994+02:00 INFO wiki_tui::wiki::article::builder - parsing the article
2022-04-17T17:49:27.244632+02:00 INFO wiki_tui::ui::article - displaying the article 'GitHub'
2022-04-17T17:49:27.245633+02:00 INFO wiki_tui::ui::article - displaying the table of contents
2022-04-17T17:49:27.245763+02:00 INFO wiki_tui::ui::article - on_article_submit finished successfully

how can i instrall it on linux

i have tried cloning the directory and running cargo install in it but it failed
error: no override and no default toolchain set

i am using arch linux
if there is any simple way to install plz help

[BUG] Whitespace at the top of some articles

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS
Backend (If changed during install): default

Describe the bug
When opening articles, there is sometimes a large amount of whitespace at the top (its size also varies). Articles that have this whitespace include:

• Plant

  
• Fruit

  

• Apple

  

However, some articles just work correctly

• Internet hosting service

  

• Server (computing)

  

To Reproduce
Steps to reproduce the behavior:

1. Open any of the articles above in wiki-tui
2. See the whitespace at the top

Expected behavior
The whitespace should not be there and the article should just be rendered correctly.

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

Crashes on keyboard input right after selection

This is fantastic by the way.

When a search string is entered and the return key is hit there is a moment when results are being gathered prior to populating the UI. During this time if keyboard input is hit it will crash the application. Please disable keyboard input during this time or fix the issue so that there is no effect. Thank you

[BUG] Colors aren't returned to how they looked before

General Information
Version: 5.1
Installation Method: AUR
Operating System: Arch Linux (new/minimal install to test the AUR package)
Backend (If changed during install): /

Describe the bug
When the program ends, the foreground and background colors aren't like they were before the program was started. They should be reset to the original colors. This only happens in a tty, since I think most terminal emulators automatically reset the colors after a program ends.

To Reproduce
Steps to reproduce the behavior:

1. Run wiki-tui from a tty
2. (Search an article)
3. Terminate the program by pressing 'Q'

Expected behavior
Colors should look the same as before.

Screenshots

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[FEATURE] UI-Overhaul - simpler home screen

[BUG] Short articles only have a limited size

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS
Backend (If changed during install): default

Describe the bug
When opening an article that is smaller in height than the current size of the terminal window, the view won't get displayed in full. This leads to other views below the article being visible.

To Reproduce
Steps to reproduce the behavior:

1. Make the terminal window big (eg. fullscreen)
2. Open a short article in wiki-tui (eg. Opet)
3. The bug should now be visible (if not, try making the window even larger)

Expected behavior
Even when the article is too short to fill an entire window, the view should still fill it to prevent any unwanted views from still being visible.

Screenshots

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

Improve GitHub labels

The current labels are very close to the default GitHub ones and don't offer context about the status of an issue, only what type it is. Because of this, we'd want to replace the current ones with two different types of labels: State and Type labels.

The state labels are going to indicate the decision state of an issue, the following states are required:

• approved: This will indicate that the issue was approved and can be worked on
• inactive: When there were no interactions with this issue for a certain amount of time, the issue will be marked with this
• blocked: This issue cannot be worked on until another issue (linked in its description) has been finished
• duplicate: There is already another issue with the same topic (linked in its description)
• question: We need additional information to further work on this issue

Type labels indicate what type the issue is. We would need the following types:

• bug: This issue reports a bug or if it's a pull request, it'll fix the bug
• chore: Updates to the build process or dependency updates
• documentation: Changes to the documentation (in code and external documentation)
• feature: This issue requests / suggests a feature or if it's a pull request, it'll implement said feature
• testing: Changes to the tests
• refactor: This issue suggests a refactor or if it's a pull request, it'll implement said refactor

Because the labels are tightly integrated within the GitHub workflows, we'll have to update them to continue working correctly. We would even have to update the pull requests and other issues to incorporate changes to the labeling system.

There are also other labels we need:

• breaking-change: This issue or pull request introduces a breaking change to the codebase
• ignore-release: When we fix something that broke in the current development version, this will be handy
• good first issue: Issues or pull requests that are good for newcomers

This would be a list of all the labels needed, with their correct name, description, and color:

Label name	Description	Color
state: approved	This issue or pull request was approved and can be worked on	#0E8A16
state: inactive	This issue or pull request hasn't seen any activity in a while	#BFD4F2
state: blocked	This issue cannot be worked on until others have been finished	#B60205
state: duplicate	This issue or pull request already exists	#BFDADC
state: question	Additional information is required	#D876E3
type: bug	Something isn't working	#B60205
type: chore	Updates to the build process or dependency updates	#FEF2C0
type: documentation	Changes to the documentation (in code and external documentation)	#1D76DB
type: feature	Requests or implements a new feature	#A2EEEF
type: testing	Changes to the tests	#F9D0C4
type: refactor	Changes to the style and structure of the codebase or project	#BFDADC
breaking-change	Introduces a breaking change to the codebase	#B60205
ignore-release	This won't be included in the release notes	#5CEB33
good first issue	Good for first time contributors	#5319E7

This is a major change to the project (no breaking changes to the codebase, so don't worry there) that involves changing and updating multiple things.

Tasks

• Replace old GitHub labels with improved ones
• Update default labels in the issue templates (#127)
• Update label configurations in workflows (#128)
• Update labels for the issues and pull requests

References

• https://seantrane.com/posts/logical-colorful-github-labels-18230/
• https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63
• https://github.com/abdonrd/github-labels

[BUG] Crashes when pressing the arrow keys

General Information
Version: main
Installation Method: local build
Operating System: macOS

Describe the bug
Program crashes with an stack overflow error when pressing the arrow keys inside of a view.

To Reproduce
Steps to reproduce the behavior:

1. Build wiki-tui locally
2. Remove any keybindings configuration in the config file
3. Start wiki-tui
4. Search for anything
5. Press the down key inside of the search preview view
6. wiki-tui crashes

Expected behavior
Program works fine and does not crash when pressing keys

Additional context
This bug was found in another issue (#39)

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

0.5.0 consistently crashes

General Information
Version: 0.5.0
Installation Method: Built from source with Rust-1.64.1
Operating System: NetBSD-9.99.98
Backend (If changed during install):

Any attempt to open a search result results in a crash.
Example log,

Name: wiki-tui
Version: 0.5.0
Operating System: Unknown
Cause: assertion failed: header_y_coords.len() > index.
Panic occurred in file 'src/ui/article/content.rs' at line 76


Logs: 
2022-07-29T16:34:52.644877179+02:00 ERROR wiki_tui::error - panic occurred, crash log is at: /home/pin/crash_report-be8668f3-928c-4b1f-ac25-530038ae7731.log

[FEATURE] UI-Overhaul remove buttons in favor of configurable keybindings

TOC doesn't seem to work

Hi! Thank you very much for this fantastic piece of software! I live in the terminal, and being able to now never leave it to look at Wikipedia articles is just the best thing since sliced pizza! 😄

I've noticed though that, no matter which article I go to, the TOC does not allow me to jump around the main body. Maybe I'm doing it wrong, but I assumed that selecting the heading/sub-heading in the TOC and then hitting Enter would get me to the respective section in the main article, but it's not, nothing happens.

• NixOS Unstable
• wiki-toc v0.4.2
• alacritty terminal (in case that is interesting)

[BUG] No checksums provided for the release files

There should probably be checksums for the release files in the release notes or in separate checksum files per release file, to ensure their integrity. Checksums are kind of required for different software repositories, and they need to be provided upstream. Best would be BLAKE2 checksum, with sha256 or sha512 after that if BLAKE2 isn't available.

So like this:

• wiki-tui-x86_64-unknown-linux-gnu.tar.gz
• wiki-tui-x86_64-unknown-linux-gnu.tar.gz.sha512sum

how can i configure the background variable in config to use my terminal default background color

[BUG] Large release size

The latest release of wiki-tui (v0.6.0, 4MB) was substantially bigger than the release before that (v0.5.1, 79.6 KB). This is primarily due to the inclusion of assets in the release which is necessary because the images in the readme all have relative paths.

To fix this, we would need to use URLs as paths in the images. Which will in turn allow us to exclude the images from the release and therefore make the release much smaller again.

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[BUG] Multi-line links require multiple keypresses to move over

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS
Backend (If changed during install): default

Describe the bug
When a link is split between two lines, it requires multiple keypresses to move to the next one

To Reproduce
Steps to reproduce the behavior:

1. Open an article with links in wiki-tui
2. Either find a split link by scrolling or adjust the size to force a split link
3. Try to move over the link by pressing the required key

Expected behavior
The link should behave like any other link, not requiring multiple keypresses to move to the next one

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

[FEATURE] Add mkdocs documentation website

Is your feature request related to a problem? Please describe.
The current documentation, which includes the readme and the contributing guidelines is not clear and sometimes even outdated. It would be nice if we had a central place (preferably a website that's written in markdown so we can even read it in the terminal) for all of the documentation and maybe even some guide or checklists of how to contribute to the project. I've created a documentation website with mkdocs before so this wouldn't be much of an issue (apart from the writing, that part will probably take an eternity).

Describe the solution you'd like
There would be a website (hosted via Github Pages) that hosts all of the documentation and maybe some guides or checklists for new contributors. For updating the website, I think it would be great if pull requests that update the documentation are labeled with "documentation" so we can use a workflow that updates the website when the PR gets merged. We would also need to disable the ci workflow for pull requests labeled with "documentation" because we don't update any source code when making changes to the website.

EDIT: The contributors guide would have to be copied over to the CONTRIBUTIONS.md file or we could just link to the website in the file

The following things would need to be contained in this website (these are only the ones I've come up with, any ideas or suggestions are greatly appreciated):

• landing page that quickly sums up what wiki-tui is and what you can do with it (bd00d11)
• usage guide (controls, maybe pictures or a step-by-step guide on how to use it) (45999f6)
• crash guide (what to do if a crash occurs) (8f551e9)
• configuration guide (here is every configuration option explained, with sample configs)
• contributors guide
  • how to request a feature (also what happens when you request a feature)
  • how to report a bug (also what happens when you report a bug)
  • setup environment (install dev-dependencies, nix-shell, etc.)
  • how to contribute (code styles, file structure, commit messages, how to open a pr)
  • what are the labels (description of all the labels)
• checklists (basically a quick way of checking if you've done everything) (don't know if these should go into the contributors guide)
  • feature checklist
  • bug report checklist
  • commit checklist
  • pr checklist
  • pr merge checklist
  • release checklist

Additional context
Any suggestions or contributions to the documentation are greatly appreciated so if you have an idea, just make a pr or write it here as a comment.

Checklist

• checked that this feature wasn't requested before in an issue
• read CONTRIBUTING.md

[BUG] Multiple views not displaying the correct border

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS

Describe the bug
When changing the border style in the config, some views won't display the correct borders. They'll show the default border. These views are the dialog when opening a link and the table of contents

To Reproduce
Steps to reproduce the behavior:

1. Change the border style in the config to anything other than the default (eg. round)
2. Open any article in wiki-tui (the table of contents is visible)
3. Open a link in said article (the dialog is visible)

Expected behavior
The views should display the correct borders

Screenshots

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

Doesn't compile on mac m1 / arm

cargo error[E0532]

Contents pane doesn't navigate to section

When clicking or hitting enter on an item in the contents window, it does not navigate to the section of the document.

Is this by design or a bug?

I have tested this on native Ubuntu 20.x LTS and via Docker:Ubuntu20 on various hosts and see the same behavior.

Thank you for this awesome tool and for your assistance.

[BUG] Automatic scroll down doesn't work

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS
Backend (If changed during install): default

Describe the bug
When trying to select a link that is below the currently visible area, nothing happens.

To Reproduce
Steps to reproduce the behavior:

1. Open any article that has links
2. Try to select a link that is below the currently visible area
3. Watch as nothing happens

Expected behavior
The viewport should move down to the next link

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

Use flavours for colorscheme consistency?

The configuration file is nice and clean an lends itself well to be managed by flavours, which in turn uses Chris Kempson's fantastic base16 theme architecture.

Is that something you'd be interested in?

Vi Like Key Bindings [FEATURE]

It appears there is not a configuration option to use Vi like (h/j/k/l) key bindings for navigation. Seeing as how this is targeted at terminal users, it seems odd that you are required to have to use arrow keys which many keys which many keyboards don't even have.

wiki-tui now available on NetBSD

FYI, I've now packaged and merged wiki-tui into the main pkgsrc-branch, https://mail-index.netbsd.org/pkgsrc-changes/2021/10/31/msg242581.html

The package will soon be available to NetBSD users and to users of other platforms supported by pkgsrc.

Thank you for the application.
Two wishes, if possible,

1. Please provide GitHub release tags in sync with crates.io, it makes it easier for me to keep the package up-to-date
2. Would it be possible to configure the color of the TUI search bar?

Regards,
[email protected]

[BUG] URI fragments don't get handled properly

General Information
Version: 0.6.0
Installation Method: cargo
Operating System: macOS
Backend (If changed during install): default

Describe the bug
When the target URL of a link contains an URI fragment, it doesn't get handled nicely by the opening dialog (it is left in its raw form, see the screenshot below) and when opening said article, it stays at the top of the article and doesn't scroll to the required position.

To Reproduce
Steps to reproduce the behavior:

1. Open the Atom (text editor) wiki page in wiki-tui
2. Scroll down to the link unique UUID v4 random identifier (it is almost at the bottom of the article)
3. Open said link

Expected behavior
The user should be informed by the dialog box that the link is pointing to a specific position in the article and the program should scroll down to said position when opening the article.

Screenshots

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md

Garbled ascii on specific terminal geometries

wiki-tui is gaining users 👍
But, with it issues as well.
Please revisit my forum post, https://www.unitedbsd.com/d/603-wikipedia-on-the-terminal

and read through some findings.

Can the suggestion on the last post be implemented as a fix for the garbled ascii on certain terminal geometries?

[BUG] can't disable logging

General Information
Version: 0.5.1
Installation Method: source
Operating System: FreeBSD

Describe the bug
~/.config/wiki-tui/config.toml:

[logging]
enabled = false
log_dir = 'wiki_tui.log'
log_level = 'INFO'

log is created.

Checklist

• checked other issues for the same bug
• read CONTRIBUTING.md