[O] Automatic tangling/detangling

[Matthew Bauer]

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

[Cook, Malcolm]

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?

[Nicolas Goaziou]

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

[John Kitchin]

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  (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 

Re: [O] what settings would make original export to pdf as good as pandoc conversion?

[Diego Zamboni]

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

[Neil Jerram]

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

[Th. Rikl]

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/)]

[Kevin Brubeck Unhammer]

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

[siraben]

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?

[Samuel Wales]

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)

[Joseph Vidal-Rosset]

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?

[Daniel P Gomez]

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/)]

[numbch...@gmail.com]

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

[Jack Henahan]

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

[Gregor Zattler]

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
-- 
 -... --- .-. . -.. ..--.. ...-.-