Be able to use #+LINK definitions for URL shortcuts

[bam93]

The functionality I was most missing in lazyblorg is to be able to use tags for URL links (eg define a #+LINK: tag https://url.org/ in the org file and then use [[tag][linking to this tag]] in the actual blog text, so it is easier to check for/update dead links.

The LINK element happily also lives in a properties drawer (this is actually what I do, I have a properties drawer at the very top of the org file and put all my +LINKs in there). The way I am trying to set this up is to have one master file with all my links defined (maybe simple emacs abbreviations, I haven't quite decided) and then a couple of scripts that can easily check all my org-mode files at their top LINK definitions whether they are consistent with this master file or not (and may need to be updated/consolidated). Dead links can then easily be checked just by going through the master file.

It should in principle also be possible for the link definition not to be within the very same article they are referred to. I added a dictionary data structure to lazyblorg to manage this additional information. For now, I collect all the LINKs when URLs are parsed. In the way I implemented it, a dictionary is populated (in modified lazyblorg code) with all link definitions from all articles.

However, if there were the same tags with two different definitions, then only the last parsed would be used everywhere. That could also alternatively raise an error, if I implemented a "strict" checking. I want unique tags anyway. You mentioned that
you would not feel so optimistic about conflicting link definitions. When defining "foo" that points to site X and at a different place defining "foo" to point to site Y, this could be a big issue. So indeed that one should be able to handle with the strict checking idea, throwing an error that breaks the lazyblorg run until it is fixed in the data.

The one problem I have run into is that the parsing of [[link]] constructs and variants I have modified does not seem to apply for links in bulleted lists for instance. I haven't investigated this just yet, I guess they are maybe deferred to eg pandoc so the regexp parsing I adjusted is maybe not called in this case.

[bam93]

Here are the two files I modified to achieve what I wanted.
LinkParsing.zip

An example org file would have eg

:PROPERTIES:
#+LINK: lb-readme-w https://github.com/novoid/lazyblorg/blob/master/README.org
#+LINK: general-el-git-w https://github.com/noctuid/general.el
:END:

at the very top and then references like such in the body

Here I will try to describe a few of the customizations I made to simplify and streamline my blogging experience within Emacs. General information of requirements for lazyblorg are well described on the github page [[lb-readme-w][Readme file]]. We start from some org-mode file where you already have a heading and text section for something you want to blog about.

[novoid]

This discussion started as a Disquis thread at the bottom of this blog article of mine: https://karl-voit.at/2015/05/15/pypandoc-for-lazyblorg/

As I wrote there: I have to say that I won't implement things I don't use myself at the moment. If it doesn't interfere with existing functionality, I'm happy to check pull requests but I won't support this functionality myself.

Certain aspects needs to be clarified like, e.g., parsing needs to be done differently because definitions may be defined outside of blog article sub-hierarchies and definitions may contradict. My proposal is to adapt the parsing with a completely new data structure and abort lazyblorg with a helpful error message if any conflicting definition is found.

[bam93]

Thank you. I have now been working on this. I implemented error checking as you suggested with critical stop if there are inconsistencies. A LINKDEFS_STRICT_CHECKING boolean allows to raise an error and stop whenever something is defined multiple times. Although I thought this might happen when one wants the org files to be independent, so by setting that boolean to False it will warn but only raise an error and stop when something is re-defined differently than before.

Lists now also work, which was important to me. Some light pre-processing by looking up the dictionary is done before handing off to pypandoc.

I also did some code cleaning and worked on the error messages so they should be helpful and meaningful.

I am not sure I understand your remark about parsing. It seems to work as you suggest: eg even if you define "#+LINK" at the very top and not in a sub-hierarchy, it is parsed. Should I attach the latest version of the two modified files here, or would you prefer that I make a pull request?

[novoid]

Oh, wonderful news!

I'd prefer a pull request.