[O] Automatic tangling/detangling
Is there any good way to automatically tangle Org files and detangle tangled files? I frequently use this workflow but they often get out of sync. I have tried adding an after-save-hook but it’s too slow to be useful. Something like auto revert mode might work better... Anyone have solutions for this? -Matthew Bauer
[O] info-js hijacks clicks disallowing integration with other custom click handlers
Hello, I am using infojs_opt while exporting to html from org-mode I find that it “hijacks” all clicks. This is interfering with some custom click handlers I’ve coded up for toggling the display of code listings when clicking on their caption. Does anyone have a suggestion for me to get the best of both worlds? If it helps, below is what I have in my SETUPFILE.org to provide for my desired handling of source code. Thanks ~malcolm_c...@stowers.org #+HTML_HEAD: .org-src-name {text-decoration: underline; font-style: italic; font-family: monospace; border-left: 1em solid Yellow; } #+HTML_HEAD: #+HTML_HEAD: $(document).ready(function() { #+HTML_HEAD: $('.src').hide() // start out with hidden listings (source code) - my clients mostly want RESULTS!!! #+HTML_HEAD: $('.org-src-name').click(function(e){ #+HTML_HEAD// allow to individually toggles src listing by clicking on its #+CAPTION (ASSUMING it has one). #+HTML_HEAD: $(this).next('.src').slideToggle(); #+HTML_HEAD: }); #+HTML_HEAD: $(document).keyup(function(e){ #+HTML_HEAD: switch(e.keyCode){ #+HTML_HEAD: // display/hide ALL source code listings on w/alt-w (chosen to not conflict with +INFOJS_OPT keybindings). #+HTML_HEAD: case 87 : if (e.altKey) {$('.src').slideUp()} else {$('.src').slideDown()} ; break; #+HTML_HEAD: } #+HTML_HEAD: }); #+HTML_HEAD: } ); #+HTML_HEAD:
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
Hello, Daniel P Gomez writes: > I've adapted the code such that it handles both bracketed and > unbracketed links, and links with descriptions. > As it is now, the changes are always automatically applied. Thank you. > I couldn't find a simple way of rewriting links without making them > absolute, as `org-export--prepare-file-contents` does not have access > to the path of the including file, only of the included file. `org-export--prepare-file-contents' is called from the including document, so you can get its path with (buffer-file-name (buffer-base-buffer)). However, we need to handle the case where the including buffer is not associated to a file, i.e., the Sexp above returns nil. > +(goto-char (point-min)) > +(while (re-search-forward org-any-link-re nil t) > + (let ((link (save-excursion > + (backward-char) > + (org-element-context It would be nice to add a comment explaining what we are going to do. > + (when (string= (org-element-property :type link) "file") > + (let* ((has-bracket (string= > +(org-element-property :format link) "bracket")) > + (has-content (org-element-property :contents-begin link)) > + (old-path (org-element-property :path link)) > + (new-path (expand-file-name old-path > + (file-name-directory file))) > + (raw-new-link > + (concat "file:" new-path)) > + (new-link > + (cond > +((and has-bracket (not has-content)) > + (concat "[[" raw-new-link "]]")) > +((and has-bracket has-content) > + (let ((description > +(buffer-substring > + (org-element-property :contents-begin link) > + (org-element-property :contents-end link > + (concat "[[" raw-new-link "][" description "]]"))) > +(t raw-new-link > + (apply #'delete-region (list (org-element-property :begin link) > + (org-element-property :end link))) > + (insert new-link) I suggest the following inner part: (when (string= "file" (org-element-property :type link)) (let* ((old-path (org-element-property :path link)) (new-path (expand-file-name old-path (file-name-directory file (delete-region (org-element-property :begin link) (org-element-property :end link)) (insert (let ((new (org-element-copy link))) (org-element-put-property new :path new-path) (when (org-element-property :contents-begin link) (org-element-adopt-elements new (buffer-substring (org-element-property :contents-begin link) (org-element-property :contents-end link (org-element-interpret-data new) Also, would you mind adding a test in "text-ox.el", within `test-org-export/expand-include'? Regards, -- Nicolas Goaziou
Re: [O] Feature suggestion and code review request: org-babel-cycle-src-block-header
This is a neat idea. I sometimes want to switch to silent, or between value and results. I don't know if you would consider the code below an improvement, but it seems to do what you want, and is shorter. It has less checking of things, and is more of a replace the header kind of approach. Personally, I think strings are the way to go here. #+BEGIN_SRC emacs-lisp :tangle yes :results none (require 's) (require 'dash) (defvar header-sequences '((emacs-lisp . (":tangle no :results none";; type 2 above ":tangle yes :results none" ;; type 3 above ":results type verbatim" ;; type 1 above (defun obch () (interactive) (let* ((lang (car (org-babel-get-src-block-info t))) (headers (cdr (assoc (intern-soft lang) header-sequences))) header index) (save-excursion (org-babel-goto-src-block-head) (re-search-forward lang) (setq header (buffer-substring-no-properties (point) (line-end-position)) index (-find-index (lambda (s) (string= (s-trim s) (s-trim header))) headers)) (delete-region (point) (line-end-position)) (insert " " (if index (nth (mod (+ 1 index) (length headers)) headers) (car headers)) #+END_SRC John --- 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 On Wed, Feb 28, 2018 at 2:59 AM, Akater wrote: > When I have a chance, I enjoy the following development workflow: the > code is written in org files and is tangled into conventional source > code files more or less regularly. > > I find that source blocks mostly fall into three categories, numbered > here for further reference: > - examples/test cases/desiderata, like > `(my-implemented-or-desired-function x y)' (type 1) > - drafts, failed attempts at implementations and other snippets better > left as is, or as a warning (type 2) > - working implementations, to be tangled (type 3) > > Hence I end up using only a handful of header argument strings. An > example corresponding to this 3-cases setup is found below. So it would > be nice to have a function that cycles between those, much like we can > cycle through org TODO sequence now using a standard function, and set > up this sequence per Org file. > > I'm fairly bad at Emacs Lisp, so I'm interested in feedback about my > implementation of cycling function. It operates with strings, mostly > because I failed to make it work with lists of alists of header > arguments as ob-core.el suggests. On the other hand, given that Emacs > Lisp is more string-oriented than it is object-oriented, it might not be > a really bad idea. > > So what do you think? How can this implementation be improved? (Sans > using rotate and tracking position in a smarter way.) Does it make sense > to include this feature in Org mode? Maybe I missed some existing > well-estabilished solutions? This is something akin to “literate > programming”; I'm not a fan of this idea---at least the way it is > usually presented---but it is somewhat popular a topic. I have some > other feature in mind I'd love to see implemented in Org-Babel: > convenient export of src blocks of type 1 (see above) into unit tests > (as test cases) and into documentation sources (as examples) but this > one is heavily target-language dependent and probably deserves its own > thread. > > #+begin_src emacs-lisp > (cl-defun next-maybe-cycled (elem list &key (test #'equal)) > "Returns the element in `list' next to the first `elem' found. If `elem' > is found at `list''s very tail, returns `list''s car. `next-maybe-cycled' > provides no way to distinguish between \"found nil\" and \"found nothing\"." > (let ((sublist (cl-member elem list :test test))) > (and sublist > (if (cdr sublist) > (cadr sublist) >(car list) > > (defun shrink-whitespace (string) > "Transforms all whitespace instances into single spaces. Trims > whitespace at beginning and end. No argument type checking." > (cl-reduce (lambda (string rule) >(replace-regexp-in-string (car rule) (cdr rule) string)) > '(("[[:blank:]]+" . " ") ("^[[:blank:]]*" . "") > ("[[:blank:]]*$" . "")) > :initial-value string)) > > (defun string-equal-modulo-whitespace (x y) > (string-equal (shrink-whitespace x) (shrink-whitespace y))) > > (defun org-babel-cycle-src-block-header-string (header-strings) > "Cycle through given `header-strings' if currently in Org Babel source > code block. If current src-block header is not found in `header-strings', > switch header to the car of `header-strings'. > > `header-strings' must be a non-empty list of strings. All whitespace in > them is shrinked. > > If UNDO-ed, cursor position is not guaranteed to be preserved." > (interactive) > (cond >((not (and header-strings (listp header-strings))) > (error "No Org Babel header strings list
Re: [O] what settings would make original export to pdf as good as pandoc conversion?
I have also found that exporting to a .texi file (using ox-texinfo) and then using texi2pdf to generate a PDF produces, out of the box, a nicer-looking (IMO) document than the native LaTeX export. —Diego > On 2 Mar 2018, at 19:53, Samuel Wales wrote: > > On 3/2/18, Eric S Fraga wrote: >> Why can you not use any LaTeX settings? Org has very extensive support >> for allowing tweaking of the formatting. > > delighted to learn of settings. >
Re: [O] Orgmode in Madrid
I won't be in Madrid, but would still be interested to hear (especially) Bastien's remarks about the French government's use of free software. Could you let us know if slides and/or a recording are posted? Thanks - Neil On 1 March 2018 11:49:47 GMT+00:00, David Arroyo Menendez wrote: > >Hi emacsers, > >Bastien Guerry will be in Medialab this weekend if you are in Madrid, >you can enjoy about orgmode and emacs speech. > >All info in >https://www.medialab-prado.es/actividades/dia-de-los-datos-abiertos > >I'm creating an event in meetup to this event >https://www.meetup.com/es-ES/EmacsMadrid/ > >Regards.
[O] Typo org-switchb org-iswitchb
Newest ... The manual and the guide talk about "org-iswitchb", the code contains only "org-switchb". Thanks
[O] Bug: org-gnus-store-link wrong if used from article buffer when point moved in summary [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.3/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 http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Hi, If you open an article in Gnus, then move the point away from the summary line of that article in the Summary buffer, then go back to the Article buffer and M-x org-store-link, it will link to the article you're pointing at in the Summary, not the article in the Article buffer. The issue is at line 145 in https://code.orgmode.org/bzg/org-mode/raw/master/lisp/org-gnus.el which does (header (with-current-buffer gnus-summary-buffer (gnus-summary-article-header))) (I'm running 8.2.10 normally, but I've tried the most recent org-gnus.el and it's the same, and the code makes it clear why.) In my own code I use the following workaround: (if (eq major-mode 'gnus-article-mode) (save-window-excursion (gnus-article-show-summary) (org-store-link nil)) (org-store-link nil)) although someone with knowledge of gnus internals might be able to avoid the call to (gnus-configure-windows 'article) that changes the window configuration. (Or maybe org-mode should simply use the above workaround since that assumes less about gnus internals, which might change more than its public API.) best regards, Kevin Brubeck Unhammer Emacs : GNU Emacs 25.3.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-12 Package: Org-mode version 8.2.10 (release_8.2.10 @ /usr/share/emacs/25.3/lisp/org/)
[O] Typo in the compact Org Mode Guide
Hello, I'm not completely sure if this mailing list is the appropriate place to put it, but it was the e-mail address listed under section 1.4 (Feedback) of the compact Org mode Guide. I have encountered a typo. It's on page 10 of the PDF of the latest release (9.1.7). The sentence in question is: > Org mode providing methods to give you an overview of all the things that you > have to do, collected > from many files. The corrected version should appear as follows: > Org mode *provides* methods to give... Please let me know if it's an legitimate grammatical error. Ben Siraphob
Re: [O] what settings would make original export to pdf as good as pandoc conversion?
On 3/2/18, Eric S Fraga wrote: > Why can you not use any LaTeX settings? Org has very extensive support > for allowing tweaking of the formatting. delighted to learn of settings.
[O] (no subject)
Dear Eric, Just a quick email to tell you that I have just succeeded to configure gnus-alias [[https://www.emacswiki.org/emacs/GnusAlias]] rather correctly mainly thanksto Fabrice Niessen [[https://github.com/fniessen/emacs-leuven/blob/master/gnus-leuven.el]] (many thanks Fabrice !) and thanks to other related web pages. I still do not succeed to use correctly regular expressions for gnus-alias-identity-rules but, anyway, at the moment it works correctly for me. It is a very good tool. Best wishes, Jo
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
I've adapted the code such that it handles both bracketed and unbracketed links, and links with descriptions. As it is now, the changes are always automatically applied. > Also, rewriting needs not be always absolute path, if both directories > share a common root. I couldn't find a simple way of rewriting links without making them absolute, as `org-export--prepare-file-contents` does not have access to the path of the including file, only of the included file. On Thu, Mar 1, 2018 at 11:42 PM, Nicolas Goaziou wrote: > Hello, > > Daniel P Gomez writes: > >> Currently when passing the :absolute-paths toggle to an include >> derivative, as in : >> >> #+INCLUDE: file.org :absolute-paths t >> >> The function `org-export--prepare-file-contents` will automatically >> deduce the directory from file.org and adapt links by calling: >> `(new-path (expand-file-name old-path (file-name-directory file)))`. >> I could either make this a default option, such that links get >> corrected but users can overwrite this by calling `:absolute-paths >> nil`, or I could completely remove this toggle and always correct >> links no matter what. > > I am wondering about the latter. If there is no reason to keep broken > file names, it makes sense to automatically apply it. > > Also, rewriting needs not be always absolute path, if both directories > share a common root. > >> One question regarding the implementation, currently I'm deleting the >> link with a call to `delete-region` and using `(insert "[[file:" >> new-path "]]")` to insert the corrected one. This does not take into >> consideration whether links are bracketed or not ( is there a >> functional difference if links are not bracketed?). > > Yes. White spaces are handled differently in each link type. > >> Also, my approach completely disregards link descriptions, which may >> be relevant if the linked file would be, for example, an html >> document. Would there be a cleaner org approach to replace the path >> keeping the description? > > You could check :contents-begin and :contents-end for the link. If they > are not nil, extract this region, and insert it again in the new link. > > Regards, > > -- > Nicolas Goaziou0x80A93738 0001-Fix-file-links-when-using-INCLUDE.patch Description: Binary data
Re: [O] Bug: [ob-clojure] Surprising evaluation result [9.1.6 (release_9.1.6-491-g70b029 @ /Users/xcy/src/org-mode/lisp/)]
No, it's not expected result. It should be caused by my commit here https://code.orgmode.org/bzg/org-mode/pulls/5 Don't know how to workaround this. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Thu, Mar 1, 2018 at 11:50 PM, Xu Chunyang wrote: > Hello all, > > I run the following Clojure code with CIDER as the backend. The result > is surprising to me: > > #+begin_src clojure > (* 6 7) > (= nil ()) > #+end_src > > #+RESULTS: > : 42false > > As you can see, the result is the concatenation of the value of each > expression. Is it expected? I would like to get only the value of the > last expression, i.e., false. > > > -- > Org release_9.1.7-440-g5e8fa1361 > CIDER v0.16.0-83-g88f4fcf > Emacs 27.0.50 > >
Re: [O] wish: facility to wash org link descriptions
https://orgmode.org/manual/Adding-hyperlink-types.html#Adding-hyperlink-types Adding a custom hyperlink type (or overriding the existing one for mail messages) seems like your best bet. Jack > On Mar 2, 2018, at 07:16, Gregor Zattler wrote: > > Hi org-mode developers, > > it would be nice if there was a facility to wash (= shorten) org > link descriptions. From the users perspective this could be a > list of regular expressions with corresponding short forms. > > Use case: > > I want to automatically shorten org link descriptions, > especially if linking to emails. Some of this emails are from a > request tracker and have extraordinary long From: and Subject: > suffixes which add up to 49 characters in the link description. > I would like to radically shorten this boilerplate. > > Even with "normal" To: and Subject:, the default formatting of > such links prefixes the correspondents name with "from " or "to ". > While it's fine with me to distinguish emails from me from > emails to emails to me, I would not need the "from "). > > > Ciao; Gregor > -- > -... --- .-. . -.. ..--.. ...-.- > >
[O] wish: facility to wash org link descriptions
Hi org-mode developers, it would be nice if there was a facility to wash (= shorten) org link descriptions. From the users perspective this could be a list of regular expressions with corresponding short forms. Use case: I want to automatically shorten org link descriptions, especially if linking to emails. Some of this emails are from a request tracker and have extraordinary long From: and Subject: suffixes which add up to 49 characters in the link description. I would like to radically shorten this boilerplate. Even with "normal" To: and Subject:, the default formatting of such links prefixes the correspondents name with "from " or "to ". While it's fine with me to distinguish emails from me from emails to emails to me, I would not need the "from "). Ciao; Gregor -- -... --- .-. . -.. ..--.. ...-.-