Giter Site home page Giter Site logo

out-of-cheese-error / gooseberry Goto Github PK

View Code? Open in Web Editor NEW
152.0 4.0 9.0 2.47 MB

A command line utility to generate a knowledge base from Hypothesis annotations

License: Apache License 2.0

Rust 100.00%
knowledge-base hypothesis-annotations hypothesis mdbook obsidian-md wiki command-line

gooseberry's Introduction

Gooseberry - a Knowledge Base for the Lazy

Crates.io CI GitHub release dependency status

"Buy Me A Coffee"

Gooseberry provides

  • a command-line interface for Hypothesis (a tool to annotate the web)
  • lets you generate a knowledge-base wiki without you having to actually type your knowledge out.

Obsidian example

demo

made with asciinema, svg-term-cli, and svgembed

This demonstrates the interactive search functionality. Enter adds a new tag, Shift-Left deletes a tag, and Shift-Right deletes an annotation. (TODO: embed keypresses in GIF)

Install

Installation requirements

  • A Hypothesis account, and a personal API token obtained as described here.
  • bat to display highlighted markdown in the terminal.

Binaries

See the releases

  • OSX - allow gooseberry via System Preferences (necessary in Catalina at least)
  • Linux - chmod +x gooseberry
  • Currently, doesn't work on Windows (waiting on this issue)

With brew (OSX)

brew tap out-of-cheese-error/gooseberry && brew install gooseberry

AUR

gooseberry is now also available on the Arch User Repo here

Contributing

See CONTRIBUTING.md for an in-depth explanation of how Gooseberry works and what could be improved.

Motivation

So yes, knowledge-base tools are old hat and a dime a dozen, and we really have no excuse to not have a nice big tangled folder of markdown files filled with our overflowing wisdom. But after spending all day writing code and papers and tasks, it just isn't fair that our reading time also needs to be typing time to get all that knowledge down. And if we don't type things out our fancy knowledge-base is bare, empty, and sad.

In comes Gooseberry - a tool to build a knowledge base from highlighting and annotating passages while reading news articles, blog posts, papers, what have you. Gooseberry combines the ease of annotation offered by Hypothesis, bulk tagging and organization support in the command line, and a customizable plaintext wiki with HandleBars templating.

A typical workflow

  1. Find an article, blog post, paper etc. to read.
  2. Highlight lines and facts you'd like to remember later. You can add comments and tags already if you're up for it but the focus can also be just on reading and highlighting without thinking too much about taking notes.
  3. More often than not, when one gets into a topic it ends in 50 open tabs of subtopics. This is fine, keep reading and highlighting away, we'll get back to this.
  4. Finally, once your thirst for knowledge has been fulfilled, fire up a terminal and run
    • gooseberry sync to download all your latest highlights and annotations.
    • gooseberry tag --from "9a.m." topic to tag everything you've read this morning with the topic you were looking into. This subcommand is super flexible. You can tag something by a website, so that all annotations from subtopic B's wikipedia page are tagged as B for instance. Or just open up search to search your annotations and add tags to everything matching a search query (or remove tags and annotations). Tags are very nestable, definitely make use of this - e.g. all annotations today may be about topic A, five of them are also subtopic B etc.
    • gooseberry make to add all this new tagged information to your knowledge base.

Here's an example. Today I read and annotated three articles about insects: this Nautilus article titled "We need insects more than they need us", this publication about honey bees and pesticides, and an Atlantic article about the "anternet" .

I synced and tagged these annotations:

gooseberry sync and tag

Then ran gooseberry make to make an mdBook style wiki which I could then open in the browser:

Tag page example

Or an Obsidian style wiki, with annotations grouped into folders based on the document/web-page title

Obsidian example

Annotation text is just markdown so text formatting, LaTeX, pictures etc. goes too!

Picture example

The annotation template is configurable, as is the folder and grouping structure. Each annotation can link back to the position in the website that you got it from, if ever you feel like you're missing context.

Some advantages

  • You barely have to type while reading unless you're in the mood for taking notes.
  • If you're in the mood, the note-taking won't involve window switching.
  • Even without using the wiki functionality you end up with a CLI to quickly tag your Hypothesis annotations.
  • Even without using the tagging functionality you end up with a pretty cool wiki listing all your annotations.
  • Since it's just plaintext, and the template can be customized, you can integrate it with any knowledge base system accepting plaintext files (like Obsidian, mdBook, org-mode, vim-wiki, etc.)

Usage

Usage: gooseberry [OPTIONS] <COMMAND>

Commands:
  sync      Sync newly added or updated Hypothesis annotations
  search    Opens a search buffer to filter annotations. Has keyboard shortcuts for deleting annotations, modifying tags, and creating knowledge-base files
  tag       Tag annotations according to topic
  delete    Delete annotations in bulk
  view      View (optionally filtered) annotations
  uri       Get the set of URIs from a list of (optionally filtered) annotations
  make      Create knowledge-base text files using optionally filtered annotations
  index     Create an index file using hierarchy and optionally filtered annotations
  complete  Generate shell completions
  config    Manage configuration
  clear     Clear all gooseberry data
  move      Move (optionally filtered) annotations from a different hypothesis group to Gooseberry's
  help      Print this message or the help of the given subcommand(s)

Options:
  -c, --config <CONFIG>  Location of config file (uses default XDG location or environment variable if not given) [env: GOOSEBERRY_CONFIG=]
  -h, --help             Print help

The default config TOML file is located in

  • Linux: /home/<username>/.config
  • Mac: /Users/<username>/Library/Preferences

Change this by creating a config file with gooseberry config default > config.toml and modifying the contents. You can then use this as your configuration with gooseberry -c path/to/config.toml <subcommand> or by setting the environment variable $GOOSEBERRY_CONFIG to point to the file.

Authorize Hypothesis either by setting the $HYPOTHESIS_NAME and $HYPOTHESIS_KEY environment variables to your username and developer API token or by running gooseberry config authorize.

Gooseberry takes annotations from given Hypothesis group(s) which you can create/set with gooseberry config group. This automatically syncs all existing annotations from these groups.

Sync newly added annotations with gooseberry sync.

The search command provides an interactive search interface to your annotations (optionally pre-filtered using the filtering options below). Each annotation is rendered using the annotation template (configured with gooseberry config kb annotation and described below). The interface supports the following keybindings: Arrow keys to scroll, Tab to toggle selection, Ctrl-A to select all, Esc to abort Enter to add a tag, Shift-Left to delete a tag, Shift-Right to delete an annotation Shift-Down to make knowledge-base files, Shift-Up to print the set of URIs.

You can also accomplish these tasks without the interactive interface using the tag, delete, view, uri, make, and index commands.

NOTE: tagging and deletions are synced to Hypothesis!

Filtering

You can filter the annotations you want to modify or export using the following options in most gooseberry commands:

      --from <FROM>
          Only annotations created after this date and time
          
          Can be colloquial, e.g. "last Friday 8pm"

      --before <BEFORE>
          Only annotations created before this date and time
          
          Can be colloquial, e.g. "last Friday 8pm"

  -i, --include-updated
          Include annotations updated in given time range (instead of just created)

      --uri <URI>
          Only annotations with this pattern in their URL
          
          Doesn't have to be the full URL, e.g. "wikipedia"
          
          [default: ]

      --any <ANY>
          Only annotations with this pattern in their `quote`, `tags`, `text`, or `uri`
          
          [default: ]

      --tags <TAGS>
          Only annotations with ANY of these tags (use --and to match ALL)

      --groups <GROUPS>
          Only annotations from these groups

      --exclude-tags <EXCLUDE_TAGS>
          Only annotations without ANY of these tags

      --quote <QUOTE>
          Only annotations that contain this text inside the text that was annotated
          
          [default: ]

      --text <TEXT>
          Only annotations that contain this text in their textual body
          
          [default: ]

  -n, --not
          Annotations NOT matching the given filter criteria

      --and
          (Use with --tags) Annotations matching ALL of the given tags

  -p, --page
          Only page notes

  -a, --annotation
          Only annotations (i.e exclude page notes)

Knowledge base

The gooseberry make command is used to generate knowledge base files using (optionally filtered) annotations. By default, it also generates an index file (configured by the index and link configuration options) - this can be disabled with --no-index. Use gooseberry index to generate just the index file.

Configuration options for the knowledge base are as follows:

Usage: gooseberry config kb <COMMAND>

Commands:
  all         Change everything related to the knowledge base
  directory   Change knowledge base directory
  annotation  Change annotation handlebars template
  page        Change page handlebars template
  link        Change index link handlebars template
  index       Change index file name
  extension   Change knowledge base file extension
  hierarchy   Change folder & file hierarchy
  sort        Change sort order of annotations within a page
  ignore      Set which tags to ignore
  nest        Set string defining nested tags (e.g "/" => parent/child)
  help        Print this message or the help of the given subcommand(s)

You can set all knowledge base configuration options at once by running gooseberry config kb all or changing the corresponding keys in the config file (found at gooseberry config where).

IMPORTANT: The knowledge base directory is cleared at every sync so if you're storing Hypothesis annotations alongside other notes, make sure to make a separate folder.

Annotation template

The annotation template is used to render a single annotation. The following keys can be used inside the template:

  • {{ id }} - Annotation ID
  • created - Date of creation. Use with the date_format helper (See here for formatting options)
  • updated - Date of the last modification. Use with the date_format helper (See here for formatting options)
  • {{ user }} - User account ID formatted as acct:<username>@<authority>
  • {{ uri }} - URI of page being annotated (this can be a website URL or a PDF URN)
  • {{ base_uri }} - Base website of URI, i.e just the protocol and domain.
  • {{ title }} - Title of webpage/article/document
  • {{ incontext }} - Link to annotation in context (opens the Hypothesis sidebar and focuses on the annotation)
  • highlight - List of selected/highlighted lines from document (split by newline)
  • {{ text }} - The text content of the annotation body
  • tags - A list of tags associated with the annotation.
  • {{ group }} - ID of Hypothesis group,
  • {{ group_name }} - Name of Hypothesis group,
  • references - List of annotation IDs for any annotations this annotation references (e.g. is a reply to)
  • {{ display_name }} - Display name of annotation creator. This may not be set.

See the Handlebars Language Guide for more on templating. You can also make use of the helpers from handlebars_misc_helpers.

Some examples for using the list keys and for formatting dates are shown below for different systems:

  • mdBook
##### {{date_format "%c" created}} - *{{id}}*

{{#each tags}}| [{{this}}]({{this}}.md) {{#if @last}}|{{/if}}{{/each}}

{{#each highlight}}> {{this}}{{/each}}

{{text}}

[See in context]({{incontext}})

Renders as:

##### Sat Jan 16 11:12:49 2021 - *test*

| [tag1](tag1.md) | [tag2](tag2.md) |

> exact text highlighted in website

testing annotation

[See in context](https://incontext_link.com)

This makes each tag a link to a dedicated page consisting of annotations with that tag - you can set this up by configuring the hierarchy (hierarchy = ["tag"]).

  • Obsidian
### {{id}}

Created: {{date_format "%c" created}} Tags: {{#each tags}}#{{this}}{{#unless @last}}, {{/unless}}{{/each}}

{{#each highlight}}> {{this}}{{/each}}

{{text}}

[See in context]({{incontext}})

Renders as:

### test

Created: Sat Jan 16 10:22:20 2021 Tags: #tag1, #tag2

> exact text highlighted in website

testing annotation

This uses #tags b/c Obsidian likes those.

TODO add org-mode example

Page template

The page template is used for rendering a single page of annotations (NOT the Index page). The following keys can be used inside the template:

  • {{ name }} - file stem
  • {{ relative_path }} - path relative to KB directory
  • {{ absolute_path }} - full path on filesystem
  • annotations - a list of rendered annotations (according to the annotation template)
  • raw_annotations - a list of annotations (in case you need info for the page about the annotations - e.g. {{raw_annotations.0.title}})

The default template is:

# {{name}}

{{#each annotations}}{{this}}{{/each}}

Grouping annotations into folders and pages

The hierarchy configuration defines how the folder and file structure of the knowledge base looks and which annotations are on what pages. The available options are:

  • Empty - Set hierarchy = [] to have all annotations rendered on the index page.
  • Tag - Groups annotations by tag
  • URI - Groups annotations by their URI
  • BaseURI - Groups annotations by their base URI
  • Title - Group annotations by the title of their webpage/article/document
  • ID - Groups annotations by annotation ID.
  • Group - Groups annotations by group ID.
  • GroupName - Groups annotations by group name.

Multiple hierarchies combined make folders and sub-folders, with the last entry defining pages.

e.g.

hierarchy = ["Group", "Tag"] would make a separate folder for each group. Within each folder would be a page for each tag consisting of annotations marked with that tag.

hierarchy = ["Tag"] gives the structure in the mdbook figure above, i.e. no folders, a page for each tag.

Sorting annotations within a page

The sortconfiguration defines how annotations are sorted within each page. The available options are:

  • Tag - Sorts by tag (multiple tags are considered as "tag1,tag2,tag3" for sorting)
  • URI
  • BaseURI
  • Title
  • ID
  • Group
  • GroupName
  • Created
  • Updated

Multiple sort options can be combined in order of priority e.g. sort = ["Tag", "Created"] sorts by tags, then by the date of creation.

Index link template

The link template controls how each link in the index file is rendered. The available keys are:

  • {{ name }} - file stem
  • {{ relative_path }} - path relative to KB directory
  • {{ absolute_path }} - full path on filesystem

Examples:

  • mdBook
- [{{name}}]({{relative_path}})
  • Obsidian
- [[{{name}}]]

to make internal links, or

- ![[{{name}}]]

to transclude files

  • Org-mode
- [[{{relative_path}}][{{name}}]]

Other options

  • index - sets the name of the Index file, e.g. mdbook needs this to be called "SUMMARY" and in Obisidan you could use "00INDEX" to make it show up first in the file explorer.
  • ignore - sets the list of tags to ignore when creating the knowledge base. Note: Annotations with ignored tags will still be included in the search and tag commands
  • nest - defines the pattern to use for nesting tags. e.g. if nested_tag = "/" then a tag of "parent/child" combined with hierarchy = ["Tag"] would create a "parent" folder with a "child" file inside it. Note: Commas (",") and semicolons (";") should not be used inside tags as they are used as separators by Gooseberry.
  • extension - sets the file extension for the knowledge base files. e.g. "md", "org", "txt" etc. Note: Don't include the . in the extension

Why "Gooseberry"?

Because Discworld will never let me down when it comes to names: Dis-organizer Mark 5, the Gooseberry

gooseberry's People

Contributors

kevloui avatar ninjani avatar oktak avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

gooseberry's Issues

No such file or directory during config

Hi there, MacOS X Catalina here. When I'm using any config command, i'm getting this error:

The application panicked (crashed).
Message:  called `Result::unwrap()` on an `Err` value: 
   0: ConfigError: "Couldn\'t create database directory \"/Users/emile/Library/Application Support/rs.gooseberry/gooseberry_db\", No such file or directory (os error 2)"

Location:
   src/configuration.rs:154
Location: src/configuration.rs:106
Abort trap: 6

This was solved by executing mkdir /Users/emile/Library/Application\ Support/rs.gooseberry/, but it sounds like it's better to create this dir automatically.

Add page template

Problem

Gooseberry provides templates for individual annotations. However, I'd like to create pages for individual URI's visited. This means the URI would be repeated at every annotation.

Solution

Ideally, one would be able to create a template for the page the annotations will be in as well. This is challenging though because it depends on the hierarchy used what keys will be available.

So for instance, the 'page template' could be, when hierarchy is eg ['URI']:

---
aliases: []
---

{{#each annotation}} {{annotation}} {{/each}}

---
#gooseberry 
- [link](URI) 

"gooseberry make" should print some information

Such as:
"Finished building book. Use mdbook serve "<kb_dir>" and go to localhost:3000 to view it."
The <kb_dir> can be read from self.config in the make function (in gooseberry/markdown.rs)
This may be a good place to use an indicatif progress bar.

Displaying annotations is too long

Using home-made binary from the trunk, on Ubuntu 20.04.
gooseberry search takes more that 7 seconds to display its output for 693 annotations. That's very long. Is there any reason why ?
I'm assuming no network operations are involved here, is that so ?

Add gooseberry edit to edit annotation text

Add a new command gooseberry edit that lets you edit and upload the annotation content. Include this as a keyboard shortcut in gooseberry search.

Think about how this could be done in bulk - a text file with each annotation in a separate section (with a fixed format, so it's parse-able) opened in the default editor? Would be nice to use a different editor for this (e.g whatever is being used for viewing the knowledge base - Typora, Obsidian, Emacs etc.) but that would need two commands - one for preparing a file to edit and one for uploading edits.

Unsure about the acceptable characters for tags

Okay, this is more of a question than an issue per se, but since I'm tring to get back to Hypothes.is and can't remember which characters can be part of a tag, I thought it could be worth adding that info to the docs.

(What I'm trying to come up with is a controlled vocabulary with facets, so something like parent:child1 / parent:child2 or parent/child1 / parent/child2 -- whatever form Hypothes.is would be nice enough to accept).

Tag manager

Problem

It's hard to keep in mind all the existing tags and tag structure when adding a new tag.

Solution

Tagging in gooseberry should open up a search window with a list of existing tags to select from and a way to add new ones. This is an easy way to also allow selecting multiple tags at once.

Additional context

Maybe some way to create tag hierarchies like in Obsidian with "/". (this should probably be a separate issue as it would need refactoring of the query system).

Add a "gooseberry stats" command

Dashboard:

  • Table listing tags and number of notes in each tag
  • Bar chart showing number of notes added per day/month
  • List URIs with many notes

Use tui.

Theming

Themes are applicable in two areas:

  1. gooseberry view which prints out annotations in markdown to the terminal using termimad
  2. the generated mdbook

termimad can be themed as described here and may make sense to have the quoted text in a different color.

mdbook can also be themed. This can be done from the user's side, but need to look into adding a sidebar for linking annotations to each other.

Link local PDF annotations to filename

Problem

Local PDF annotations have urn:x-pdf:<fingerprint> as their URI, which says nothing about the filename or where it's stored. Would be nice to have the filename to link to the file in local knowledge base systems.

Solution

Have a PDF folder set in the config, keep a mapping of all PDF fingerprints for this folder (using this post as reference), and map all PDF annotations to their respective files using this mapping.

Alternatives

Ideally should have a reverse mapping function so that you don't need a PDF folder, but I doubt this is possible.

Additional context

Needs a file-watcher aspect to check if PDF files in the folder have been added / updated. The first version could just loop through the PDF folder on every sync.

Set the kb_dir somewhere more accessible to the user

The directory with mdbook files is currently automatically set using directories-next. This would make more sense if it was in a more user-accessible location.
This could be done the same way as the hypothesis_name and hypothesis_key are set, i.e with an input prompt where the user can enter a directory (see request_credentials in gooseberry/configuration.rs). Would need to check that the directory path is valid and doesn't already exist. Also would make sense to suggest some default directory here, maybe in $HOME.

Store annotations locally

Problem

Gooseberry queries Hypothesis for every search and make which is time-consuming and wasteful since many old annotations won't change any more.

Solution

  • Store annotations in database
  • Use last synced time to check for updates
  • Re-implement filtering using all options supported by Hypothesis
  • Refactor to only run hypothesis for sync, updating tags, deleting annotations. Everything else should be offline.

Additional context

See issue #75

Mention that `--time` expects values in UTC

Unless I'm misunderstood, --time expects values in UTC.
Mentioning it in the docs would be nice.
Even nicer would be to take values in local time and doing the queries with the local timezone taken into account.

Error: Make sure input fields are valid

Bug description

When trying to synchronise the local knowledge base, an error is thrown:

Error: 
   0: Make sure input fields are valid
   1: Status: 
      Reason: 

Location:
   /home/runner/work/gooseberry/gooseberry/src/gooseberry/mod.rs:201

To Reproduce

  1. goosebery config authorize
  2. goosebery config kb all
  3. gooseberry sync

Expected behavior

The sync is performed and a subsequent make run can finish.

Better output for sync

In gooseberry sync:

  • Handle single note case: i.e. "Added/Updated/Ignored 1 note" instead of "1 notes"
  • Output "Everything up to date" if nothing changes.

(Remember to modify tests/cli.rs to reflect these changes)

Tag rules based on URI

Would be handy to have a set of rules that automatically adds tags to pages from a certain domain. e.g a "paper" tag for publications from nature or any other journal, a "news" tag for news websites etc.

  • Needs a file format to specify these rules
  • Every gooseberry sync call needs to check new annotations against the set of rules and update them accordingly.

Note: I think it's important to prepend these tags with "gooseberry:" to keep them separate from user / other tools' tags and easier to search for.

No newline in index list

Bug description

The index is creating a nice overview of elements in the annotation, but they're missing newlines. For instance, my index.md looks like

- [https_github_com_out-of-cheese-error_gooseberry_issues_50](https_github_com_out-of-cheese-error_gooseberry_issues_50.md)- [https_github_com_out-of-cheese-error_gooseberry](https_github_com_out-of-cheese-error_gooseberry.md)

which doesn't render as a proper list in Markdown.

  • OS: MacOS Catalina

Multiple configuration files

Problem

I have two Obsidian vaults, one for work and one for personal activities. Gooseberry however only allows a single configuration file, meaning I can only set it up for one of these vaults.

Solution

It would be nice if it were possible to have multiple configuration files, where one of the vaults could be populated by different groups and using different templates.

(Sorry for all the issues! I like it a lot, which is why I'm adding some things I'd really like to have :) )

Markdown - incremental generation

One major improvement would be to incrementally generate Markdown files instead of regenerating from scratch every time gooseberry make is called.
This would involve keeping track of each annotation as a Section and only modifying it if its Updated time has changed + appending newly created annotations to the end.

This would theoretically allow a user to modify their markdown files in an editor of choice and store other kinds of (non-annotation) notes in it.

This would also help integrate Gooseberry into existing Markdown-based PKB tools.

Add an ignore_tags configuration option to ignore annotations in make

Problem

Some annotations don't need to be present in generated knowledge base. Maybe they're addressed already, or specific to a short-term task.

Solution

An ignore_tags configuration option that gooseberry make uses to ignore annotations with given tags.

Alternatives

Possibly also a complementary keep_tags option that only generates annotations with given tags. Either option can be used but not both.

gooseberry make giving error

on Arch linux , compiled gooseberry after cloning repo and downloaded mdbook as seperate binary.
gooseberry sync and tag sub commands working without error.

gooseberry make giving the following error after creating src directory and book.toml

Error: No such file or directory (os error 2)

i tried running gooseberry make after creating Chapter_1.md and SUMMARY.md in knowledgebase directory, which erased both files giving the same above error.

More CLI options

The CLI allows tagging, deleting tags, and deleting annotations. These three allow filtering based on tag, uri, text, quote, and date. What else would a knowledge-base maintainer need?

  • --before to complement --from in Filters
  • --exact to complement the default fuzzy search (or the other way round with --fuzzy)
  • view to print out a single annotation - again, search window + print prettily including created/updated dates and a link to the annotation on Hypothesis.
  • edit for editing annotations - this could open the search window to select an annotation and then an editor window to edit the text/comment. Seems unnecessary when you can just edit it in the browser
  • sync --group id - to sync annotations from a different group just once? this could also post these annotations to gooseberry's group to collect annotations from here and there into the KB. Make sure to set the user though, o/w if the group is public then you'll be syncing millions of annotations. This should have Filters - maybe a different command makes more sense for this: move?.
  • bookmark - Hypothesis annotations can also be to a whole page instead of a quote. This would be a neat way of storing bookmarks to pages out of scope

Add tests using assert_cmd

All command line behavior needs to be tested:

  • sync: test that new and updated annotations are correctly recorded, annotations marked as gooseberry_ignore are ignored, annotations with no tags are stored with gooseberry_empty etc.
  • tag: adding and deleting tags should work as expected. this just uses sync again so database should be fine
  • delete: check that annotation is deleted either from just gooseberry or also from hypothesis. deleting an annotation from gooseberry should add gooseberry_ignore to its tags.
  • make: should take book.toml into account, should make a correct mermaid graph for the index. should list annotations in date order.

Is it possible to include the website title

Problem

I hope the title of the website can be included, Not just the ID, since It contains more information. But i couldn't find any field to represent it. But it is possible in the webpages of hypothesis

Solution

Alternatives

Additional context

'gooseberry make' crashes

gooseberry make fails with following output :

✔ Clear knowledge base directory? · no
⠁
The application panicked (crashed).
Message:  called `Option::unwrap()` on a `None` value
Location: /home/xxxx/Downloads/gooseberry/src/gooseberry/knowledge_base.rs:275
fish: “./gooseberry make” terminated by signal SIGABRT (Abort)

Suggestions for features

A knowledge base tool can have any number of features. Some really improve user experience and others are more for eye-candy. This issue should track possible additions and improvements to make Gooseberry a "real" personal knowledge base tool.

Tagging and linking

Think about more tagging and linking functionality. Some ideas:

  • Linking an annotation to another like a footnote. Maybe with a special tag like gooseberry_link_a1_a2, or using the references field in Annotation.
  • Tags can probably be parents of other tags: e.g Science -> Biology. In mermaid this would be a subgraph but how would this be indicated by the user? gooseberry_parent_t1_t2?
  • Need to deal with reply comments correctly and nest them in the wiki. This could also be a CLI functionality gooseberry reply to mark one annotation as the child of another. This also uses the references field in Annotation.

Support tags with spaces in them

mdbook chapter filenames can't have spaces in them. This should be as simple as

  1. .replace(" ", "_") when making each tag_file
  2. same for the the mermaid graph

Group together annotations from same webpage

Right now each annotation gets its own section on the tag page, with "see in context at " written below it. This doesn't make a lot of sense for multiple annotations from the same webpage. They should all be in a section instead, with a single link to the page and multiple smaller footnote-style links to each specific annotation.

.env USERNAME may misuse the OS ENV value

Hi. I read through CONTRIBUTING.md and followed the steps to run the test. I find the test does not pass. It said sync and tags tests are failed.

I print hypothesis_username in cli.rs for debug, and found it is not the same as what I set in the .env file. Instead it is my username on the OS.

It seems it affects the test only, but not the main program. It may be due to using dotenv::var(USERNAME")?; to get the value.

I suggest use a more specific variable name such as HYPOTHESIS_USERNAME to replace USERNAME.

OS: Ubuntu 18.04.5
Rust: 1.46.0 (04488afe3 2020-08-24)

P.S. I tried to unset USERNAME, and it comes back after I reboot the OS.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.