Re: attachment: link type export to HTML invalid attach dir
Gustav Wikström writes: > Hi! > > Thanks for reporting this! > > The code is updated on the master branch to make the exporters aware of how > to deal with attachment links. Commit d70db54db for the curious. Basically, > attachment links are expanded into file-links by the exporters now, before > further processing into links in the respective markup language. > > Regards > Gustav Many thanks for really quick patching. I tested out the new patch, still does not work. #+begin_src org ,** Strings are not Lists, but Anyway… :PROPERTIES: :ID: 2fd354f3-ac7a-499d-9fe4-a76626bbdb38 :END: In Calva Paredit, strings are treated in much the same way as lists are. Here’s an example showing Slurp and Barf, Forward/Backward List, and Grow Selection. [[attachment:string-as-list.gif]] #+end_src The upper org content is exported as this (HTML page): #+begin_example Strings are not Lists, but Anyway… In Calva Paredit, strings are treated in much the same way as lists are. Here’s an example showing Slurp and Barf, Forward/Backward List, and Grow Selection. file:///home/stardiviner/Org/Wiki/Computer Technology/Programming/Emacs/Data/Emacs Packages/string-as-list.gif #+end_example You can see: 1. the link still does not contains the attach directory from ~(org-attach-dir)~. 2. image links are not exported as inline image displayed with ~~. -- [ 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! Thanks for reporting this! The code is updated on the master branch to make the exporters aware of how to deal with attachment links. Commit d70db54db for the curious. Basically, attachment links are expanded into file-links by the exporters now, before further processing into links in the respective markup language. Regards Gustav From: Emacs-orgmode on behalf of stardiviner Sent: Monday, January 13, 2020 13:24 To: emacs-orgmode@gnu.org Subject: Re: attachment: link type export to HTML invalid attach dir When I export with =[C-c C-e h o]=, I found attached inline image links are not displayed in HTML page. Here is Org content: #+begin_src org ,** Strings are not Lists, but Anyway… :PROPERTIES: :ID: 2fd354f3-ac7a-499d-9fe4-a76626bbdb38 :END: In Calva Paredit, strings are treated in much the same way as lists are. Here’s an example showing Slurp and Barf, Forward/Backward List, and Grow Selection. [[attachment:string-as-list.gif]] #+end_src The email attachment contains the screenshot of HTML page. I used Edebug on functions, track down to the error function ~(org-attach-dir)~, it returns ~nil~ when in exporting to HTML, but when I evaluate ~(org-attach-dir)~ interactively under the headline, it works correctly. -- [ 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: [RFC] Document level property drawer
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. > 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. My 2ct, -- Marco
Re: [O] Orgmode Latex Export with Babel/LilyPond
Hello
On 12 Jan 2020, adam wrote:
> On Sun, 2020-01-12 at 10:43 +1300, adam wrote:
>> On Sun, 2020-01-12 at 09:04 +1300, adam wrote:
>> >
>> > On Sat, 2020-01-11 at 12:30 -0300, Jonathan Gregory wrote:
>> > >
>> > >
>> > >
>> > > On 11 Jan 2020, adam wrote:
>> > >
>> > > >
>> > > >
>> > > >
>> > > > Still no success in tangling the examples modal-cycle.org
>> > > > modal-cycle2.org
>> > > > shown here,
>> > > > https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
>> > > >
>> > > >
>> > > > My current problem is Emacs rejecting the addition of either Lilypond
>> > > > or
>> > > > lilypond, in the org-babel-do-load-languages
>> > > >
>> > > >(org-babel-do-load-languages
>> > > > 'org-babel-load-languages
>> > > > '(
>> > > >(emacs-lisp . t)
>> > > >(shell . t)
>> > > >(org . t)
>> > > >(Lilypond . t)
>> > > >))
>> > > >
>> > > > including either in the last line causes an error at Emacs startup,
>> > > > reported as,
>> > > >
>> > > >Warning (initialization): An error occurred while loading
>> > > > ‘/home/user/.emacs’:
>> > > >Symbol's value as variable is void: > > > >
>> > > >
>> > > > Earlier in my .emacs init file, I had hopefully defined lilypond, thus
>> > > >
>> > > >(setq ly-nix-ly-path "lilypond")
>> > > >
>> > > >(add-to-list 'load-path "/usr/share/emacs/site-lisp/")
>> > > >
>> > > >(autoload 'LilyPond-mode "lilypond-mode")
>> > > >
>> > > >(setq auto-mode-alist
>> > > > (cons '("\\.ly$" . LilyPond-mode) auto-mode-alist))
>> > > >
>> > > >(add-hook 'LilyPond-mode-hook (lambda () (turn-on-font-lock)))
>> > > >
>> > > >
>> > > > In /usr/share/emacs/site-lisp/ many lilypond related .el files
>> > > > are located,
>> > > >
>> > > >lilypond-font-lock.el
>> > > >lilypond-indent.el
>> > > >lilypond-init.el
>> > > >lilypond-mode.el
>> > > >lilypond-song.el
>> > > >lilypond-what-beat.el
>> > > >lilypond-words.el
>> > > >ltx-help.el
>> > > >ob-lilypond.el
>> > > >ob-Lilypond.el
>> > > >ob-lisp.el
>> > > >org-tests.el
>> > > >
>> > > >
>> > > > $ which lilypond is unhelpful,
>> > > >
>> > > >/usr/bin/lilypond
>> > > >
>> > > >
>> > > > The lilypond installation is at,
>> > > >
>> > > >/usr/share/lilypond/2.18.2/
>> > > >
>> > > >
>> > > > Any advice or suggestions would be most welcome.
>> > > Version 9.1.9 comes with ob-lilypond.el. There's no ob-babel-lilypond.el
>> > > AFAIK.
>> > > Also,
>> > > where is ly-nix-ly-path and other ly-* variables defined? I don't see
>> > > these
>> > > variables.
>> > >
>> > Thank you. I'll look inside ob-lilypond.el for clues, variables to be
>> > defined.
>> >
>> >
>> > Org-mode version 9.1.9 (release_9.1.9-65 ...) @
>> > /usr/share/emacs/26.3/lisp/org
>> > on Ubuntu 18.04
>> >
>> > $ find / -name "ob*.el" locates only the ob-lilypond.el I downloaded
>> > from github
>> >
>> >
>> > Maybe I need a (require 'lilypond) somewhere, I was thinking.
>> >
>> >
>> > Its a new system here. Emacs was installed with Ubuntu's software manager,
>> > lilypond
>> > was installed with $ sudo apt install lilypond Neither were built from
>> > source.
>> >
>>
>> OK, my bad. When I look inside ob-lilypond.el I find I pulled a page of
>> markup
>> stuff.
>> Will grab a proper ob-lilypond.elThat will improve matters.
>
>
> Improvement with correct ob-lilypond.el Now the
> (org-babel-do-load-languages ..)
> doesn't cause Emacs to report error at Emacs start-up.
>
> Presently, with examples modal-cycle.org modal-cycle-2.org
> modes-in-key-of-C.org
> I can C-c C-e l p export to PDF, but there's no music symbols.
>
> Also I have no M-x ly-* commands available.
>
> Org Customize Option, babel, lilypond, for org-babel-lilypond-commands is
> set to nil
That page was published 9 years ago by Martyn Jago. Some of the code in it no
longer works with recent versions of Org and LilyPond. Also, the source files
used in the examples reside in the author's github page (not editable in worg),
so if you want to try them out you may have to make the adjustments yourself
prior to running the code. In any case, I pushed a few edits which I think
makes the tutorial easier to follow.
--
Jonathan
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. -- [ 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
When I export with =[C-c C-e h o]=, I found attached inline image links are not displayed in HTML page. Here is Org content: #+begin_src org ,** Strings are not Lists, but Anyway… :PROPERTIES: :ID: 2fd354f3-ac7a-499d-9fe4-a76626bbdb38 :END: In Calva Paredit, strings are treated in much the same way as lists are. Here’s an example showing Slurp and Barf, Forward/Backward List, and Grow Selection. [[attachment:string-as-list.gif]] #+end_src The email attachment contains the screenshot of HTML page. I used Edebug on functions, track down to the error function ~(org-attach-dir)~, it returns ~nil~ when in exporting to HTML, but when I evaluate ~(org-attach-dir)~ interactively under the headline, it works correctly. -- [ 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
