Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hello again, I'm still a fan of Org as an IETF registered MEME type, but I recently heard of what Rust did to get text/rust registered on Linux systems: https://bugs.freedesktop.org/show_bug.cgi?id=90487 Perhaps we could submit a similar patch? -- Timothy.
Items with emphasis marks are not sorted properly in a list
Hi, Consider this list: - vol. - adj. - /circa/ - /vid./ If I evaluate `(org-sort-list t ?a)', it seems that `org-sort-list' doesn't sort correctly items that contain an emphasis mark: - /circa/ - /vid./ - adj. - vol. I don't know if there is any solution to this, or if I'm doing something wrong... Best regards, Juan Manuel
Re: noweb syntax clashing with shell here document syntax
You can choose which delimiters signal noweb. see the documentation of org-babel-noweb-wrap-start and org-babel-noweb-wrap-end. Immanuel On Mon, Mar 22, 2021 at 5:35 PM Sebastian Miele wrote: > > Hello! > > The noweb syntax seems to clash with the syntax of here documents in > shell scripts. In the block like > > #+BEGIN_SRC shell :noweb yes > echo a > <> > echo b > #+END_SRC > > everything following the line with the the noweb reference does not > get fontified properly. I suspect that the problem already is known > for a long time. Is that true? If yes, what is the status of this > issue? Is there a known workaround? > > At least in ZSH it may very well be the case that a line ending with > '>>' never is valid, except in cases where something like an '< before it is not an opening of a here document. So it possibly is > something that could be fixed in sh-script.el. But I do not know > exactly. > > Anybody who already knows more about this? > > Best wishes > Sebastian > -- -- Researching the dual problem of finding the function that has a given point as fixpoint.
noweb syntax clashing with shell here document syntax
Hello! The noweb syntax seems to clash with the syntax of here documents in shell scripts. In the block like #+BEGIN_SRC shell :noweb yes echo a <> echo b #+END_SRC everything following the line with the the noweb reference does not get fontified properly. I suspect that the problem already is known for a long time. Is that true? If yes, what is the status of this issue? Is there a known workaround? At least in ZSH it may very well be the case that a line ending with '>>' never is valid, except in cases where something like an '<
[PATCH] Update example :publishing-function names in manual
--- doc/org-manual.org | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 0dbc5e205..d75828722 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -15845,12 +15845,12 @@ and possibly transformed in the process. The default transformation is to export Org files as HTML files, and this is done by the function ~org-html-publish-to-html~ which calls the HTML exporter (see [[*HTML Export]]). But you can also publish your content as PDF files using -~org-publish-org-to-pdf~, or as ASCII, Texinfo, etc., using the +~org-latex-publish-to-pdf~, or as ASCII, Texinfo, etc., using the corresponding functions. If you want to publish the Org file as an =.org= file but with /archived/, /commented/, and /tag-excluded/ trees removed, use -~org-publish-org-to-org~. This produces =file.org= and put it in the +~org-org-publish-to-org~. This produces =file.org= and put it in the publishing directory. If you want a htmlized version of this file, set the parameter ~:htmlized-source~ to ~t~. It produces =file.org.html= in the publishing directory[fn:140]. -- 2.30.2
Re: source blocks DAG evaluation
Hello Thomas! That is fairly nice, thanks! I can use it for the moment. I see a minor problem, if you export it, the last block will show all the code and that may be redundant or undesired. But that can be solved fiddling with exporting options or code I guess. btw, using :noweb no-export, just leaves the <> sintax, so it's not what I want. In this sense it also doesn't do any cycle resolving, when a there is one it just fails with "org-at-heading-p: Variable binding depth exceeds max-specpdl-size" That may be ok, you shouldn't have cycles. But there is a more realist problem, you *can* have, diamonds dependencies. Say libA -> libB -> libD -> main \> libC / If you <> from main, you will get two copies of libA source code. That may be a problem in some languages and it's definitely bad at export time. The good about noweb expansion is that you can ignore the problem with the sessions all together and it will work with things that doesn't have sessions at all (now I remember a home work in assembler that I did in org-mode with noweb expansion ...) So, maybe if I try to improve anything, to address this issue, maybe is the code for noweb expansion? Maybe some options to conditional output the template expansion or just remove the <<*>> calls. I don't know if the semantics of what I want go along a template expansion ... I have the feeling that we might need something particular for this, like a (require ...) for org-mode source blocks. thanks! COD. "Thomas S. Dye" writes: > Aloha c4to, > > I would be tempted to use noweb expansion here. > > #+name: libB > #+begin_src scheme :results none :noweb yes > > <> > (define greetings (string-append hi ", " "to all the people!")) > #+end_src > > #+begin_src scheme :session example :results output :noweb yes > <> > (display greetings) > #+end_src > > Does this do what you want? > > All the best, > Tom > > c4t0 writes: > >> Hi, >> >> Is it possible to have a dependency hierarchy of source blocks? >> >> i.e.: in C, if you use libA from a compilation unit and that >> library needs libB, you don't need to include it in main.c >> >> -> main.c >> #include "libB.h" >> -> libB.c >> #include "libA.h" >> >> you don't need to: >> -> main.c >> #include "libB.h" >> #include "libA.h" >> >> because library headers are closed under inclusion. >> >> I haven't succeeded in doing the same in org-mode. Even after >> populating org-babel-library-of-babel. >> >> Using #+call just doesn't work. Using :var is better, evaluates >> all, but there appears to lack session support, it doesn't check >> for cycles and it feels a little hacky >> >> With #+call I need to do it like this: >> >> #+name: libA >> #+begin_src scheme :results none >> (define hi "hello") >> #+end_src >> >> #+name: libB >> #+begin_src scheme :results none >> (define greetings (string-append hi ", " "to all the people!")) >> #+end_src >> >> here is my "main" I need to C-c C-c in each #+call line and >> write the :session that the code block uses in each one, and do >> it in the correct order. If I C-c C-c in libB first it won't >> eval because 'hi' is not defined. >> >> #+call: libB[:session example] >> #+call: libA[:session example] >> #+begin_src scheme :session example :results output >> (display greetings) >> #+end_src >> >> source blocks can be #+call(ed) but aren't closed under #+call >> (a source block can be called but then the callee won't) >> >> instead I would like to : >> >> #+name: libA >> #+begin_src scheme :results none >> (define hi "hello") >> #+end_src >> >> #+call: libA >> #+name: libB >> #+begin_src scheme :results none >> (define greetings (string-append hi ", " "to all the people!")) >> #+end_src >> >> #+call: libB >> #+begin_src scheme :session example :results output >> (display greetings) >> #+end_src >> >> - there shouldn't be needed to C-c C-c in the #+call line, >> evaluating the source block alone should suffice. >> - there shouldn't be a need to write the :session >> - it should use the session of the user evaled block, unless >> specified otherwise >> >> In the other hand, using :var with a dummy variable: >> >> #+name: libA >> #+begin_src scheme :results none >> (define hi "hello") >> #+end_src >> >> #+name: libB >> #+begin_src scheme :results none :var _=libA >> (define greetings (string-append hi ", " "to all the people!")) >> #+end_src >> >> #+HEADER: :var _=libB >> #+begin_src scheme :session example :results output >> (display greetings) >> #+end_src >> >> It evals libA then libB and finally the (display greetings) >> code. >> But it fails, because the :session example is ignored. Even if I >> add a :session example to every source block (which would be >> really bad, sessión must be decided by the consumer) it doesn't >> work. I think that is because :var expects a value, so it just >> opens a new session to evaluate code every time. >> >> Besides if there are any dependency cycles, it just fails with: >> Lisp nesting exceeds ‘max-lisp-eval-depth’
Bug: Org manual, 16.15.2 The ‘capture’ protocol, possible error [9.4.4 (release_9.4.4 @ /home/admin/Programming/Software/emacs/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. 16.15.2 The ‘capture’ protocol -- Activating the “capture” handler pops up a ‘Capture’ buffer in Emacs, using acapture template. emacsclient org-protocol://capture?template=X?url=URL?title=TITLE?body=BODY In my opinion above line has errors and places "?" where actually the symbol "&" should be. This works: emacsclient 'org-protocol://store-link?url=http://www.gnu.org=GNU.org' while this does not work: emacsclient 'org-protocol://store-link?url=http://www.gnu.org?title=GNU.org' Thus the line should be shown as below in the manual: emacsclient org-protocol://capture?template=X=URL=TITLE=BODY and I would recommend quoting: emacsclient 'org-protocol://capture?template=X=URL=TITLE=BODY' Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw scroll bars) of 2021-03-15 Package: Org mode version 9.4.4 (release_9.4.4 @ /home/admin/Programming/Software/emacs/lisp/org/) -- Thanks, Jean Louis ⎔ λ 퍄 팡 팚
Re: Bug: Org bold emphasis gobbles leading stars on next headline [9.3.7 (release_9.3.7-710-g3f04ad @ /home/n/.emacs.d/straight/build/org/)]
> No Wayman writes: > > With the following Org mode file and point denoted by "|": > > > > * Parent > > | > > ** Sibling > > > > Insert the text "*", resulting in: > > > > * Parent > > "*"| > > ** Sibling > > > > textually, but the final star of the Sibling heading is hidden as > > well: > > > > * Parent > > "*"| > > Sibling > > > > I believe the org-hide face is being overridden by the bold face. > > Indeed, I can reproduce this bug with latest Org. > > -- > Bastien I can also reproduce this bug: https://emacs.stackexchange.com/questions/64021/headings-in-org-mode-unexpected-behavior After setting `org-hide-emphasis-markers' back to nil (the default), it goes away. Perhaps that's helpful for fixing it. All the best, Greg
Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
On Fr 19 Mär 2021 at 13:33, Eric S Fraga wrote: > With respect to the topic at hand, I believe it's the result of the same > tendency that Excel users have of using spreadsheets (aka tables) for > everything, something I hate when I'm given some Excel sheet that I need > to modify and where entries are huge paragraphs. The UI in Excel is > horrible for these types of tables. I would hate to see org go in the > same direction. +1 for that Unfortunately I have to deal with this type of people at work. > In many cases, I believe that a simple text based database format would > be more appropriate. I wonder if the time would be better spent > providing native support for GNU recutils [1] in org instead. recutils has an emacs mode an I think it even has some sort of org-mode integration. 'Andreas
Re: trivial software engineering'ish question: switching org's
On 22/03/2021 00:44, Greg Minshall wrote: hi. i occasionally want to switch from the org package to a git version, then back again. and, i want to avoid the dread "mixed installation". Do you really need to switch or just to launch it a couple of times? Is it required to run namely compiled version? Actually I am unsure if the following way is reliable or it has some problems that I have not discovered yet. emacs -q -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp file.org Unfortunately -L (--directory) options are processed after ~/.emacs.d/init.el, that is why -q (--no-init-file) is added. I had (require 'org-protocol) in init.el file and a part of org bundled with emacs were loaded before processing of -L. If there is no setup for alternative org version, the file could be loaded after -L options using -l ~/emacs.d/init.el (--load), alternatively a bit cleaned variant of init.el from another directory could be specified. I do not recommend to skip contrib directory. I noticed that due to system-wide configs some files could be loaded from older org contrib.
Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
On Sunday, 21 Mar 2021 at 09:06, Tim Cross wrote: > However, often now, I'm presented with a spreadsheet (or workbook) > with not a single calculation or cell formula -it is just about > formatting. Exactly. And this is why I am not happy about org being modified to enable this. Make the path of least resistance the most attractive: > In many ways, workbooks are being treated like a poor persons slow > inefficient database with a really poor interface. And also why I suggested that it would be good to have some type of database functionality in org. Well, we do already in the form of properties. I use these, with column view, all the time, but maybe we need to think about how such are exported and encourage its use? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
Re: trivial software engineering'ish question: switching org's
Tim and Gustav, thanks for your answers. in particular, straight.el does seem promising. i'll set it up, use it with Tim's "switching use-package blocks", and see how it goes. cheers, Greg
Re: Sharing variables between source blocks without session
Eric S Fraga writes: > On Friday, 19 Mar 2021 at 14:59, Loris Bennett wrote: >> To be honest, I find it is a wee bit confusing that it's >> >> #+PROPERTY: header-args:sh :var user="loris" >> >> *without* a colon after the language (if I add it, there is not error, >> but the variable is just not set) but >> >> :PROPERTIES: >> :header-args:sh: :var user="loris" >> :END: > > When in a property drawer, the name of the property you want to set is > enclosed within a pair of :s. When in a #+PROPERTY statement, there is > no need for the :s, just the name. It's not about the language part of > it at all. Thanks for the clarification. I didn't think it was about the language part - I was just using the position describe which colon I meant. The colon gets to do quite a lot of work in Org :-) Cheers, Loris -- This signature is currently under construction.
Re: Invalid function: org-preserve-local-variables
Kyle Meyer writes: > Loris Bennett writes: > >> Hi, >> >> I'm running >> >> Org mode version 9.4.4 (9.4.4-25-g3a522a-elpaplus @ >> /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/) >> >> and today I encountered the following error when refiling >> >> org-refile: Invalid function: org-preserve-local-variables >> >> Despite the error, the refiling itself did however work. >> >> I am fairly sure that I have refiled without seeing this error message >> since I last updated Org, thus I am somewhat surprised by it. > > org-preserve-local-variables is a macro defined in org-macs.el. That > file is loaded by org.el, which is loaded by org-refile.el. So, I think > everything looks fine there. > > My guess---especially if you're running Emacs 26 or lower, which ships > with an Org that didn't yet have org-preserve-local-variables---is that > you have a mixed installation. list-load-path-shadows might reveal the > problem. > > https://orgmode.org/worg/org-faq.html#mixed-install Thanks for the information and the suggestions. I am running 26.1. The Org version is Org mode version 9.4.4 (9.4.4-25-g3a522a-elpaplus @ /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/) list-load-path-shadows lots of lines like /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/ox-md hides /home/loris/.emacs.d/elpa/org-20210222/ox-md where elpa/org-plus-contrib hides elpa/org, and lots of lines like /home/loris/.emacs.d/elpa/org-plus-contrib-20210222/ox-md hides /usr/share/emacs/26.1/lisp/org/ox-md where elpa/org-plus-contrib hides Org from the OS. Having both org and org-plus-contrib installed from ELPA has always bothered me a bit, but I seem to remember that certainly at some point several years ago, there was an issue (to do with dependencies? or use-package?) which meant I had some problems with org-plus-contrib on its own. Maybe that was wrong back then and maybe is still wrong now. However, duckduckgoing a bit I find the following issue https://github.com/jwiegley/use-package/issues/597 from a few years back. Maybe that's what I was hitting. I'll change make my set-up to just use org-plus-contrib and see whether I can reproduce the org-preserve-local-variables error. Cheers, Loris -- This signature is currently under construction.
