Re: [O] blogging wih org-mode
Many thanks to all for your replies, I am very thankful to your help. I have to make a choice, but of course I than everybody who replied to me. It is a wonderful list. Best wishes, -- Joseph
Re: [O] blogging wih org-mode
Hi Joseph, Others have recommended ox-hugo already, and I can only second the recommendation: https://ox-hugo.scripter.co I use ox-hugo to maintain two blogs/websites (since ox-hugo can easily deal with static pages as well, it can take over the whole content): - https://zzamboni.org, you can see the source here: https://github.com/zzamboni/zzamboni.org/tree/master/content-org - https://cf-learn.info, you can find the source here: https://github.com/zzamboni/cf-learn.info/tree/master/content-org The workflow is like this: org file -> ox-hugo export -> commit to github -> trigger Hugo build on Netlify -> publish on Netlify It works great for me. And Kaushal (ox-hugo's author) is here all the time, which is an added bonus :) Hope this helps, --Diego On Mon, Sep 30, 2019 at 12:06 AM Joseph Vidal-Rosset < joseph.vidal.ros...@gmail.com> wrote: > Hi the list, > > I would be glad to know what is, according to the majority, the best > tool to blog with org-mode. I'm searching something simple to use and > to install in order to blog with emacs, and, ideally, with emacs and > org-mode only. > > (I met difficulties with lazyblorg, for example. I did not succeed to > understand how it works.) > > Thanks for your help. > > Jo. > >
[O] small bash/awk script to query org-mode tables
hi, all. for a project, i wanted to be able to easily query the contents of a table in an org-mode document from the shell. in case that it might be useful to others, the result is: https://gitlab.com/minshall/org-query the beginning of the help output is: usage: org-query -h|--help : org-query [-f|--field column] [--complement] [--regexp] file [[table:]column] key : org-query -t|--tables file : org-query -c|--columns file [table[:]] : org-query -k|--keys file [[table:]column] it works for my use cases (obviously), but i'm sure it will break, or be feature-deficient, for those of others. i'd be happy to try to fix bugs. cheers, Greg ps -- if anyone knows how to get gitlab.com to recognize org-mode footnotes (in particular, of the [fn::"this is a footnote"]-variety), my readme.org file would be pleased to hear.
[O] How many other people want an org-mode client to the Canvas LMS API?
Hi everyone, I've been working away slowly on my primitive API client for the Canvas Learning Management System, which my university now uses ( https://github.com/titaniumbones/org-lms, note the documentation is terrible and may be misleading in places). The code is at my usual very low level of quality. I'm interested in improving it, but if I'm going to be the only person who ever uses it, my motivation to do so is somewhat more limited. So I just wanted to ask here if anyone else would really like to have this tool (I've asked before, but it's been a while). For me it's been kind of great, and along with ox-hugo has made it possible for me to keep all my course materials in one place. But it might not be worthwhile for others! Matt
Re: [O] small bash/awk script to query org-mode tables
Greg Minshall writes: > hi, all. > > for a project, i wanted to be able to easily query the contents of a > table in an org-mode document from the shell. in case that it might be > useful to others, the result is: > > https://gitlab.com/minshall/org-query Hi Greg, That's very cool, thanks for sharing. If I may, please consider renaming it to something like org-table-query.sh. org-query sounds more generic, and like an Emacs package, so users might confused it with something like org-ql (Org Query Language).
Re: [O] [RFC] Document level property drawer
Gustav Wikström writes: > Hi, > > This patch introduces a document level property drawer. > > This has been discussed previously in a larger context: > - https://lists.gnu.org/archive/html/emacs-orgmode/2019-06/msg0.html > - https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00339.html > - https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00010.html > > The patch is a somewhat modified version of what was included in the third > link above. How does it differ from what was previously proposed? > The following will be true for document level property drawers: > 1) In the same way that one can have a property drawer for a heading, one >can have a property drawer for a whole document. > 2) All existing commands that can work with property drawers will >(shall) work also on property drawers before the first heading. What exactly does "will (shall)" mean? > 3) Properties defined in a property drawer will have precedence over >properties defined as a property keyword, if the same property is >defined using both conventions. That protocol seems unnatural and confusing to me: - If precedence were to be defined by something other than file-order, it seems to me that those defined with #+ keywords should have precedence, because they are more visible, while those in drawers are hidden. - However, it seems to me that the simplest, most natural protocol would be for later declarations to override earlier ones. > 4) The position for the document level property drawer is: >- At the first line in a file that is not a comment or a keyword. > > I.e. the following will work: > > #+begin_src org ># -*- mode: org -*- >,#+TITLE: Test >:PROPERTIES: >:CATEGORY: Test >:END: > >Preamble > >,* Some heading >Some content > #+end_src > > > but not this: > > #+begin_src org >Some comment and/or empty line > >:PROPERTIES: >:CATEGORY: Test >:END: > >,* Some heading >Some content > #+end_src That feels unintuitive to me. Document-level property keywords may appear anywhere in a file, so it seems inconsistent for document-level property drawers to be limited in this way, as if there were an implied headline at the top of the file. If it were so, I would expect to see many mailing list posts by users asking why the properties defined in their document-level property drawers aren't working. Given that there is no enforcement in Org's UI to keep such drawers in certain places, I think the implementation should be tolerant of users' preferences and mistakes (cf. Postel's Law).
[O] sync a single subtree to a different file
I'm looking for a way to sync a given subtree to a different file, semi-automatically (it at the launch of a command). Is there something like that in org-mode ? Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune
Re: [O] [RFC] Document level property drawer
Adam Porter writes: > Gustav Wikström writes: > >> 3) Properties defined in a property drawer will have precedence over >>properties defined as a property keyword, if the same property is >>defined using both conventions. > > That protocol seems unnatural and confusing to me: > > - If precedence were to be defined by something other than file-order, > it seems to me that those defined with #+ keywords should have > precedence, because they are more visible, while those in drawers are > hidden. > - However, it seems to me that the simplest, most natural protocol would > be for later declarations to override earlier ones. I think it would be quite natural to use the tree structure of Org. A property setting in a subtree overrides the setting in a parent (which could be the document(= the whole file.)) >> 4) The position for the document level property drawer is: >>- At the first line in a file that is not a comment or a keyword. >> >> I.e. the following will work: >> >> #+begin_src org >># -*- mode: org -*- >>,#+TITLE: Test >>:PROPERTIES: >>:CATEGORY: Test >>:END: >> >>Preamble >> >>,* Some heading >>Some content >> #+end_src [...] > That feels unintuitive to me. Document-level property keywords may > appear anywhere in a file, so it seems inconsistent for document-level > property drawers to be limited in this way, as if there were an implied > headline at the top of the file. If it were so, I would expect to see > many mailing list posts by users asking why the properties defined in > their document-level property drawers aren't working. Given that there > is no enforcement in Org's UI to keep such drawers in certain places, I > think the implementation should be tolerant of users' preferences and > mistakes (cf. Postel's Law). TBH allowing document-level properties anywhere in an Org file looks rather messy to me. When a user is interested in all the document-level properties she needs to scan the whole file. Also the spread out document-level properties introduce a distinction between a whole Org file and an Org subtree. I think the distinction between Org file and Org subtree should be kept to a minimum. Wouldn't it be nice if Org files can be considered as Org subtrees? In this sense a property drawer for the document is a step in the right direction. Ciao, -- Marco
Re: [O] [RFC] Document level property drawer
Hi Adam, > How does it differ from what was previously proposed? It differs by not introducing the document concept in Org element. Removing that means there is no reason to wait for another major version of Org mode. > What exactly does "will (shall)" mean? You can ignore the inside of the parentheses. It carries no important meaning. > > 3) Properties defined in a property drawer will have precedence over > >properties defined as a property keyword, if the same property is > >defined using both conventions. > > That protocol seems unnatural and confusing to me: > > - If precedence were to be defined by something other than file-order, > it seems to me that those defined with #+ keywords should have > precedence, because they are more visible, while those in drawers are > hidden. > - However, it seems to me that the simplest, most natural protocol would > be for later declarations to override earlier ones. I'd argue that precedence already works that way. One has to take inheritance into account. With inheritance turned on, tell me which value for Property1 is used for the nodes in the following example: #+begin_src org ,* Node 1 ,* Node 2 :PROPERTIES: :Property1: Value1 :END: ,#+PROPERTY: Property1 Value2 #+end_src As you'll see line number already isn't the deciding factor. With two ways to define properties it makes sense to first think of which syntax to promote as "more important" and then to think of precedence rules for duplicates within each syntax. Having the same syntax for node level 0 as for regular nodes makes the property functionality easy to understand and congruent. Something I think is worth promoting by saying that property blocks on file-level has precedence over the keyword syntax. > > 4) The position for the document level property drawer is: > >- At the first line in a file that is not a comment or a keyword. > > > > I.e. the following will work: > > > > #+begin_src org > ># -*- mode: org -*- > >,#+TITLE: Test > >:PROPERTIES: > >:CATEGORY: Test > >:END: > > > >Preamble > > > >,* Some heading > >Some content > > #+end_src > > > > > > but not this: > > > > #+begin_src org > >Some comment and/or empty line > > > >:PROPERTIES: > >:CATEGORY: Test > >:END: > > > >,* Some heading > >Some content > > #+end_src > > That feels unintuitive to me. Document-level property keywords may > appear anywhere in a file, so it seems inconsistent for document-level > property drawers to be limited in this way, as if there were an implied > headline at the top of the file. If it were so, I would expect to see > many mailing list posts by users asking why the properties defined in > their document-level property drawers aren't working. Given that there > is no enforcement in Org's UI to keep such drawers in certain places, I > think the implementation should be tolerant of users' preferences and > mistakes (cf. Postel's Law). If you think of the document as an outline, something Org mode is all about, it makes sense to also think of things before the first headline as "node level 0". And with that way of conceptually thinking of the document it makes perfect sense to have a property drawer fixed at the top - in the same way as it is required for all other node levels. Regarding the placement of drawers, if you apply my patch on your end to test it out you'll see that the built in functionality to define properties creates the drawer for you. That's easy to do since it's positional rule is easy to derive by the system. Try for example org-set-property (C-c C-x p) and you'll get the drawer defined for you. In exactly the same way as it already works when you're inside a heading today. The lack of posts asking why properties defined on their outline nodes doesn't work tells me that positional requirements for property drawers already is well understood. Kind regards Gustav
[O] Inserting a link when setting a property
I'd like to be able to use C-c C-l (org-insert-link) to specify a link when setting a property value with C-c C-x p (org-set-property) but that key sequence isn't recognized in that mode. What's the best way to set things up so this works? Thanks, Rob.
Re: [O] blogging wih org-mode
i keep each blog entry in a subtree. then i export to html. then i paste into blogger. done. maybe not helpful, but maybe somebody will chuckle? -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.
Re: [O] How many other people want an org-mode client to the Canvas LMS API?
I am pretty interested in this. I can't use it this semester, but next semester I am teaching a new class where it might be useful. I don't have much time this fall to look into it, but I will have time in the spring before my class starts. Matt Price writes: > Hi everyone, > > I've been working away slowly on my primitive API client for the Canvas > Learning Management System, which my university now uses ( > https://github.com/titaniumbones/org-lms, note the documentation is > terrible and may be misleading in places). The code is at my usual very low > level of quality. I'm interested in improving it, but if I'm going to be > the only person who ever uses it, my motivation to do so is somewhat more > limited. So I just wanted to ask here if anyone else would really like to > have this tool (I've asked before, but it's been a while). For me it's been > kind of great, and along with ox-hugo has made it possible for me to keep > all my course materials in one place. But it might not be worthwhile for > others! > > Matt -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] small bash/awk script to query org-mode tables
Adam, thanks for the feedback. i hadn't known about org-ql -- very nice. i've renamed the gitlab *project* org-table-query-script, though i've kept the command, itself, the simpler org-query. does that seem reasonable? if so, i'll do whatever i need to give the gitlab URL for my project "that name" (and leave a forward pointer at the old URL, for whoever may have copied the current URL). cheers, Greg
Re: [O] [RFC] Replace lambda functions added to org-mode-hook with named funcs
On Fri, Oct 5, 2018, 6:42 AM Nicolas Goaziou wrote: Kaushal Modi writes: > I propose to replace such lamba functions with named functions. > Here's an example of diff on maint branch, after making one such change: > > -;; Remove overlays when changing major mode > -(add-hook 'org-mode-hook > - (lambda () (add-hook 'change-major-mode-hook > - 'org-show-block-all 'append 'local))) > +(defun org--unfold-all-blocks-on-major-mode-change () > + "Remove overlays when changing major mode." > + (add-hook 'change-major-mode-hook #'org-show-block-all 'append 'local)) > +(add-hook 'org-mode-hook #'org--unfold-all-blocks-on-major-mode-change) If that's a function added to `org-mode-hook', it is not useful to add "on major mode change". Certainly it's useful. Or at least in general it's a common *pattern* for a major mode to add a function to `change-major-mode-hook' so that if the user changes from that major mode to some other major mode, the function will be called and can put the buffer into a sensible state before the replacement mode function is called. The only curious thing about it to me is that this code is being run via `org-mode-hook' rather than in the `org-mode' body; but maybe there's some reason for that. Regarding the general issue: Grep shows me all of the following instances in the master branch (commit d215c3a8c0b4c027), where a lambda is added to a hook variable (a few of them in the form of commented suggestions to the user). It's never a good idea; all of these should be changed to use named functions, IMO. -Phil -*- grep -*- ./ob-core.el:1429:(add-hook 'org-mode-hook ./ob-haskell.el:66: (add-hook 'inferior-haskell-hook ./ol-w3m.el:171:(add-hook ./ol-w3m.el:176:(add-hook ./org-agenda.el:2246: (add-hook 'filter-buffer-substring-functions ./org-agenda.el:2935: (add-hook ./org-attach.el:697:;; (add-hook ./org-compat.el:813: (add-hook 'imenu-after-jump-hook ./org-compat.el:817: (add-hook 'org-mode-hook ./org-compat.el:880: (add-hook 'speedbar-visiting-tag-hook ./org-crypt.el:144: (add-hook 'auto-save-hook ./org-crypt.el:267: (add-hook ./org-ctags.el:196:(add-hook 'org-mode-hook ./org-ctags.el:59:;;(add-hook 'org-mode-hook ./org-indent.el:188:(add-hook 'filter-buffer-substring-functions ./org-mouse.el:1085:(add-hook 'org-agenda-mode-hook ./org-mouse.el:856:(add-hook 'org-mode-hook ./org-src.el:745: (add-hook \\='org-src-mode-hook ./org.el:15697: (add-hook 'after-save-hook ./org.el:18978:(add-hook 'occur-mode-find-occurrence-hook ./org.el:21221:(add-hook 'org-mode-hook ;remove overlays when changing major mode ./org.el:2916: (add-hook \\='org-capture-mode-hook
[O] fill function: Put a newline at the end of each sentence in paragraph.
Hi I am looking for a filling function, which puts a newline at the end of each sentence. I have one for LaTeX mode but it does not work in org mode. Anybody has a pointer? Regards Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
