Je prends des notes à l'aide de #dendron
( première Bulle à ce sujet https://liens.vincent-bonnefille.fr/?AGBhmA )

Bon, les WikiLinks c'est formidable
( Internal links : [[lien_popup_sujet]] - doc wiki )

J'appelle WikiLinks des liens internes, qui lient des pages/notes entre elles...
Comme sur #wiki quand on survol un de ces liens il affiche un popup !
Si on clique dessus, le lien ouvre la page vers laquelle cette note/lien pointe.

Trop deep

Mais, quand j'écris en #md_markdown avec #dendron ...
Je peux me retrouver avec une hiérarchie de notes assez deep (profonde)
Les liens contiennent en effet tout le chemin des sous-parties (séparées par un (.))

[[Root.sujet.partie.élément_child]]
= lien vers =>
Root > sujet > partie > élément_child

Le lien devient long
Difficile à lire
Il prend de la place dans le texte
Je voudrais qu'il prenne moins de place
( comme dans son état final, quand on "preview" le code en HTML )

: qu'il soit +lisible :
lire seulement le titre de la note/fiche ( sans le chemin entier )
EX/ [[gparent.parent.child_name]] -> [[child_name]]

Solution : plugin

Heureusement, #vscode regorge de plugins/extensions...
vscode-inline-fold permet de rétracter ("fold") les bouts de code trop longs ...
( par exemple, on pourra réduire "fold" une chaine de classes dans un élément HTML )

->

Regex / préférence :

Mes préférences avec le #Regex pour les WikiLinks :

  "[markdown]": {
    "inlineFold.regex":"\\[\\[(([\\.A-Za-zÀ-ú0-9_\\-\\:]{1,}?)\\.)([A-Za-zÀ-ú0-9_\\-\\:]{1,}?)\\]\\]",
    "inlineFold.regexFlags": "g",
    "inlineFold.regexGroup": 1,
    "inlineFold.unfoldedOpacity": 0.6,
    "inlineFold.maskChar": "",
    "inlineFold.after": "",
    "inlineFold.maskColor": "#000",
    "inlineFold.unfoldOnLineSelect": true,
    "inlineFold.autoFold": true,
  }

On peut ensuite ajouter un raccourcis pour afficher/masquer les Wikiliens...

Final #Regex

https://regex101.com/library/nlSi7u (me)
https://regex101.com/r/5R0WQ1/1 (other user)

Un peu de #Regex (de bon matin)
j'utilise souvent https://regex101.com
qui permet entre autres de sauvegarder
NOTE : /Regex101/ a un debugger !
--> https://regex101.com/r/BDV74e/1/debugger

je viens de découvrir https://www.debuggex.com (cette {bulle}) via :

• https://www.michaelperrin.fr/blog/2019/02/advanced-regular-expressions

"Test your regex by visualizing it with a live editor. JavaScript, Python, and PCRE."

Debuggex et les autres

/Debuggex/ indique cibler des entreprises
En payant on peut sauvegarder +de regex
... /D/ est il en toujours en dev ? ( blog posts : 2013 )
.... https://alternativeto.net/software/debuggex/about/ -> Discontinued

Semblables, à tester :
( moins bien ergonomiquement )

• /Regulex/：JavaScript Regular Expression Visualizer
  https://jex.im/regulex/#!flags=&re=%5E(a%7Cb)*%3F%24
• /i Hate Regex/ - The Regex Cheat Sheet
  https://ihateregex.io/

Story

J'ai voulu refaire un Parser de #md_markdown -> JS
Bon en Regex ca se fait mais la mutliplication des cas particuliers rend vite la chose compliquée ! Un bon outil de diagnostique/débug devient vite essentiel !

Pour quoi ?

#Pandoc fait bien le boulot !
Oui oui mais j'ai quelques habitudes particulières dans mon écriture au quotidien !
#écrire c'est structurel mais on a nos propres mods de prise de note par exemple.
Des mécanismes de renvois
Ex/ j'utilise @ et # ( pour les auteur.ices et tags ) : comme {ici}
Ex/ j'utilise des renvois (indent)
...
des choses qui sont absentes ou mal interprétées dans les parser "de base"
: ca me sufisait pas, je voulais mon propre moteur

Dans cette recherche

Un raccourcis : des Regex pour cibler les éléments de #md_markdown

• https://javascript.plainenglish.io/simple-markdown-parser-with-javascript-and-regular-expressions-f0c8d53449a4

liens ( [text de desc](http://monlien.fr) )

• https://medium.com/@mattkenefick/regular-expressions-markdown-to-html-anchors-1e7d52905517

• Embed :
  \[([^\]]+)\]\(([^\)]+)\)
  
  Debuggex Demo