Is it related to https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html
I implemented that idea for fun once: https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ John ----------------------------------- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sat, Dec 4, 2021 at 5:10 PM Samuel Wales <samolog...@gmail.com> wrote: > the quoted post below, which had message id > 20524da70901041233g105f372fv175a47dc9884f...@mail.gmail.com , starts a > thread relevant to the current discussion of syntax, at least > historically, maybe practically. could not find it online. > > there were succeeding threads with examples and other stuff for id > markers and graph-theoretic things and other examples, where you as > user could always use a cl-like syntax [i.e. something like > "$[functionality-name arg :keyword arg]"]. my main concern was the > proliferation of syntax, and the risks of that [e.g. parsing] and > wanting the ability of factoring of syntax features. > > display, parsing and so on would be shared [factored] among all the > different such features; org would always handle that the same. thus > as a user even, you could add some new feature in lisp, and write it > in org using this syntax. it would already work. > > i have more in notes. idk if it is still relevant, but i have > included the thread starter for the earliest thread [carsten/myself]. > > On 1/4/09, Samuel Wales <samolog...@gmail.com> wrote: > > A general idea, which might or might not be useful. > > > > There are occasionally questions about syntax, like this: > > > > Also, I'm afraid definition matching regexp won't play > > nicely with text indentation, ... -- Paul > > > > Or this: > > > > What would be safer? -- Carsten > > > > I like the footnote implementation, so this is for future > > features, not necessarily footnotes. > > > > One issue when implementing new syntax (or changing existing > > syntax or cleaning up code) is parsing risk, which I will > > define as the risk that the syntax and the regexp or > > matching code: > > > > 1) conflicts with user text > > 2) conflicts with existing features > > 3) will be hard to maintain > > 4) constrains future features by making them conflict > > syntactically > > 5) makes you run out of syntax to use in the future > > 6) will require complicated regexps > > 7) doesn't readily handle stuff you might want in the > > future, like being combined with another feature > > 8) will be hard to quote, escape, comment, *boldify*, etc. > > 9) doesn't handle nestability, print-readability, > > pretty-printability, syntax coloring, etc. > > 10) will be inefficient when called in a loop > > 11) isn't factored out > > 12) etc. > > > > For example, one of the many reasons for using org-IDs (:)) > > in the conversation manager (as proposed) is that there are > > already functions to parse org-IDs, so a new syntax is not > > necessary and therefore parsing risk is minimized. > > > > In case parsing risk is a concern when adding a new feature > > to org, here is one idea: have a generic syntax that is > > extensible with keywords. > > > > The idea is to have a bracketing syntax with a reserved > > keyword as the first element that says what you are doing. > > > > To use footnotes as an example (this is not a suggestion to > > change footnote syntax, just an example that can be used for > > future syntax): > > > > You might use something like "here is some text to be > > footnoted $[fn apple]" to specify the footnote link, and > > "$[fn-target apples are delicious]" to specify the target. > > > > The general point I want to make is that once such a syntax > > is decided on, many future features are possible without > > introducing parsing risk. > > > > For example, you can implement a new feature as > > "$[my-new-feature ...]". Then there is no parsing risk, > > even though you have just added a new feature. > > > > For modifications of features, you can use keywords: > > "$[my-new-feature ... :myparameter ...]". These are easily > > parsed by standard functions for parsing lists. > > > > You can develop ways to boldify, quote, nest, prettily > > print, etc. this syntax, and those ways will work well with > > all future features that use it. > > > > Of course, the dollar sign and brackets are not the only > > possibility; it could be percent sign and parentheses, for > > example. > > > > You will not be starting from scratch. Lisp has already > > worked out many of these issues. > > > > I will leave it to those who write massive amounts of org > > code to decide whether an extensible syntax might be useful > > to reduce parsing risk for future features. > > > > But I thought that I would propose the idea in case it is of > > interest. > > > > -- > > For personal gain, myalgic encephalomyelitis denialists are knowingly > > causing further suffering and death by grossly corrupting science. Do > > you care about the world? > > http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm > > > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > >
