Re: ob-scheme doesn't support :stdin?
Vladimir Nikishkin writes: > Is it true that ob-scheme doesn't support :stdin ? > > I just tried, and doesn't seem to work, although it works with ob-shell. > > (This is not a complaint, I just would like to confirm that I > understand things correctly.) Yes, that's true as far as I can tell: $ git grep :stdin lisp/ob-awk.el:;; - :stdin takes an Org data or code block reference, the value of lisp/ob-awk.el: (stdin (let ((stdin (cdr (assq :stdin params lisp/ob-sed.el: (stdin (let ((stdin (cdr (assq :stdin params lisp/ob-shell.el:(stdin (let ((stdin (cdr (assq :stdin params testing/examples/ob-awk-test.org:#+begin_src awk :stdin genseq :results silent testing/examples/ob-sed-test.org: #+BEGIN_SRC sed :stdin ex1 So it seems support for :stdin is limited to awk, sed, and shell.
ob-scheme doesn't support :stdin?
Hello, friends. Is it true that ob-scheme doesn't support :stdin ? I just tried, and doesn't seem to work, although it works with ob-shell. (This is not a complaint, I just would like to confirm that I understand things correctly.) -- Yours sincerely, Vladimir Nikishkin
Re: Recommended global keybindings in the guide vs the manual
Nick Dokos writes: > org-guide.org:Introduction/Activation says: > > --8<---cut here---start->8--- > Add the following lines to your Emacs init file. The last four lines > define /global/ keys for some commands---please choose suitable keys > yourself. > > #+begin_src emacs-lisp > ;; The following lines are always needed. Choose your own keys. > (global-set-key (kbd "C-l") 'org-store-link) > (global-set-key (kbd "C-a") 'org-agenda) > (global-set-key (kbd "C-c") 'org-capture) > (global-set-key (kbd "C-b") 'org-switchb) > #+end_src > --8<---cut here---end--->8--- I was surprised to see the ones above because they're overriding some pretty central Emacs bindings. It looks like the "-c " in the middle was unintentionally dropped in the guide's .texi to .org conversion (1a678f184). > I realize that it says to "choose suitable keys yourself", but > surely, these should be identical to what the full manual recommends? I've pushed 36cd249e7, which brings the guide's recommneded bindings in agreement with the manual's. Thanks for reporting.
RE: attachment: link type export to HTML invalid attach dir
Ok, so change pushed... Where org-element-link-parser now sets one extra property only for attachment links. The exporters and org-link-open use this additional information when exporting and opening attachment links. Feature parity with file links should now be complete. Note that exporters outside of the Org mode repo need to be aware of the attachment link type if the path expansion is to be correct. They aren't translated in between into file-links. Not doing that translation is the proper think in my opinion. No magic hiding of the attachment link type. Who knows - maybe some exporters in the future need the link as is, without expansion!?. Making an exporter in the wild aware of attachment links can be done using org-element-property and the new property :attachment-path created by the parser only for attachment links. Regards Gustav > -Original Message- > From: Gustav Wikström > Sent: den 17 januari 2020 19:36 > To: Nicolas Goaziou > Cc: emacs-orgmode@gnu.org > Subject: RE: attachment: link type export to HTML invalid attach dir > > Hi again, > > > -Original Message- > > From: Gustav Wikström > > Sent: den 17 januari 2020 15:30 > > To: 'Nicolas Goaziou' > > Cc: emacs-orgmode@gnu.org > > Subject: RE: attachment: link type export to HTML invalid attach dir > > > > Hi, > > > > [...] > > > > > > > > It is true that Element library expands link abbreviations right > > > before parsing a link, and an attachment is similar to a local link > > abbreviation. > > > This is not great because some information is lost in the > > > process: interpreting the parse tree will not bring the abbreviation > > > back, only its expanded form. Actually, `org-link-expand-abbrev' is > > > called so that the parser knows what is the true type of the link, > > > since abbreviations could expand to anything. OTOH, attachments can > > > only expand to a "file" link, so the motivation for expansion > > > doesn't > > hold. > > > > Hmm, interesting... And are we sure the destructive behavior is > > something we want to maintain? I for one would vote for the parsers > > ability to provide information that can reconstruct the source... Is > > it really worth the space saving in the parse tree to do that > > destruction? I feel inclined here to add a :link and :raw-path > > property to the output from the link parser for example. That would > > allow those links that expand to be stored in the parse tree in both > expanded and non-expanded form. > > > > Reasons against? > > Hmm, I'm actually kind of going full circle here, back to think that the > logic currently implemented is in its right place... Either that, or to > just decorate the link in the parse-tree with some auxiliary information > that can be specific for the type of link. For attachment links that > auxiliary information would be attachment-path-prefix (or something > shorter but possibly less clear). For abbreviated links possibly the > auxiliary information would be it's unexpanded form. But I'm not sure of > the necessity or need for that, except from allowing interpreters to > reconstruct the original link. > > > > > [...] > > > > Regards > Gustav
Recommended global keybindings in the guide vs the manual
org-guide.org:Introduction/Activation says: --8<---cut here---start->8--- Add the following lines to your Emacs init file. The last four lines define /global/ keys for some commands---please choose suitable keys yourself. #+begin_src emacs-lisp ;; The following lines are always needed. Choose your own keys. (global-set-key (kbd "C-l") 'org-store-link) (global-set-key (kbd "C-a") 'org-agenda) (global-set-key (kbd "C-c") 'org-capture) (global-set-key (kbd "C-b") 'org-switchb) #+end_src --8<---cut here---end--->8--- I realize that it says to "choose suitable keys yourself", but surely, these should be identical to what the full manual recommends? --8<---cut here---start->8--- #+begin_src emacs-lisp (global-set-key (kbd "C-c l") 'org-store-link) (global-set-key (kbd "C-c a") 'org-agenda) (global-set-key (kbd "C-c c") 'org-capture) #+end_src --8<---cut here---end--->8--- Right? -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
RE: attachment: link type export to HTML invalid attach dir
Hi again, > -Original Message- > From: Gustav Wikström > Sent: den 17 januari 2020 15:30 > To: 'Nicolas Goaziou' > Cc: emacs-orgmode@gnu.org > Subject: RE: attachment: link type export to HTML invalid attach dir > > Hi, > > [...] > > > > > It is true that Element library expands link abbreviations right > > before parsing a link, and an attachment is similar to a local link > abbreviation. > > This is not great because some information is lost in the > > process: interpreting the parse tree will not bring the abbreviation > > back, only its expanded form. Actually, `org-link-expand-abbrev' is > > called so that the parser knows what is the true type of the link, > > since abbreviations could expand to anything. OTOH, attachments can > > only expand to a "file" link, so the motivation for expansion doesn't > hold. > > Hmm, interesting... And are we sure the destructive behavior is something > we want to maintain? I for one would vote for the parsers ability to > provide information that can reconstruct the source... Is it really worth > the space saving in the parse tree to do that destruction? I feel inclined > here to add a :link and :raw-path property to the output from the link > parser for example. That would allow those links that expand to be stored > in the parse tree in both expanded and non-expanded form. > > Reasons against? Hmm, I'm actually kind of going full circle here, back to think that the logic currently implemented is in its right place... Either that, or to just decorate the link in the parse-tree with some auxiliary information that can be specific for the type of link. For attachment links that auxiliary information would be attachment-path-prefix (or something shorter but possibly less clear). For abbreviated links possibly the auxiliary information would be it's unexpanded form. But I'm not sure of the necessity or need for that, except from allowing interpreters to reconstruct the original link. > > [...] > Regards Gustav
RE: Missing `org-attach-set-inherit' function
Hi, > -Original Message- > From: Emacs-orgmode On > Behalf Of stardiviner > Sent: den 17 januari 2020 08:39 > To: emacs-orgmode@gnu.org > Subject: Missing `org-attach-set-inherit' function > > > I found the function ~org-attach-set-inherit~ is missing. I noticed it in > the Info document. > > #+begin_quote > ‘i’ (‘org-attach-set-inherit’) > Set the ‘ATTACH_DIR_INHERIT’ property, so that children use > the same directory for attachments as the parent does. > #+end_quote I can't find that reference in the newest version of the documentation. Should be removed since commit ae9cd437. Are you sure the documentation and your Org mode version is the same? > > -- > [ stardiviner ] >I try to make every word tell the meaning what I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >
RE: attachment: link type export to HTML invalid attach dir
Hi, > -Original Message- > From: Nicolas Goaziou > Sent: den 17 januari 2020 01:40 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: attachment: link type export to HTML invalid attach dir > > Gustav Wikström writes: > > > Hardcoding the translation of attachment-links into file-links in an > > in-between layer (ox.el - that is somewhat complicated as well) is not > > transparent and I think best to avoid. Even if an attachment link is > > /very/ similar to a file link it may be best still to treat them for > > what they are. If some export back-ends out in the wild don't work > > with attachment-links today then so be it. But let's at least make it > > easy to fix! So I'll try to remove the hard coding of org-attach > > invocation and instead make the attachment-path when parsed by > > org-element return a path that is an actual file-system path out of > > the box. I'll see what I figure out in terms of code I suppose...! > > > > What do you say? > > It is true that Element library expands link abbreviations right before > parsing a link, and an attachment is similar to a local link abbreviation. > This is not great because some information is lost in the > process: interpreting the parse tree will not bring the abbreviation back, > only its expanded form. Actually, `org-link-expand-abbrev' is called so > that the parser knows what is the true type of the link, since > abbreviations could expand to anything. OTOH, attachments can only expand > to a "file" link, so the motivation for expansion doesn't hold. Hmm, interesting... And are we sure the destructive behavior is something we want to maintain? I for one would vote for the parsers ability to provide information that can reconstruct the source... Is it really worth the space saving in the parse tree to do that destruction? I feel inclined here to add a :link and :raw-path property to the output from the link parser for example. That would allow those links that expand to be stored in the parse tree in both expanded and non-expanded form. Reasons against? > Besides, there's no good reason to store redundant, or even remote, > information in the parse tree. The parser needs to be as low level as > possible. Yes, this is a reason against... But big enough? I humbly question that a bit. Also, would it be feasible to store the original "raw" form only if it differs from the expanded form? It may complicate the interpreters work though... They would have to have a bit more insight into when the original form will be needed. Not sure of the better design decision here. > Moreover, the issue encountered here is specific to export, so it makes > sense to solve at the export level, i.e., in "ox.el". This is not trivial > though, as it needs to be done very early, much link footnotes. > Indeed, since the meaning of the link is position dependent, including > parts of a document, or executing arbitrary code can mess it up. IOW > expansion should happen in `org-export--prepare-file-contents', i.e., > within every included piece of text, and in `org-export-as', somewhere > after `org-export-expand-include-keyword' call, but before Babel code > execution. It's actually not only specific to exporting. Opening attachment links show a similar issue (org-link-open). Because the current way to open files and attachments differ. And it shouldn't have to! That as well would be solved if the link parser would take care of the path expansion. One example of the difference today is that attachment links cannot abide to any prefix argument. As a user I would expect the prefix arguments that work for files to also work for attachments. Something I think we can fix here, by making the parser do a little bit more work. I'd be happy to apply a patch. Kind regards Gustav
ob-scheme haunted source code block?
Hi list, I've been learning some Scheme recently and decided to use Org mode and babel so I could document my progress, keep notes, etc. together with the code I write. I also installed the geiser package to work with Scheme source files directly. This all worked perfectly, until I made the (apparent) mistake of typing =C-c C-c= on an expression while editing a source code block. That is, I had pressed =C-c '= in an Org buffer on a source block and in the editing buffer that popped up, I hit =C-c C-c= (bound to =geiser-eval-definition=) on a particular function (well procedure...) definition. From that moment on, that particular procedure definition seems haunted. Whenever I evaluate a source block containing it from within an Org file, the associated REPL is doomed. It takes about 30 seconds for the evaluation to complete, during which time Emacs seems to hang (no CPU activity, just waiting). Any further interaction with the REPL from that point on, either from other source blocks in the same file (all source blocks in it use the same session) or in the REPL buffer directly, causes the same hang. I can `C-g` out of the hang, but this doesn't solve much because any further interaction causes the same hang. Putting the relevant procedure definition in a Scheme source file and evaluating that (within Emacs, through geiser) is unproblematic, so the code itself is not to blame. The weirdest thing about this is that the problem is persistent. I restarted Emacs and in my desperation even rebooted the computer, but to no avail. Does anyone have any idea what might be going on? I rgrepped through my =.emacs.d= directory to see if the relevant procedure name turns up anywhere but found nothing. I'm not really sure where to look beyond that. Versions: IELM> emacs-version "26.3" IELM> org-version "9.3.1" TIA Joost -- Joost Kremers Life has its moments
