For now, it is not convenient to use akl when editing a document because it is not in the database. Potential solutions for latex users include

1. Create a akl package that rewrites links inside the pdf document.
2. Create a custom latexmk configuration to override the generated pdf document.

Solution 2 typically looks like this

$pdf_mode = 1;
$pdf_update_method = 4;
$pdf_update_command = 'akl convert --uri %S --output %S';
$pdf_previewer = 'start evince';

While solution 1 should look like

\makeatletter
% save the old hyper@linkurl command
\let\oldlinkurl\hyper@linkurl
% override it by prepending AKL in front
\renewcommand{\hyper@linkurl}[2]{\oldlinkurl{#1}{akl://open-document/?uri=#2}}
\makeatother

This has numerous disadvantages:

1. The generated urls will mostly be invalid because not urlencoded
2. The page/destination parameters are not transferred to the akl link

For the program to reach full potential, it is needed that users create links with extra destination information in their pdfs. That is, instead of writing https://arxiv.org/abs/2207.07450v4, one would write https://arxiv.org/abs/2207.07450v4?page=15 or https://arxiv.org/abs/2207.07450v4?dest=theorem.2.9.

To automate this process, the pdfs imported currently allow to copy to the user's clipboard a direct link with the necessary information. However, it is quite unpleasant to write in usual latex code, and typically would integrate well with the knowledge package.

A prototype idea is to generate the following definitions in a separate file

\knowledge{url={GENERATED_URL_HERE}}
  | ressource name @ bibtex entry name

Together with a command that allows to properly cite parts of a document as follows:

\NewDocumentCommand{\kcite}{ m m }{
   \cite[\kl(#1){#2}]{#1}
}

Concretely, this allows to easily write references in documents, with several keywords referencing the same "named destination" in the document.

This theorem has been proven by \kcite{colcombet2023}{Theorem 1.7} ...

While automating such a behavior is far from simple, a reasonable roadmap would be the following

1. Allow users to configure the format of the clipboard content using an environment variable.
2. Add a polished version of the \kcite command to the knowledge package

If this is not enough, the following can be done

3. Write a bibtex-reverse command taking as input the same arguments as resolve plus a path to a bibtex file. The output is the key of the document in the bibtex file.
4. Create a vim script (for demo purposes) that allows users to search for a paper, and uses the clipboard selection together with bibtex-reverse to automatically update the knowledge file, and produce the correct command.

Now it panics with value: Error("missing field ...").

Issue with the config dir creation:

thread 'main' panicked at 'called Result::unwrap()on anErrvalue: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:657:18

Issue with the clipboard dependencies:

thread 'main' panicked at 'called Result::unwrap()on anErrvalue: NoBinary', src/main.rs:818:40

Pdf viewers such as PDFjs or acrobat partially handle opening at given named destinations or pages (see https://helpx.adobe.com/acrobat/kb/link-html-pdf-page-acrobat.html).

The proposed syntax is

url#page=${page-num}
url#nameddest=${named-destination}
url#${named-destination}

Should we embrace this standard?

It seems that part of the job is already done by someone who re-implemented a pdf viewer :(

https://github.com/ahrm/sioyek

However, it does not handle named destinations and pages.

Right now a problem is to find documents that are present in the system. This is not particularly easy because of the filename limitations on various operating systems: we cannot place all metadata inside the filename.

A potential solution is to have a real index (xapian?) and search using this. However, an easy low-tech solution is to simply generate a pdf file that is a catalog of the available documents. It would then be fully searchable, and would also nicely interface with the rest of the programs.

Factor the code to have two manifests, one for chromium based browsers, and the others for firefox like ones. I don't know how to handle safari yet (see safari).

In the following paper https://arxiv.org/abs/2210.16580, the 10 authors create a filename that is too large for the operating system. In particular, the following uri command fails

akl://import-document/?payload=%7B%22uri%22%3A%22https%3A%2F%2Farxiv.org%2Fpdf%2F2210.16580%22%2C%22title%22%3A%22GPC%3A+A+Pattern+Calculus+for+Property+Graphs%22%2C%22authors%22%3A%5B%22Francis%2C+Nadime%22%2C%22Gheerbrant%2C+Am%C3%A9lie%22%2C%22Guagliardo%2C+Paolo%22%2C%22Libkin%2C+Leonid%22%2C%22Marsault%2C+Victor%22%2C%22Martens%2C+Wim%22%2C%22Murlak%2C+Filip%22%2C%22Peterfreund%2C+Liat%22%2C%22Rogova%2C+Alexandra%22%2C%22Vrgo%C4%8D%2C+Domagoj%22%5D%2C%22context%22%3A%5B%5D%2C%22identifiers%22%3A%5B%22https%3A%2F%2Farxiv.org%2Fabs%2F2210.16580%22%2C%22arxiv%3A2210.16580%22%2C%22https%3A%2F%2Farxiv.org%2Fpdf%2F2210.16580%22%5D%2C%22view%22%3Atrue%2C%22force%22%3Afalse%7D

When --interactive is set, the program should see whether it has access to a terminal window (in which case it should launch $EDITOR) or not (in which case it should use the open::that command on the text file).

This switch could be used to

1. prevent the download of pdf documents when switched off
2. allow querying crossref when importing a document to autofill the informations

The code handling the arxiv links should be removed from the rust program and delegated to the web extensions / another program.

The core of the program could be used to handle links outside of simple pdf files.

The easiest addition would be html pages. However, it is unclear how one should handle editable documents (odt, docx, md, etc.)

Build a script that does a migration from Zotero to the akl program.