This tool is in its early stage and was born out of a guess as to the extent peco might lend itself to being used as an interface for buku. Viewing bookmarks, then opening them in the browser or adding tags to them works, to a first approximation, well. Changing titles works as well.
The next significant step is, in my opinion, to make it visually appealing as, for the moment, the displayed lines are, though properly searchable, unstructured and messy. Unfortunately the approach seems to make a trade off unavoidable. And this is between the amount of information that can be searched, which is spread out over tags, descriptions, titles and urls, and the amount of information that is crammed into a single line and with it the ability to structure it for readability. Whitespace and the width restrictions that would come with, for instance, a column formatting subtract from the space available for searchable text.
Now, for my personal use I would probably quickly make a compromise, restrict myself to short titles, a low amount of tags per bookmark and a url that just exceeds the right side of the screen and be done with it, the last downside being the parts of the url not on the screen not highlighting the matched parts. But that would most likely fail to accomodate for other peoples use cases.
Therefore, for everyone visiting, might I ask you a favour? Would you care to answer a few question so I can begin to estimate what compromises are possible for other people:
Which of the buku datafields, namely url, tags, description and title would you routinely need to search?
Might there be a set of 2 or 3 of them that would end up being sufficient given acceptable adjustments of usage on your part?
Do you have an idea or hint as to what other avenues can be explored to further structured/readable lines? (For instance color output, which I tried for a second but I think the terminal ansi color thingies are not preserved by peco since it provides its own coloring facilities that can't make any assumptions about the content of lines, I might be wrong though)
What I have not explored as of yet is how the left/right scrolling of peco impacts this situation. It might alleviate parts of the problem.
TL;DR I need your help deciding which parts of the buku url/tags/description/title data cannot be omitted from being searchable and which can.
Thank you very much for reading :heart:
UPDATE: Based on this comment I suspect that it is possible with a bit of tinkering to provide an interface to peco that allows for separation of searchable and displayed text. I am currently for lack of time and knowledge of go not investigating this.
This tool is in its early stage and was born out of a guess as to the extent peco might lend itself to being used as an interface for buku. Viewing bookmarks, then opening them in the browser or adding tags to them works, to a first approximation, well. Changing titles works as well.
The next significant step is, in my opinion, to make it visually appealing as, for the moment, the displayed lines are, though properly searchable, unstructured and messy. Unfortunately the approach seems to make a trade off unavoidable. And this is between the amount of information that can be searched, which is spread out over tags, descriptions, titles and urls, and the amount of information that is crammed into a single line and with it the ability to structure it for readability. Whitespace and the width restrictions that would come with, for instance, a column formatting subtract from the space available for searchable text.
Now, for my personal use I would probably quickly make a compromise, restrict myself to short titles, a low amount of tags per bookmark and a url that just exceeds the right side of the screen and be done with it, the last downside being the parts of the url not on the screen not highlighting the matched parts. But that would most likely fail to accomodate for other peoples use cases.
Therefore, for everyone visiting, might I ask you a favour? Would you care to answer a few question so I can begin to estimate what compromises are possible for other people:
What I have not explored as of yet is how the left/right scrolling of peco impacts this situation. It might alleviate parts of the problem.
TL;DR I need your help deciding which parts of the buku url/tags/description/title data cannot be omitted from being searchable and which can.
Thank you very much for reading :heart:
UPDATE: Based on this comment I suspect that it is possible with a bit of tinkering to provide an interface to peco that allows for separation of searchable and displayed text. I am currently for lack of time and knowledge of go not investigating this.