andreiulmeyda / oil Goto Github PK

Thanks for sharing your work. Awesome tool.

I was using buku_run (also a great buku frontend) until I found your tool. I saw a comment you made about printing out a bookmarks 'title' in addition to the other info. Which is right along the lines of what I have been trying to do with buku_run as well. So when I saw you made this tool I had to give it a spin.

I am running into one issue I can not resolve. If I start my terminal, than start Oil I am able to successfully open bookmarks in my browser. But if I try to start Oil with a hotkey, or any other method that has Oil started in parallel with the terminal Oil will crash silently when trying to open a bookmark. The bookmark does not open and the entire terminal crashes. And I do not know where to start debugging it as its not logging any info. Or I cannot find any at least.

Any tips on how to get to the bottom of this would be appreciated. IMO Oil could be a perfect buku frontend with a few tweaks to how it displays output. Thanks for your time!

Arch linux Kernel: 4.17.14 
Gnome 3.30
Buku 3.8
Python 3.7 
fish-shell  2.7.1-1
peco 0.5.3-1
Vivaldi-Snapshot 1.16.1259.3-1
tilda-terminal 1.3.2

Hi, what did you use when taking that screencast? That terminal at the background is just great!

Once peco starts it is easy to forget in what mode the thing started and what the outcome of selecting a bookmark will be.

Hi, I've just installed and ran oil, and got this:

Traceback (most recent call last):
File "/usr/local/bin/buku", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.8/dist-packages/buku.py", line 5481, in main
bdb.print_rec(0)
File "/usr/local/lib/python3.8/dist-packages/buku.py", line 1748, in print_rec
print(format_json(resultset, field_filter=self.field_filter))
BrokenPipeError: [Errno 32] Broken pipe

Peco stock configuration does not feature multiple selection, but for people who enabled it the tool should work as expected.

I use firefox's bookmark manager, it has the convenience of auto complete tags and make the tagging system more consistant, i.e. few typos. But manage bookmarks in firefox is too slow when the number of bookmarks grow. Auto complete tags will save typing in case of a very long tag as well.

...by using peco.ExecuteCommand.xxx and, basically, restarting.

There were a few issues on OSX platform and I have got them fixed. Please let me know how you would like me to patch them back. There will have to be some platform checks in the fix.

But, moooom, do I really have to?

Print proper help text, ect.

Mocking is, even with bats, not too comfortable. Subsequent runs of the tests are not mutually independent leading to tests sometimes failing or passing without apparent reason. Feeding input to the jq script in tests is awkward and a syntactical plague if it works at all. Find another testing library, scrap the tests or abandon bash.

Buku is called with --sany and therefore, if one url is a substring of another, they cannot be deleted individually.

prompt for title and tags when adding a bookmark

It was added alongside the adding from clipboard feature.

That is an issue introduced by refactorings during which it was assumed passing arrays in bash as arguments to functions was not a total bitch. It would be somewhat feasible, yet ugly, if the array was the only passed argument in each case, but that is an assumption only waiting to be broken.

Until there is a neat solution or popular demand, one-by-one title editing it is.

Hi there !

After installing the needed dependencies and running make install, I get an error running oil :

/usr/bin/oil: /usr/lib/oil/json-to-line.jq : /bin/jq : mauvais interpréteur: Aucun fichier ou dossier de ce type
/usr/bin/oil: /usr/lib/oil/format-columns.awk : /bin/awk : mauvais interpréteur: Aucun fichier ou dossier de ce type

After a quick look at the source files, I see that the shebang is followed by hardcoded paths. My awk is not in /bin, as for jq, I installed it with LinuxBrew, so the path is completely different.

Would you please consider changing the interpreter ?

Thanks in advance

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 ❤️

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.

Since the idea for the project was to tick some boxes on the buku todo list and deleting bookmarks based on a search is one of them, add a mode for that.

Hello, I'm in the process of packaging oil into NixOS but there is one glaring problem. It searches the files from the $LIBDIR directory which currently is located on /usr/local/... which is not present on NixOS. I'd like to propose using the normal way of getting files from the PATH or LD_LIBRARY_PATH, or something like that, so it would be easier. If it ain't possible I might have to patch your code on my side.

Thx for your amazing app.

"|" is used in bookmark titles from time to time and messes things up

As of now, setup of multiline selection demands reading up on peco and meddling with its config file. Specify a small config setting up that feature with the --rcfile flag when invoking peco.

Provide means to disable this for people who use peco for other things as well and provide their own config.