[O] Bug: Feature request: make org-link emacs wide mode [9.2.5 (9.2.5-elpa @ /home/data1/protected/.emacs.d/elpa/org-20190801/)]
Emacs : GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2019-08-04 Package: Org mode version 9.2.5 (9.2.5-elpa @ /home/data1/protected/.emacs.d/elpa/org-20190801/) I would like to request feature so that Org Links can be turned on Emacs wide as org-link-mode. Then links could work in various buffers, and this could make hyperlinking possible from any kinds of files. Jean
[O] Bug: Feature request: make org-links elisp functions take parameter [9.2.5 (9.2.5-elpa @ /home/data1/protected/.emacs.d/elpa/org-20190801/)]
Emacs : GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2019-08-04 Package: Org mode version 9.2.5 (9.2.5-elpa @ /home/data1/protected/.emacs.d/elpa/org-20190801/) I can see that Hide Org Link Abbrev Alist: can accept emacs lisp function. The function is then probably just receiving the button information. If I understand it well. What would be really useful is to add possibility for emacs lisp function to accept parameter directly from the button. If this is the link: [[contact:481550][Profile of Mr. John Doe]] then "contact" could be name for the link that invokes Emacs Lisp function with the value 481550. Person could click on the link and go straight to profile of Mr. John Doe. Profile would be invoked within GNU Emacs, and not in browser. As URL links have their corresponding %s option to add the value, so the Emacs Lisp functions should also get their corresponding option that value can be added. -- Thanks, Jean Louis
Re: [O] Bug: Feature request: make org-link emacs wide mode [9.2.5 (9.2.5-elpa @ /home/data1/protected/.emacs.d/elpa/org-20190801/)]
> I would like to request feature so that Org Links can be turned on > Emacs wide as org-link-mode. Then links could work in various buffers, > and this could make hyperlinking possible from any kinds of files. For reference: https://github.com/seanohalpin/org-link-minor-mode https://github.com/tarsius/orglink -- Štěpán
[O] nested plain lists
Hi I know it is possible to have simple, enumerated (and other type of lists), but I can't find information concerning nested lists, such as 1. 1.1. 1.2. Is this possible? Somebody knows about it? Thanks Uwe Brauer
Re: [O] nested plain lists
Hi Uwe, Yes, this is supported and documented: https://orgmode.org/manual/Plain-lists.html For example: 1. Item 1 1. Sub item 1.1 1. Sub-sub item 1.1.1 2. Sub Item 1.2 2. Item 2 1. Sub item 2.1 --Diego On Wed, Aug 7, 2019 at 3:52 PM Uwe Brauer wrote: > > > Hi > > I know it is possible to have simple, enumerated (and other type of > lists), but I can't find information concerning nested lists, such as > > 1. > > 1.1. > > 1.2. > > Is this possible? Somebody knows about it? > > Thanks > > Uwe Brauer > > >
Re: [O] getting access to a self-invented option?
On Sat, Aug 3, 2019 at 1:28 AM Thibault Marin wrote: > Hi, > > I am not sure where you are trying to get to the value (in the > publishing function?), but I use something like the following to handle > custom keywords: > > , > | #+MWP_EXPORT_TYPE: slides > | > | #+name: elt > | #+begin_src emacs-lisp :results silent :exports none > | (let ((tree (org-element-parse-buffer))) > | (org-element-map > | tree 'keyword > | (lambda (r) > | (let ((key (org-element-property :key r)) > | (value (org-element-property :value r))) > | (when (string= key "MWP_EXPORT_TYPE") > | value))) ;; Return the keyword value > | nil t)) > | #+end_src > ` > > If you have access to the parsed tree or the buffer filename, you may be > able to use this or something similar (maybe wrapped in a function). > > Hope it helps. > > I think this is a pretty good option -- I would use this in an interactive function that is called from the org buffer, so I should be able to parse it. I keep all my lectures in a single file, and same for all my other course materials, so I guess I will have to do some testing and see how long the parse operation takes...
Re: [O] getting access to a self-invented option?
On Sat, Aug 3, 2019 at 1:42 PM Berry, Charles wrote: > Matt, > > This seems like a good use case for a `derived-backend'. > > You can use `org-export-define-derived-backend' with 'hugo as the parent, > define a :menu-entry to add an export action for your custom export to the > hugo menu using '?m' (say) as the key. > > Then > > C-c C-e H m > > will export using your custom variant of hugo. > > :-) I'm trying to use the variable to determine whether I export with hugo or with my hugo-reveal franken-backend: https://github.com/titaniumbones/ox-huveal . So my preference is to evaluate the variable BEFORE export begins. I guess another option is to just set a buffer-local variable in the file, or use #+FILETAGS: and hack htings that way. I'm not sure what the most sustainable & org-like method relaly is... > > HTH, > > Chuck > > > > On Aug 2, 2019, at 9:10 AM, Matt Price wrote: > > > > I'm trying to streamline some veyr ad-hoc workflows I have. One thing I > do a lot during the school year is make some changes to an org source file, > and then export to hugo markdown with ox-hugo, and finally commit to git > (after that I have a git hook that generates the website & uploads the > changed pages to the appropriate location, usually a github-pages branch or > separate repo). > > > > So I have this code: > > > > (defun mwp-hugo-export-and-release () > > "Make it faster and easier to put my lectures up on the website." > > (interactive) > > > > (let* ((modfile (org-hugo-export-wim-to-md)) > > (basedir (plist-get (org-export-get-environment 'hugo) > ':hugo-base-dir )) > > (default-directory (expand-file-name basedir))) > > (magit-stage-file modfile) > > ;; (magit-status) > > (magit-commit-create) > > ) ) > > > > It works great, I'm very happy. HOWEVER: in my websites I have two kinds > of outputs: > > > > - regular pages -- these get exported to .md files and turned into html > by hugo > > - lecture notes -- these get exported to reveal.js HTML pages by > org-re-reveal and my hugo theme treats them differently . > > > > I would really like to set a switch somewhere in the file, something > like: > > > > #+MWP_EXPORT_TYPE: slides > > > > And then something like > > > > let* ((modfile (if (eq :mwp-export-type "slides") > (mwp-hugo-reveal-custom-export-function) > >(org-hugo-export-wim-to-md))) > > etc) > > do stuff) > > > > > > But I'm not sure how to get access to a totally non-standard option like > the kind I just invented in that last bit of pseudo-code. Anyone have a > good suggestion? > > > > Thank you as always! > > > > Matt > > >
Re: [O] getting access to a self-invented option?
On Fri, Aug 2, 2019 at 4:02 PM Tim Cross wrote: > > Could you just use a tag for this? My shallow thought is that if you > tagged headlines, over time you could use different tags for different > content type whereas if you use a new custom type, you would need to > repeat the definition process (whatever that might be) every time you > discovered a new required type. This would also enable you to benefit > from some of the other nice attributes of tags, such as inheritance. > Googling a bit after reading your answer, I fond #+FILETAGS: which I hadn't noticed before. Since all my lectures are in the same file, I guess I could just add a single line to that file and, as you say, eventually I'd have an extensible and potentially more sustainable system. Thanks to you and everyone else! sorry I too ka while to get back, forgot I wouldn't have Internet while I was away. >
Re: [O] nested plain lists
>>> "DZ" == Diego Zamboni writes: > Hi Uwe, > Yes, this is supported and documented: > https://orgmode.org/manual/Plain-lists.html > For example: > 1. Item 1 > 1. Sub item 1.1 >1. Sub-sub item 1.1.1 > 2. Sub Item 1.2 > 2. Item 2 > 1. Sub item 2.1 Ok. It is not done via changing the enumeration scheme from 1. To 1.1 but increasing the indentation via the meta right/left commands Thanks. Uwe smime.p7s Description: S/MIME cryptographic signature
Re: [O] getting access to a self-invented option?
Matt, See inline. > On Aug 7, 2019, at 8:36 AM, Matt Price wrote > > > On Sat, Aug 3, 2019 at 1:42 PM Berry, Charles wrote: > Matt, > > This seems like a good use case for a `derived-backend'. > > You can use `org-export-define-derived-backend' with 'hugo as the parent, > define a :menu-entry to add an export action for your custom export to the > hugo menu using '?m' (say) as the key. > > Then > > C-c C-e H m > > will export using your custom variant of hugo. > > :-) I'm trying to use the variable to determine whether I export with hugo or > with my hugo-reveal franken-backend: > https://github.com/titaniumbones/ox-huveal . So my preference is to evaluate > the variable BEFORE export begins. But `org-export-as' doesn't execute until the dispatcher has run and the choice of hugo or hugo-reveal has been made. However, if this determination is permanently set for a particular file (you only export in one manner according to the variable and never alter the variable), then see below. > > I guess another option is to just set a buffer-local variable in the file, or > use #+FILETAGS: and hack htings that way. I'm not sure what the most > sustainable & org-like method relaly is... > The obvious choice for a local file setting is an OPTION. Since your 'huveal backend already has an :options-alist, you can just add another option for `:mwp-export-type' there. If you want access to the value before `org-export-as' runs, try something like (plist-get (org-export-get-environment) :mwp-export-type) HTH, Chuck
Re: [O] getting access to a self-invented option?
Correction below. [snip] > >> >> I guess another option is to just set a buffer-local variable in the file, >> or use #+FILETAGS: and hack htings that way. I'm not sure what the most >> sustainable & org-like method relaly is... >> > > The obvious choice for a local file setting is an OPTION. Since your 'huveal > backend already has an :options-alist, you can just add another option for > `:mwp-export-type' there. If you want access to the value before > `org-export-as' runs, try something like > > (plist-get (org-export-get-environment) :mwp-export-type) Rather (plist-get (org-export-get-environment 'huveal) :mwp-export-type) is needed to access your custom options before export is underway. Chuck
