Re: [RFC] Document level property drawer
Marco Wahl writes: > Sebastian Miele writes: > >> But for such properties to satisfactorily work for me, they would have >> to be visible by default. E.g. I would want the header-args to be >> immediately visible just like they are when they are written after >> #+BEGIN_SRC or #+HEADER. Otherwise I would find myself constantly >> wondering whether this or that property drawer contains something >> essential and every TAB on a collapsed headline would have be followed >> by an accompanying move to the property drawer and a TAB there. >> >> On the other hand, there are properties that are very good candidates >> for remaining hidden by default, like ID. >> >> I would like to be able to make a clear distinction between properties >> that are visible by default and properties that are not. Maybe it would >> be possible to allow some #+.. syntax following headings for subtree >> properties that are visible by default. A requirement could be made that >> such property specifications always have to be followed by a property >> drawer, even if that is empty. Then everything #+.. that is before the >> property drawer would belong to the heading/subtree, and everything #+.. >> that follows the drawer would be treated as it is until now. >> >> Please tell me if I missed something and Org is already capable of >> something like that. If not, are there others who would like >> visible-by-default property specifications for headings/subtrees in >> addition to invisible-by-default property specifications in drawers, >> too? > > I don't think Org is capable of this out of the box right now. Further > I don't feel the need for a visible-by-default property, but that's just > me. After a few more months of living without that feature I must say that I basically live perfectly well without that, too. I just do not define source block header args in property drawers. It gets a bit verbose at times. But not to the degree of being painful. >> Finally, I would like to state an opinion: If there is >> visible-by-default (by #+..) and invisible-by-default (by drawers) >> syntax for headings/subtrees, including level 0, it may be viable to >> require them to be disjoint for each heading/subtree. Most probably it >> would be good practice, anyway. And the precedence question raised >> previously in this thread would be eliminated. > > I may not feel the need for the visible/invisible-by-default properties > but actually I like the idea of #+ properties parallel to the property > drawers as visible by default properties. But since the #+ properties > may appear anywhere in the Org file and affect the whole file it would > be difficult or even impossible to give them reliable meaning for > subtrees AFAICS. In the meantime I had a look into worg/dev/org-syntax.org. From the document: "Property drawers are a special type of drawer containing properties attached to a headline. They are located right after a headline and its planning information." So, currently, #+ properties may not appear between a heading and a property drawer. At least not without turning the property drawer into a non-special drawer. So, in principle, it would be possible to change the syntax of Org to allow #+ properties between headings and (possibly empty) property drawers in order to denote visible-by-default properties attached to a heading. Moreover, this change probably would introduce very little to no backwards incompatibility. With the change it would not be possible to turn property drawers into non-special drawers by putting a #+ property before them. Now it is possible to sort of uncomment property drawers by putting #+ properties before them. This "feature" probably is hardly used, if at all.
RE: attachment: link type export to HTML invalid attach dir
Hi, > -Original Message- > From: stardiviner > Sent: den 15 januari 2020 06:53 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: attachment: link type export to HTML invalid attach dir > > [...] > > I checked out the latest commit "0ac6a9e1f", The ~~ tag is solved. > But the ~(org-attach-dir)~ still not work. The exported ~~ > inline image still does not contains the attach directory. Ah yes. Found the culprit for this issue. Hopefully the last one. The exporter doesn't actually move the point in the buffer during the export. So org-attach-expand tried to expand from the first character in the buffer. This should be fixed from a few minutes ago. Crossing fingers for this to work properly now! Regards Gustav
Re: export and split orgmode headers into separate md files?
Thx Deigo for the detailed answer! Really appreciate it! i think though it’s a bit over my head as i have limited lisp knowledge :) Does this export to standard markdown files or leanpub format? Honestly at this stage im willing to export to any flavor of markdown but basic or MMD would work best. Any tips on how i can adjust the code for that? if not can i just run your code to get a different markdown format? What the main function you run after evaluating the code in emacs? i apologize in advance for the silly questions :) thx again Z On Sun, Jan 12, 2020 at 7:20 AM Diego Zamboni wrote: > Hi Z, > > I do something similar in my ox-leanpub-book module [1], which exports > each top-level heading to a different file. The general idea is to use > =org-map-entries= to loop over the entire buffer [2]. The function you call > can then check whether the current entry is a header at the level you want > [3] and then export it to the corresponding file. The title can be used to > deduct the filename [4]. > > I found that I had to mark the entire subtree before calling the export > function [5], otherwise the headline was not getting included in the export. > > I based my code originally on this blog post, which might be a simpler > starting point: > https://medium.com/@lakshminp/publishing-a-book-using-org-mode-9e817a56d144 > - this code does not select the entire subtree before exporting, which > means only the contents of the section is exported, but not the headline > itself. > > Hope this helps! > --Diego > > [1] https://github.com/zzamboni/ox-leanpub/tree/book-and-markua > [2] > https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-book.el#L185-L186 > [3] > https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-book.el#L125 > [4] > https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-book.el#L131-L135 > [5] > https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-book.el#L170-L174 > > > On Sun, Jan 12, 2020 at 4:54 AM Xebar Saram wrote: > >> Hi all >> >> For work specific needs at uni i have a need to take a comprehensive org >> file with hundreds of headers and split each header into separate .md files >> (with the header name as file name//first header in the md file). >> Has anyone done anything remotely similar? Or if not can someone point >> me in the right direction on how to even start dealing with this? >> >> thx a lot in advance any tips would be very much appreciated >> >> kind regards >> >> Z >> >
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: stardiviner > Sent: den 15 januari 2020 07:21 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > [...] > > >> I found when I set option ~(setq org-attach-store-link-p t)~. Then > >> attach a file, store file link with =[C-c C-l]=. The stored link. I > >> open this link got error "No such file: ". I tested this with > >> minimal Emacs config. confirmed this problem. > >> > > > > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) and > with only that single customization it works for me. I'm testing it in > linux. A wild guess.. Could it be that you used the move operation instead > of the copy operation when attaching the file? > > > > Regards > > Gustav > > Did you reproduce this issue with =emacs -q= ? That is a built-in Org Mode > version which does not contains the latest version =org-attach.el=. > > Here is my minimal Emacs config: > > [...] > > ;; > == > ;;; Here is org-attach.el customization > > (require 'org-attach) > > ;; store link auto with `org-store-link' using `file:' link type or > `attachment:' link type. > (setq org-attach-store-link-p 'attached) (setq org-attach-dir-relative t) > (setq org-attach-preferred-new-method 'ask) #+end_src > > #+begin_src sh :eval no > emacs -q -l '~/.config/emacs/minimal-init.el' > #+end_src Hmm, in the first mail you said that you set org-attach-store-link-p to t, but in your config it says 'attached. I've tried with a minimal config as well (using emacs -q because I build the newest org mode version into the emacs folder) and can only reproduce your issue when using the attached option for org-attach-store-link-p and then inserting that link with C-c C-l /in another heading/. Pasting the link in another heading is expected to break since the attachment link is context dependent (i.e. requires an attachment folder). Makes sense? If I'm still misunderstanding your use-case, would you care to describe the steps to reproduce it more in detail? Regards Gustav
