Re: Empty headline titles unsupported: Bug?

2021-05-25 Thread Sebastian Miele
Sebastian Miele  writes:
>David Masterson  writes:
>> Sebastian Miele  writes:
>>> Currently org-syntax.org says that "TITLE can be made of any
>>> character but a new line.  Though, it will match after every other
>>> part have been matched."  This does not reflect the currently
>>> effective behavior that "* :t:" is a headline with title ":t:" and no
>>> tags.
>>
>> Can you describe what should happen in a parser grammar (ie. BNF)?  If
>> not, I would tend toward rethinking the structure of the Org file so
>> that it can be described in a grammar.  Having a good grammar for Org
>> files will promote it's acceptance beyond Emacs.
>
> [...]  However, the way I understand the above quote from
> org-syntax.org (which is, I think, in the end preferable) [...]

To be clearer: Preferable to the way it currently is implemented.

In the headline "* :t:", the above quote from org-syntax.org (at least
in my way of reading it) means TAGS ":t:" (which is an "other part [to
be] matched [before the TITLE]") and TITLE "" (which is matched "after
every other part").

But the way Org currently is implemented is different in such cases (no
TAGS, the ":t:" is the TITLE).



Re: Empty headline titles unsupported: Bug?

2021-05-25 Thread Sebastian Miele
Hi David and all,

David Masterson  writes:
> Sebastian Miele  writes:
>> Currently org-syntax.org says that "TITLE can be made of any
>> character but a new line.  Though, it will match after every other
>> part have been matched."  This does not reflect the currently
>> effective behavior that "* :t:" is a headline with title ":t:" and no
>> tags.
>
> Can you describe what should happen in a parser grammar (ie. BNF)?  If
> not, I would tend toward rethinking the structure of the Org file so
> that it can be described in a grammar.  Having a good grammar for Org
> files will promote it's acceptance beyond Emacs.

I do not know whether it can be expressed in a context-free grammar,
although it may very well be possible.  However, the way I understand
the above quote from org-syntax.org (which is, I think, in the end
preferable) is concisely expressible in a regular expression language
that can distinguish between greedy and non-greedy matching of
subexpressions, including Emacs Lisp's regular expressions:

#+BEGIN_SRC elisp
(rx line-start
(maximal-match STARS SPACE)
(maximal-match (optional KEYWORD SPACE))
(maximal-match (optional PRIORITY SPACE))
(maximal-match (optional COMMENT SPACE))
(minimal-match (optional TITLE SPACE))
(maximal-match (optional TAGS))
(maximal-match (optional SPACE))
line-end)
#+END_SRC

SPACE is (1+ (any " \t")).  TITLE is (1+ not-newline).  In the
following, I concentrate on differences from org-syntax.org.

The above expression contains COMMENT (matching "COMMENT") not as part
of the title but as separate entity.  Although this is contrary to
org-syntax.org, it is how it is implemented now, e.g., in
org-element-headline-parser.

TAGS currently effectively is (seq ":" (1+ TAG ":")).  In particular,
that means a TAGS specification in a headline must define at least one
tag.

I suggest to change that into (seq ":" (0+ TAG ":")), i.e., to also
allow TAGS specifications of zero tags (just ":").  This would enable to
clearly disambuate the following ambiguity between TITLEs and TAGS:

#+BEGIN_SRC org
,* :t:
,* :t: :
#+END_SRC

The former headline would have empty TITLE and TAGS ":t:".  The latter
headline would have TITLE ":t:" and TAGS ":".

The following toy can be used to test some cases.  It is not complete,
but contains the essential.

#+BEGIN_SRC elisp
(defun f (x)
  (let ((r (rx line-start
   (maximal-match (group (1+ "*")) (1+ (any " \t")))
   (maximal-match (group (optional "TODO" (1+ (any " \t")
   (minimal-match (optional (group (1+ not-newline)) (1+ (any " 
\t"
   (maximal-match (group (optional (seq ":" (0+ (any "a-z") ":")
   (maximal-match (optional (1+ (any " \t"
   line-end)))
(when (let (case-fold-search) (string-match r x))
  (list :stars (match-string 1 x)
:todo  (match-string 2 x)
:title (let ((title (match-string 3 x))) (if title title ""))
:tags  (match-string 4 x)

(f "*** :t:  :  ") ;(:stars "***" :todo "" :title ":t:" :tags ":")
(f "***:t:  ") ;(:stars "***" :todo "" :title "":tags ":t:")
#+END_SRC

Best wishes
Sebastian



Re: Empty headline titles unsupported: Bug?

2021-05-24 Thread Sebastian Miele
Ihor Radchenko  writes:
> Either way is fine while it is consistent. I just tried to test some
> edge cases with existing org-element code:
>
> * TODO COMMENT :tag:
>
> org-element-at-point returns :raw-value "".
>
> * TODO :tag:
>
> :raw-value ":tag:"

Concerning tags, it is the expected behavior according to
org-syntax.org: "If the first word appearing in the title is “COMMENT”,
the headline will be considered as “commented”."  So the headline

  * TODO COMMENT :tag:

is a headline with title "COMMENT" and tag "tag".  The headline is not
empty.

However, according to org-element-api.org, the :raw-value should be
"COMMENT".

But this raises another question: In my opinion the apparently effective
behavior of org-element (make the headline :commentedp, but do not
actually include "COMMENT" in the title) is preferable.  So I would
prefer to change the spec (org-syntax.org) to reflect that.



Re: Empty headline titles unsupported: Bug?

2021-05-24 Thread Sebastian Miele


Sebastian Miele  writes:
> #+BEGIN_EXAMPLE
> ,* A
> ,* :B:
> ,* C
> #+END_EXAMPLE
>
> org-element-parse-buffer and org-match-sparse-tree make the second
> headline have title ":B:" and no tags.

Currently org-syntax.org says that "TITLE can be made of any character
but a new line.  Though, it will match after every other part have been
matched."  This does not reflect the currently effective behavior that
"* :t:" is a headline with title ":t:" and no tags.



Re: Empty headline titles unsupported: Bug?

2021-05-24 Thread Sebastian Miele
Nicolas Goaziou  writes:
> You cannot distinguish the following two cases:
>
>   * :mytag:
>   * :myheadline:

In my opinion, the cleanest solution would be to allow not only tags
specifications of one or more tags, but also the tags specification ":"
of zero tags in the headline.  Then in

  * :t:
  * :t: :

the former would be a headline with empty title and tag "t", and the
latter would be a headline with title ":t:" and not tags.



Empty headline titles unsupported: Bug?

2021-05-22 Thread Sebastian Miele
Hello,

worg/dev/org-syntax.org is not clear about whether the title of a
headline is allowed to be empty.  I occasionally (would like to) use
headlines with empty titles, e.g., when a tag in some headline already
provides all necessary information, and an additional title would
duplicate that.

Are empty headline titles meant to be supported?  If yes, then there are
at least two bugs.  On

#+BEGIN_EXAMPLE
,* A
,* :B:
,* C
#+END_EXAMPLE

org-element-parse-buffer and org-match-sparse-tree make the second
headline have title ":B:" and no tags.

Best wishes
Sebastian



Bug: ("bash" . sh) in default value of org-src-lang-modes

2021-03-27 Thread Sebastian Miele
Hello!

The default value of org-src-lang-modes contains ("bash" . sh), meaning
that for bash src blocks sh-mode gets used.

sh-mode supports many different languages (bash, zsh, dash, ...).
Often, when opening a file for which sh-mode gets activated, there is
enough information for sh-mode to determine the language that actually
is used in the file, e.g., by a shebang, or by the suffix of the
filename.

However, that usually does not work with Org src blocks.  When sh-mode
has no clues, it in effect always uses the language determined by the
SHELL environment variable (at least on POSIX-conformant systems).  If
that is not something like /bin/bash then sh-mode is not a bash mode.
E.g., with SHELL=/bin/zsh opening an edit buffer for

#+BEGIN_SRC bash
#+END_SRC

yields a buffer with the buffer-local variable sh-shell set to zsh
instead of bash, i.e., sh-shell is a zsh mode.

This can be fixed by defining something like

(defun org-babel-bash-mode ()
  (sh-mode)
  (sh-set-shell "bash"))

and having ("bash" . org-babel-bash) in the default value of
org-src-lang-mode.

Best wishes
Sebastian



Re: Bug: Fontificaton and hiding inside code and verbatim markup

2021-03-23 Thread Sebastian Miele
Sebastian Miele  writes:

> according to both, org-element-parse-buffer and
> worg/dev/org-syntax.org,
>
>   ~file:aa~
>   ~a *a* a~
>   =a /a/ a=
>
> does not have link, bold or emphasize objects inside the code or
> verbatim objects.  However, the fontification of Org makes it look like
> that.  Also, the emphasis markers inside code or verbatim objects are
> hidden, when org-hide-emphasis-markers is t.

I am using Org from the current master in Emacs 27.1.



Bug: Fontificaton and hiding inside code and verbatim markup

2021-03-23 Thread Sebastian Miele
Hello!

according to both, org-element-parse-buffer and
worg/dev/org-syntax.org,

  ~file:aa~
  ~a *a* a~
  =a /a/ a=

does not have link, bold or emphasize objects inside the code or
verbatim objects.  However, the fontification of Org makes it look like
that.  Also, the emphasis markers inside code or verbatim objects are
hidden, when org-hide-emphasis-markers is t.

Best wishes
Sebastian



Re: noweb syntax clashing with shell here document syntax

2021-03-23 Thread Sebastian Miele
Hi Immanuel,

Immanuel Litzroth  writes:

> You can choose which delimiters signal noweb.
> see the documentation of org-babel-noweb-wrap-start and
> org-babel-noweb-wrap-end.

Thank you!  That indeed should make my problem solvable in a perfect
way.

Best wishes
Sebastian



noweb syntax clashing with shell here document syntax

2021-03-22 Thread Sebastian Miele
Hello!

The noweb syntax seems to clash with the syntax of here documents in
shell scripts.  In the block like

#+BEGIN_SRC shell :noweb yes
  echo a
  <>
  echo b
#+END_SRC

everything following the line with the the noweb reference does not
get fontified properly.  I suspect that the problem already is known
for a long time.  Is that true?  If yes, what is the status of this
issue?  Is there a known workaround?

At least in ZSH it may very well be the case that a line ending with
'>>' never is valid, except in cases where something like an '<

Bug: Fontification: Heading following a comment

2020-03-20 Thread Sebastian Miele
Current master branch Org. Create an Org file with just the following
two lines

#
* A

Save, kill the buffer, find the file again. Then "* A" is in
org-meta-line face.



Bug: org-babel-expand-noweb-references: FIXEDCASE=nil

2020-03-09 Thread Sebastian Miele
org-babel-expand-noweb-references in the current master branch ends with:

  (replace-regexp-in-string noweb-re (lambda...) body nil t 2)

I.e., the FIXEDCASE argument to replace-regexp-in-string is nil. This
has the effect that in

  #+BEGIN_SRC elisp :noweb-ref AA
(ignore)
  #+END_SRC

  #+BEGIN_SRC elisp :noweb yes
<>
  #+END_SRC

the second block is expanded as "(IGNORE)". That probably is a bug.
FIXEDCASE should be t.



Re: Typo in Org Manual

2020-03-06 Thread Sebastian Miele
Sebastian Miele  writes:
>
> But how about instead changing the first sentence of the "Range
> references" section from
>
>   You may reference a rectangular range of fields by specifying two
>   field references connected by two dots ‘..’.
>
> to
>
>   You may reference a rectangular range of fields, including the ends,
>   by specifying two field references connected by two dots ‘..’.
>
> ?

I think even better would be to just add the following after the
sentence mentioned above:

  The ends are included in the range.



Re: Typo in Org Manual

2020-03-06 Thread Sebastian Miele
Kyle Meyer  writes:
>
> Sebastian Miele  writes:
>
> > In an example for Org table range references it says:
> >
> > ‘@2$1..@4$3’   six fields between these two fields (same as ‘A2..C4’)
>
> Oh, that mistake has been around for a long time.
>
> > However, it are nine fields instead of six.
>
> If we were to simply replace "six" with "nine", I think the
> description could still be confusing because it's ambiguous whether
> "between" includes the ends. (I would tend to read the above
> description as exclusive.)

At least for me, "nine" would not be confusing at all, because among the
sensible interpretations of the range specification, "nine" uniquely
identifies the maximally inclusive one.

If it were a problem, then the preceding and following examples all have
the same problem, too, except maybe the hline example.

> How about "nine fields between and including these two fields"? Any
> other suggestions?

In my opinion this is not necessary. The examples (assuming "nine"
instead of "six") make it clear enough, that always the maximally
inclusive sensible interpretation of the range specification is used.

But how about instead changing the first sentence of the "Range
references" section from

  You may reference a rectangular range of fields by specifying two
  field references connected by two dots ‘..’.

to

  You may reference a rectangular range of fields, including the ends,
  by specifying two field references connected by two dots ‘..’.

?



Typo in Org Manual

2020-03-04 Thread Sebastian Miele
In an example for Org table range references it says:

‘@2$1..@4$3’   six fields between these two fields (same as ‘A2..C4’)

However, it are nine fields instead of six.



Re: [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2020-02-13 Thread Sebastian Miele
Sebastian Miele  writes:

> Bastien  writes:
> >
> > Sebastian Miele  writes:
> >
> > > I am quite certain, that the content indentation conceptually and
> > > technically belongs to the buffer containing the src block.
> >
> > Sorry, I think I got confused - let's call buffer-A the one with the
> > "#+begin_src ... #+end_src" string and buffer-B the one you get when
> > C-c ' on this string (the src block).
> >
> > If "the buffer containing the src block" is buffer A, then we are on
> > the same line.  Is it the case?  Or am I still confused?
>
> Yes, we are on the same line.

Part of me feels that I should find a better explanation and spare you
the trouble of figuring out what I mean. But there seems to be no
(significantly) better explanation I can come up with without going to
greater lengths and especially investing considerable time for working
out very clear terminology for the situation.

I currently feel a tension between not wanting you to have to spend
considerable time understanding what I wrote and not wanting myself to
spend time to try to explain it better.

However, if it is necessary, I will take the time.

Please try having it in the back of your mind for some days, maybe even
without actively spending much time on trying to understand it. Then
tell me if struck or not.

All the best
Sebastian



Re: [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2020-02-12 Thread Sebastian Miele
Bastien  writes:
>
> Sebastian Miele  writes:
>
> > I am quite certain, that the content indentation conceptually and
> > technically belongs to the buffer containing the src block.
>
> Sorry, I think I got confused - let's call buffer-A the one with the
> "#+begin_src ... #+end_src" string and buffer-B the one you get when
> C-c ' on this string (the src block).
>
> If "the buffer containing the src block" is buffer A, then we are on
> the same line.  Is it the case?  Or am I still confused?

Yes, we are on the same line.



Re: [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2020-02-12 Thread Sebastian Miele
Hi Bastien,

Bastien  writes:
>
> Sebastian Miele  writes:
>
> > * lisp/org-src.el (org-src--contents-for-write-back): Use the
> > potentially buffer-local value of `org-edit-src-content-indentation'
> > from the source buffer instead of that from the editing buffer.
>
> I'm not sure about I see why this patch would be useful.
>
> IIUC, in case `org-edit-src-content-indentation' is set in the src
> block buffer itself, you want Org to honor its value _there_ instead
> of the value this variable has in the org buffer (containing the src
> block)?

I am quite certain, that the content indentation conceptually and
technically belongs to the buffer containing the src block. Except for
src blocks containing org I see no point at all for setting a content
indentation in an edit buffer for the block. There just is no meaning of
an org src content indentation in e.g. an Elisp buffer.

And for an src buffer containing org the meaning would be the content
intentation for the org in the block, and not for the org containing the
block.

> I find it difficult to see a compelling use case, please let me know
> if I don't understand correctly.

Nicolas already accepted the patch. Currently it is included as commit
3649d95b in the history of master. Before accepting the patch, he too
asked for a use case. Please see

https://lists.gnu.org/archive/html/emacs-orgmode/2019-11/msg00052.html

for the answer.

Best wishes
Sebastian



Re: [RFC] Document level property drawer

2020-01-15 Thread Sebastian Miele
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: Editting from the agenda view

2019-11-26 Thread Sebastian Miele
Hi Shérab,

Shérab  writes:

> Dear Victor,
>
> Many thanks for your response and sorry for the delay of mine!
>
> Victor A. Stoichita (2019/11/23 09:14 +0100):
>>
>> Le 22 Nov 2019, Shérab  a écrit :
>> > When I am in an agenda view, say the weekly view, how can I edit one of
>> > the listed entries? I may want to do that either because I notice I have
>> > made a typo that I would like to fix, or because I would like to
>> > re-schedule the entry for another date.
>>
>> To reschedule an entry remotely from the agenda view, you can press S-right
>> (org-agenda-do-date-later) or S-left (org-agenda-do-date-earlier).
>
> I indeed remember having seen these commands!
> The thing is that I am using emacs in the Linux console where these
> bindings do not work, so I couldn't try them. Is there a way to bind
> them to different key bindings? I am asking becuase I assume the
> bindings you mention are specific to the agenda view and the way to
> modify them is thus different from ordinary, global bindings. Am I
> correct?

After opening the agenda, inspection of the buffer-local variable
major-mode (e.g. by C-h v) reveals that the major mode in the agenda
buffer is org-agenda-mode. A search for a variable containing
"org-agenda", and "map" reveals that most probably org-agenda-mode-map
is the keymap used there. It follows the usual naming scheme for major
mode maps.

After (require 'org-agenda) it will be possible to (define-key
org-agenda-mode-map KEY BINDING) in an init file.

Best wishes
Sebastian



Re: noweb multiple block together

2019-11-24 Thread Sebastian Miele
Hi Ken,

Ken Mankoff  writes:

> When tangling blocks, I can tangle multiple blocks by setting a
> (sub)-tree level property, or ":tangle foo" in multiple headers. Is
> there a way to achieve the same thing with noweb?
>
> I've tried giving multiple blocks the same "+name:" and then <>,
> but only one seems to be included. Does this feature exist through
> some mechanism?

A block named by #+name: should always be unique per file. Otherwise the
Org tangling code that I looked at until now (which is most or even all
in the master branch) just uses the first one found, without checking
for duplicates.

On the other hand there is the possibility to give a common name to
multiple blocks via the header arg :noweb-ref. That works in the way you
looking for.

There is a further difference between these two kinds of naming: With
blocks named by :noweb-ref it is not possible to do something like
<>. Only <>, i.e. plain inclusion, is possible.

Best wishes
Sebastian



Re: [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2019-11-19 Thread Sebastian Miele
Hi Nicolas,

Nicolas Goaziou  writes:

> Sebastian Miele  writes:
>
>> The Org default of org-edit-src-content-indentation is 2. I like that
>> value and leave it that way. Worg's root .dir-locals sets it to 0
>> buffer-locally in at least many Worg's Org files. Hence, when I edit an
>> src block in a Worg file, the value of org-edit-src-content-indentation
>> in the edit buffer is 2. But the correct value in that case is 0.
>
> Then I think we should do the same as what is done for, e.g.,
> `org-src--preserve-indentation`, i.e. store the initial value from
> `org-src--edit-element', and use it in
> `org-src--contents-for-write-back'.
>
> WDYT?

That's perfectly fine with me. An updated patch is attached.

Best wishes
Sebastian
>From a8575e16e2496b2bdcddaaae2532f510a5b18908 Mon Sep 17 00:00:00 2001
From: Sebastian Miele 
Date: Wed, 9 Oct 2019 01:00:50 +
Subject: [PATCH] Respect buffer-local value of
 `org-edit-src-content-indentation'

* lisp/org-src.el (org-src--content-indentation): Introduce
permanently buffer-local variable for storing away the potentially
buffer-local value of `org-edit-src-content-indentation' in the source
buffer.

(org-src--contents-for-write-back): Use `org-src--content-indentation'
instead of `org-edit-src-content-indentation' in the edit buffer.

(org-src--edit-element): Set `org-src--content-indentation' in editing
buffer.  For greater clarity and consistency, rename already existing
let-bound variable `ind' to `block-ind'.

* etc/ORG-NEWS: Add entry.
---
 etc/ORG-NEWS|  4 
 lisp/org-src.el | 15 ++-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 283f32e0c..eab9e021b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -434,6 +434,10 @@ leave unfolded subtrees unfolded.
 I.e. treat the whole file as if it was a subtree.
 
 *** Respect narrowing when agenda command is restricted to buffer
+*** Respect buffer-local value of ~org-edit-src-content-indentation~
+
+Use the potentially buffer-local value of `org-edit-src-content-indentation'
+from the source buffer instead of that from the editing buffer.
 
 * Version 9.2
 ** Incompatible changes
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 9134d5b5d..418f3a662 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -258,6 +258,9 @@ issued in the language major mode buffer."
 (defvar-local org-src--block-indentation nil)
 (put 'org-src--block-indentation 'permanent-local t)
 
+(defvar-local org-src--content-indentation nil)
+(put 'org-src--content-indentation 'permanent-local t)
+
 (defvar-local org-src--end-marker nil)
 (put 'org-src--end-marker 'permanent-local t)
 
@@ -422,7 +425,7 @@ Assume point is in the corresponding edit buffer."
 (if org-src--preserve-indentation 0
   (+ (or org-src--block-indentation 0)
  (if (memq org-src--source-type '(example-block src-block))
- org-edit-src-content-indentation
+ org-src--content-indentation
0
(use-tabs? (and (> org-src--tab-width 0) t))
(source-tab-width org-src--tab-width)
@@ -484,9 +487,10 @@ Leave point in edit buffer."
 (source-file-name (buffer-file-name (buffer-base-buffer)))
 (source-tab-width (if indent-tabs-mode tab-width 0))
 (type (org-element-type datum))
-(ind (org-with-wide-buffer
-  (goto-char (org-element-property :begin datum))
-  (current-indentation)))
+(block-ind (org-with-wide-buffer
+(goto-char (org-element-property :begin datum))
+(current-indentation)))
+(content-ind org-edit-src-content-indentation)
 (preserve-ind
  (and (memq type '(example-block src-block))
   (or (org-element-property :preserve-indent datum)
@@ -529,7 +533,8 @@ Leave point in edit buffer."
(setq org-src--end-marker end)
(setq org-src--remote remote)
(setq org-src--source-type type)
-   (setq org-src--block-indentation ind)
+   (setq org-src--block-indentation block-ind)
+   (setq org-src--content-indentation content-ind)
(setq org-src--preserve-indentation preserve-ind)
(setq org-src--overlay overlay)
(setq org-src--allow-write-back write-back)
-- 
2.24.0



Re: [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2019-11-03 Thread Sebastian Miele
Hi Nicolas,

Nicolas Goaziou  writes:

> Sebastian Miele  writes:
>
>> Subject: [PATCH] Respect buffer-local value of
>>  `org-edit-src-content-indentation'
>>
>> * lisp/org-src.el (org-src--contents-for-write-back): Use the
>> potentially buffer-local value of `org-edit-src-content-indentation'
>> from the source buffer instead of that from the editing buffer.
>
> Thank you.
>
> Would you mind explaining your use case?

The Org default of org-edit-src-content-indentation is 2. I like that
value and leave it that way. Worg's root .dir-locals sets it to 0
buffer-locally in at least many Worg's Org files. Hence, when I edit an
src block in a Worg file, the value of org-edit-src-content-indentation
in the edit buffer is 2. But the correct value in that case is 0.

Best wishes
Sebastian



Re: [O] Get the text of a node

2019-10-23 Thread Sebastian Miele
Joost Kremers  writes:

> I was wondering if there's a way to programmatically get the text of a
> node in an Org buffer. Basically, I have a buffer that looks something
> like this:
>
> #+BEGIN_SRC org
> * Top header
> ** Subheader
>   :PROPERTIES:
>   :Custom_ID: some_id
>   :END:
>
>   Text starts here, possibly with additional subheaders
> #+END_SRC
>
> What I would like to extract is the text below "Subheader", but
> without the :PROPERTIES: block.
>
> I've looked at the org-element library, but I haven't been able to
> figure out how to use it to extract just the plain text.

You probably are not aware of dev/org-element-api.org in Worg, yet. It
is a very good introduction to and systematic overview of the element
api. It is not mentioned at the top of org-element.el.

> I use the :Custom_ID: property to find the relevant subheading and I
> know I can use (org-back-to-heading) to get point to the Subheader
> containing the relevant :PROPERTIES: block. Obviously, I could then
> narrow the buffer to the subheader, use a text search to move point
> past the line containing :END: and then extract the text from there
> until (point-max).
>
> I'm just wondering if this may break in unexpected circumstances and
> whether there's a better way.

A robust way that I see is the following. The first two steps may be
optional. Or they could be expanded slightly in order to even exclude
possible subheadings from the work of org-element-parse-buffer in the
last step.

1. Call org-element-at-point on the heading. The resulting element has
:begin and :end properties. They contain the buffer positions of the
beginning of the headline and the end of everything that belongs to the
headline, including paragraphs and subheadings.

2. Call narrow-to-region on those positions.

3. Call org-element-parse-buffer.

See dev/org-element-api.org for what that returns and why that works.

Best wishes
Sebastian



[O] [PATCH] COMMENT and noweb-ref

2019-10-20 Thread Sebastian Miele
Sorry. I messed up the previous mail. Please ignore it.

I wrote:

> org-babel-tangle on
>
>   * A
>
> #+BEGIN_SRC elisp :tangle yes :noweb yes
> ;; A
> <>
> #+END_SRC
>
>   * COMMENT B
>
> #+BEGIN_SRC elisp :noweb-ref B
> ;; B
> #+END_SRC
>
>   * COMMENT C
>
> #+BEGIN_SRC elisp :tangle yes
> ;; C
> #+END_SRC
>
> produces a file with A and B in it. Expected: Just A. Changing
>
> #+BEGIN_SRC elisp :noweb-ref B
> ;; B
> #+END_SRC
>
> to
>
> # #+BEGIN_SRC elisp :noweb-ref B
> # ;; B
> # #+END_SRC
>
> does yield the expected result.

Attached is a patch that fixes the problem.

A second patch is attached that contains tests about this and related
stuff. It is an updated version of an unapplied patch that I
sent to this list earlier this month
(https://lists.gnu.org/archive/html/emacs-orgmode/2019-10/msg00013.html).

Best wishes
Sebastian
>From ddf0b6d89d30766158311c047d6de10091cb0377 Mon Sep 17 00:00:00 2001
From: Sebastian Miele 
Date: Sun, 20 Oct 2019 21:34:02 +
Subject: [PATCH 1/2] ob-core: Respect COMMENTed headlines when expanding noweb
 references

* lisp/ob-core.el (org-babel-expand-noweb-references): Add calls to
org-in-commented-heading-p where appropriate.
---
 lisp/ob-core.el | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 572f97919..b99545ab5 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2780,7 +2780,8 @@ block but are passed literally to the \"example-block\"."
(concat (funcall c-wrap (car cs)) "\n"
b "\n"
(funcall c-wrap (cadr cs)
- (if (re-search-forward name-regexp nil t)
+ (if (and (re-search-forward name-regexp nil t)
+  (not (org-in-commented-heading-p)))
  ;; Found a source block named SOURCE-NAME.
  ;; Assume it is unique; do not look after
  ;; `:noweb-ref' header argument.
@@ -2791,14 +2792,16 @@ block but are passed literally to the 
\"example-block\"."
;; those with a matching Noweb reference.
(let ((expansion nil))
  (org-babel-map-src-blocks nil
-   (let* ((info (org-babel-get-src-block-info 'light))
-  (parameters (nth 2 info)))
- (when (equal source-name
-  (cdr (assq :noweb-ref parameters)))
-   (push (funcall expand-body info) expansion)
-   (push (or (cdr (assq :noweb-sep parameters))
- "\n")
- expansion
+   (unless (org-in-commented-heading-p)
+ (let* ((info
+ (org-babel-get-src-block-info 'light))
+(parameters (nth 2 info)))
+   (when (equal source-name
+(cdr (assq :noweb-ref parameters)))
+ (push (funcall expand-body info) expansion)
+ (push (or (cdr (assq :noweb-sep parameters))
+   "\n")
+   expansion)
  (when expansion
    (mapconcat #'identity
   (nreverse (cdr expansion))
-- 
2.23.0

>From 66c7904298a33900e389acb184fbe7511960b34d Mon Sep 17 00:00:00 2001
From: Sebastian Miele 
Date: Sun, 20 Oct 2019 21:38:03 +
Subject: [PATCH 2/2] Add tests about omission of commented src blocks when
 e.g. tangling

* testing/lisp/test-ob.el (test-ob/noweb-expansion): Add clause to
test.
* testing/lisp/test-ob-tangle.el (ob-tangle/commented-src-blocks): Add
test.
---
 testing/lisp/test-ob-tangle.el | 84 ++
 testing/lisp/test-ob.el| 24 ++
 2 files changed, 108 insertions(+)

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 47c31dff5..301f7aff7 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -296,6 +296,90 @@ another block
(org-split-string (buffer-string
  (delete-file file))
 
+(ert-deftest ob-tangle/commented-src-blocks ()
+  "Test omission of commented src blocks."
+  (should
+   (equal '("A")
+ (let ((file (make-temp-file "org-tan

[O] [PATCH] COMMENT and noweb-ref

2019-10-20 Thread Sebastian Miele
>From ddf0b6d89d30766158311c047d6de10091cb0377 Mon Sep 17 00:00:00 2001
From: Sebastian Miele 
Date: Sun, 20 Oct 2019 21:34:02 +
Subject: [PATCH 1/2] ob-core: Respect COMMENTed headlines when expanding noweb
 references

* lisp/ob-core.el (org-babel-expand-noweb-references): Add calls to
org-in-commented-heading-p where appropriate.
---
 lisp/ob-core.el | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 572f97919..b99545ab5 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2780,7 +2780,8 @@ block but are passed literally to the \"example-block\"."
(concat (funcall c-wrap (car cs)) "\n"
b "\n"
(funcall c-wrap (cadr cs)
- (if (re-search-forward name-regexp nil t)
+ (if (and (re-search-forward name-regexp nil t)
+  (not (org-in-commented-heading-p)))
  ;; Found a source block named SOURCE-NAME.
  ;; Assume it is unique; do not look after
  ;; `:noweb-ref' header argument.
@@ -2791,14 +2792,16 @@ block but are passed literally to the 
\"example-block\"."
;; those with a matching Noweb reference.
(let ((expansion nil))
  (org-babel-map-src-blocks nil
-   (let* ((info (org-babel-get-src-block-info 'light))
-  (parameters (nth 2 info)))
- (when (equal source-name
-  (cdr (assq :noweb-ref parameters)))
-   (push (funcall expand-body info) expansion)
-   (push (or (cdr (assq :noweb-sep parameters))
- "\n")
- expansion
+   (unless (org-in-commented-heading-p)
+ (let* ((info
+ (org-babel-get-src-block-info 'light))
+(parameters (nth 2 info)))
+   (when (equal source-name
+(cdr (assq :noweb-ref parameters)))
+ (push (funcall expand-body info) expansion)
+ (push (or (cdr (assq :noweb-sep parameters))
+   "\n")
+   expansion)
  (when expansion
(mapconcat #'identity
   (nreverse (cdr expansion))
-- 
2.23.0

>From 66c7904298a33900e389acb184fbe7511960b34d Mon Sep 17 00:00:00 2001
From: Sebastian Miele 
Date: Sun, 20 Oct 2019 21:38:03 +
Subject: [PATCH 2/2] Add tests about omission of commented src blocks when
 e.g. tangling

* testing/lisp/test-ob.el (test-ob/noweb-expansion): Add clause to
test.
* testing/lisp/test-ob-tangle.el (ob-tangle/commented-src-blocks): Add
test.
---
 testing/lisp/test-ob-tangle.el | 84 ++
 testing/lisp/test-ob.el| 24 ++
 2 files changed, 108 insertions(+)

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 47c31dff5..301f7aff7 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -296,6 +296,90 @@ another block
(org-split-string (buffer-string
  (delete-file file))
 
+(ert-deftest ob-tangle/commented-src-blocks ()
+  "Test omission of commented src blocks."
+  (should
+   (equal '("A")
+ (let ((file (make-temp-file "org-tangle-")))
+   (unwind-protect
+   (progn
+ (org-test-with-temp-text-in-file
+ (format "#+property: header-args :tangle %S
+* A
+
+  #+begin_src emacs-lisp
+  A
+  #+end_src
+
+* COMMENT B
+
+  #+begin_src emacs-lisp
+  B
+  #+end_src
+
+* C
+
+  # #+begin_src emacs-lisp
+  # C
+  # #+end_src
+
+* D
+
+  #+begin_comment
+  #+begin_src emacs-lisp
+  D
+  #+end_src
+  #+end_comment"
+ file)
+   (org-babel-tangle))
+ (with-temp-buffer
+   (insert-file-contents file)
+   (org-split-string (buffer-string
+ (delete-file file)
+  (should
+   (equal '("A")
+ (let ((file (make-temp-file "org-tangle-")))
+   (unwind-protect
+   (progn
+ (org-test-with-temp-text-in-file
+ (format "#+property: header-args :tangle %S
+* A
+
+  #+begin_src elisp :noweb yes
+  A
+  

Re: [O] [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2019-10-16 Thread Sebastian Miele
Hello Adam,

Adam Porter  writes:
> You might consider using the function buffer-local-value instead of the
> macro with-current-buffer.  Not that it matters so much here, but
> benchmarking shows that it is much faster when simply accessing the
> buffer-local value of a variable.

Thank you. Such information is always very welcome.

An updated patch is attached to this mail. I also added an ORG-NEWS
entry.

Best wishes
Sebastian

>From 34eb8882e09701aa12da40510a24c688f4a5ac20 Mon Sep 17 00:00:00 2001
From: Sebastian Miele 
Date: Wed, 9 Oct 2019 01:00:50 +
Subject: [PATCH] Respect buffer-local value of
 `org-edit-src-content-indentation'

* lisp/org-src.el (org-src--contents-for-write-back): Use the
potentially buffer-local value of `org-edit-src-content-indentation'
from the source buffer instead of that from the editing buffer.
---
 etc/ORG-NEWS| 4 
 lisp/org-src.el | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 0e07326cb..b562a0935 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -428,6 +428,10 @@ leave unfolded subtrees unfolded.
 I.e. treat the whole file as if it was a subtree.
 
 *** Respect narrowing when agenda command is restricted to buffer
+*** Respect buffer-local value of ~org-edit-src-content-indentation~
+
+Use the potentially buffer-local value of `org-edit-src-content-indentation'
+from the source buffer instead of that from the editing buffer.
 
 * Version 9.2
 ** Incompatible changes
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 9134d5b5d..99841c211 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -422,7 +422,8 @@ Assume point is in the corresponding edit buffer."
 (if org-src--preserve-indentation 0
   (+ (or org-src--block-indentation 0)
  (if (memq org-src--source-type '(example-block src-block))
- org-edit-src-content-indentation
+ (buffer-local-value 'org-edit-src-content-indentation
+ (marker-buffer org-src--beg-marker))
0
(use-tabs? (and (> org-src--tab-width 0) t))
(source-tab-width org-src--tab-width)
-- 
2.23.0



[O] [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2019-10-14 Thread Sebastian Miele
* lisp/org-src.el (org-src--contents-for-write-back): Use the
potentially buffer-local value of `org-edit-src-content-indentation'
from the source buffer instead of that from the editing buffer.
---
 lisp/org-src.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 9134d5b5d..b7fe4c0fa 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -422,7 +422,8 @@ Assume point is in the corresponding edit buffer."
 (if org-src--preserve-indentation 0
   (+ (or org-src--block-indentation 0)
  (if (memq org-src--source-type '(example-block src-block))
- org-edit-src-content-indentation
+ (with-current-buffer (marker-buffer org-src--beg-marker)
+   org-edit-src-content-indentation)
0
(use-tabs? (and (> org-src--tab-width 0) t))
(source-tab-width org-src--tab-width)
-- 
2.23.0




[O] [PATCH] org-manual: Dynamic Blocks: Fix explanation of :content

2019-10-14 Thread Sebastian Miele
* doc/org-manual.org (Dynamic Blocks): Correct the information given
on :content in the plist passed to the writer function.
---
 doc/org-manual.org | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 59591894d..79257b7e0 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -20089,13 +20089,12 @@ These commands update dynamic blocks:
 
 Before updating a dynamic block, Org removes content between the
 =BEGIN= and =END= markers.  Org then reads the parameters on the
-=BEGIN= line for passing to the writer function.  If the function
-expects to access the removed content, then Org expects an extra
-parameter, =:content=, on the =BEGIN= line.
+=BEGIN= line for passing to the writer function as a plist. The
+previous content of the dynamic block becomes erased from the buffer
+and appended to the plist under ~:content~.
 
 The syntax for naming a writer function with a dynamic block labelled
-=myblock= is: ~org-dblock-write:myblock~.  Parameters come from the
-=BEGIN= line.
+=myblock= is: ~org-dblock-write:myblock~.
 
 The following is an example of a dynamic block and a block writer function
 that updates the time when the function was last run:
-- 
2.23.0




Re: [O] Make org-agenda-switch-to to show all parent headings

2019-10-13 Thread Sebastian Miele


Joon Ro  writes:

> When I right click on an agenda item to invoke org-agenda-switch-to,
> it shows only the specific heading for the item and its top-level
> heading, and in-between headings are not shown. Is there a way to
> change this behavior so it shows all parent headings of the item?
> Currently I often am confused which parent the right-clicked item
> belongs to. Please see below for a minimal example:
>
> Current behavior:
>
> * Top Heading
> *** TODO Heading for the right-clicked item in the agenda
>
> Desired behavior:
>
> * Top Heading
> ** Second heading
> *** TODO Heading for the right-clicked item in the agenda

The variable `org-show-context-detail' probably is what you are looking
for.

Best wishes
Sebastian



Re: [O] managing repetitive code in export & tangling

2019-10-08 Thread Sebastian Miele
Matt Price  writes:

> In my lectures i often have simple examples that build progressively
> over several slides. In order to use klipse properly, but also for
> clarity, I gneerally repeat variable declarations from slide to slide,
> so for instance:
>
> ** Making Lists (Arrays)
>
> +#NAME: js-array-historians
> #+BEGIN_SRC js
> let historians= ["Edward Gibbon", "Leopold von Ranke", "Edward Said", "Joan
> Scott"];
> #+END_SRC
>
> ** Repetition: While Loops
> #+NAME: js-while-hist
> #+begin_src js
> <>
> let i = 0;
>
> while (i < historians.length) {
> console.log(historians[i] + " was a historian.");
> i+=1;
>   }
> #+end_src
>
> There might then be a sequence of another 5 or 6 slides in which the same
> "historians" array is bound to the same value and used as an example.
>
> This works fine on its own. However, I would also like to tangle all this
> code to a single file per lecture so students can download a git repo and
> play with it directly in a real text editor. Unfortunately, javascript will
> error out if a ~let~ bound variable is  redeclared in the same scope.  I'm
> wondering if there's any way to specify that a noweb reference only be
> included one time in a tangled file. Or if there are cleverer workarounds
> that folks can suggest!

I have not used the exporting facilities of Org by myself, yet. However,
if what you sketch above does already produce expected results, then
something like the following should solve your problem. (The single
angle-bracketed stuff has to be replaced by the appropriate header
args.)

** Making Lists (Arrays)

#+NAME: js-array-historians
#+BEGIN_SRC js 
  let historians= ["Edward Gibbon", "Leopold von Ranke", "Edward Said", "Joan 
Scott"];
#+END_SRC

** Repetition: While Loops

#+NAME: js-while-hist
#+BEGIN_SRC js 
  let i = 0;
  while (i < historians.length) {
  console.log(historians[i] + " was a historian.");
  i+=1;
}
#+END_SRC

#+BEGIN_SRC js 
  <>
  <>
#+END_SRC

Best wishes
Sebastian



Re: [O] Bug: COMMENT and noweb-ref

2019-10-08 Thread Sebastian Miele


I wrote:

> I wrote:
>
>> org-babel-tangle on
>>
>>   * A
>>
>> #+BEGIN_SRC elisp :tangle yes :noweb yes
>> ;; A
>> <>
>> #+END_SRC
>>
>>   * COMMENT B
>>
>> #+BEGIN_SRC elisp :noweb-ref B
>> ;; B
>> #+END_SRC
>>
>>   * COMMENT C
>>
>> #+BEGIN_SRC elisp :tangle yes
>> ;; C
>> #+END_SRC
>>
>> produces a file with A and B in it. Expected: Just A. Changing
>>
>> #+BEGIN_SRC elisp :noweb-ref B
>> ;; B
>> #+END_SRC
>>
>> to
>>
>> # #+BEGIN_SRC elisp :noweb-ref B
>> # ;; B
>> # #+END_SRC
>>
>> does yield the expected result.
>
> In the following days I will try to fix it and write a regression test.

I wanted to mention that this is still on my agenda. But it will take a
while. Among other things, I have to learn the formal syntax and the
element api of Org, before I can satisfactorily dive into ob-tangle.el.
Apart from that I had to seriously limit my Emacs time per day.

It may take several weeks. But it will happen.

Best wishes
Sebastian



Re: [O] noweb and :var statements

2019-10-07 Thread Sebastian Miele


Ken Mankoff  writes:

> Hi Sebastian,
>
> Thanks for your help. I was running with "-Q" but must have been
> making some other mistakes. It does work.
>
> As for your other email... I do know several tangles can go to the
> same file. And I may be using <> incorrectly, but I'm using it
> for the following reasons:
>
> 1) I'd like to bury code that must run first but is inconsequential at
> the bottom of the Org file. Noweb lets me have a tangled <> at
> the top, and then hide the lengthy <> code elsewhere. Is this a
> correct use case?

Yes.

> 2) I'd like to import 10 tables, so I thought a noweb function might
> be useful for code reuse.
>
> I finally got the behavior I'm looking for. What I need to
> remember/understand is that <> just pastes the body, and
> <> evaluates the function. From this, my Python code needs to
> generate Python code! I now have the following MWE that behaves as I
> want both for in-buffer C-c C-c eval of main code block and tangled
> results. The key bit of code is the last babel block.

A solution without having to write code-writing code is tangling to
different files (MWE3.py and setup.py). See the example below.

I read somewhere that Python has stong reflection features. It should be
possible to write Python code that, given a string and a value,
introduces a Python variable of that name and binds the value to it. If
you find out how that works, the mangle block below can be changed so
that the main block has e.g. setup.A.sum() instead of
setup.tables["A"].sum().

Final disclaimer: There may and probably are other possibilies that I do
not know or have not thought of.

* Main Project

#+NAME: main
#+BEGIN_SRC python :tangle MWE3.py :noweb yes :results output
import setup
print(setup.tables["A"].sum())
print(setup.tables["B"].sum())
#+END_SRC

* Data Tables
#+NAME: table_42
| foo |
|-|
|  42 |
|  42 |

#+NAME: table_100
| bar |
|-|
| 100 |

* Setup

#+BEGIN_SRC python :tangle setup.py
import numpy as np
tables={}
#+END_SRC

#+NAME: mangle
#+BEGIN_SRC python
tables[name] = np.array(table).astype(np.float).flatten()
#+END_SRC

#+BEGIN_SRC python :tangle setup.py :noweb yes :var table=table_42 :var name="A"
<>
#+END_SRC

#+BEGIN_SRC python :tangle setup.py :noweb yes :var table=table_100 :var 
name="B"
<>
#+END_SRC



Re: [O] noweb and :var statements

2019-10-06 Thread Sebastian Miele


I wrote:

> [..]
>
> Please try it with emacs -Q. Maybe your config is broken.

After starting emacs -Q you will have to
M-x customize-variable RET org-babel-load-languages
and add Python as a loaded language.



Re: [O] noweb and :var statements

2019-10-06 Thread Sebastian Miele


Ken Mankoff  writes:

> On 2019-10-06 at 21:52 +02, Sebastian Miele  
> wrote...
>> I wrote:
>>
>>> [..]
>>>
>>> However, something like the following may suit your use case. (For the
>>> header-args property see section 15.2 (Using Header Arguments) of the
>>> manual.)
>>>
>>> * A Heading
>>> :PROPERTIES:
>>> :header-args: :var table=table_foo
>>> :END:
>>>
>>> #+NAME: table_foo
>>> | foo |
>>> |-|
>>> |  42 |
>>> | 100 |
>>>
>>> #+NAME: import
>>> #+BEGIN_SRC python
>>> import numpy as np
>>> table = np.array(table).astype(np.float).flatten()
>>> #+END_SRC
>>>
>>> #+BEGIN_SRC python :noweb yes :tangle import_noweb.py
>>> <>
>>> #+END_SRC
>>
>> Just the following works too, of course:
>>
>> #+NAME: table_foo
>> | foo |
>> |-|
>> |  42 |
>> | 100 |
>>
>> #+NAME: import
>> #+BEGIN_SRC python
>> import numpy as np
>> table = np.array(table).astype(np.float).flatten()
>> #+END_SRC
>>
>> #+BEGIN_SRC python :noweb yes :var table=table_foo :tangle import_noweb.py
>> <>
>> #+END_SRC
>
> The result of tangling this is "import_noweb.py" contains:
>
> import numpy as np
> table = np.array(table).astype(np.float).flatten()
>
> And I'd like it to somewhere include the line:
> table = [42,100]
> or something similar. I don't have the table data in the tangled code.

Strange. On my system, typing C-c C-v t (org-babel-tangle) in an Org
file with the above mentioned contents does yield a file import_noweb.py
with the following contents:

table=[[42], [100]]
import numpy as np
table = np.array(table).astype(np.float).flatten()

Please try it with emacs -Q. Maybe your config is broken.



Re: [O] noweb and :var statements

2019-10-06 Thread Sebastian Miele


Ken Mankoff  writes:

> Hi Sebastian,
>
> I'm not getting the results I expect from your MWE either. Perhaps I
> gave too much code and asked X when what I really want is Y. I think
> I've distilled it to this:
>
> What is the most elegant Org way to get a table into a Python array?

I do not know whether it is the most elegant way, but the following
works, and probably is at least close to shortes possible way:

#+NAME: table_foo
| foo |
|-|
|  42 |
| 100 |

#+BEGIN_SRC python :var table=table_foo :tangle table.py
#+END_SRC

After tangling, table.py contains "table=[[42], [100]]".

Did you know that you can have several source code blocks tangling to
the same file? Maybe you do not really need noweb stuff at all. If you
add a second block, e.g.

#+BEGIN_SRC python :tangle table.py
mangle_table
#+END_SRC

then, after tangling, table.py contains "table=[[42], [100]]" and
"mangle_table".


> I can code it directly:
>
> #+BEGIN_SRC python
> <>
> print(foo)
> #+END_SRC
>
>
> And now I can hide <> in a section at the bottom of the
> document. If it looks like this, everything works:
>
> #+NAME: setup
> #+BEGIN_SRC python
> foo = np.array([42,43,44])
> #+END_SRC
>
> But is there a more elegant method? Can I get the same behavior if the
> data I want is in an Org table rather than hard-coded directly in
> Python?

This use-case is covered by what I wrote above. You can put the named
Org table at the bottom of the file.

Another note: You can tangle to different files from one Org file. You
may e.g. add an additional source block:

#+BEGIN_SRC python :tangle use_table.py
include_table_py
use_table
#+END_SRC

where include_table_py must be replaced by the Python way of saying:
include the file table.py. (I do not know Python.)

> Ideally, I'd like to have:
>
> #+NAME: setup
> #+BEGIN_SRC python
> <>
> <>
> #+END_SRC
>
> And a #+NAME: setup block that takes a :var table and sticks it in the
> :var varname variable.

I strongly suspect that you do not really need noweb stuff and still
struggle to understand the very basics of tangling.

> And then after calling <> be able to use variable "foo" and
> "bar" that are generated from column or 2D Org tables elsewhere in the
> document. Can I do this in Org?
>
> Thanks,
>
>   -k.



Re: [O] noweb and :var statements

2019-10-06 Thread Sebastian Miele


I wrote:

> [..]
>
> However, something like the following may suit your use case. (For the
> header-args property see section 15.2 (Using Header Arguments) of the
> manual.)
>
> * A Heading
> :PROPERTIES:
> :header-args: :var table=table_foo
> :END:
>
> #+NAME: table_foo
> | foo |
> |-|
> |  42 |
> | 100 |
>
> #+NAME: import
> #+BEGIN_SRC python
> import numpy as np
> table = np.array(table).astype(np.float).flatten()
> #+END_SRC
>
> #+BEGIN_SRC python :noweb yes :tangle import_noweb.py
> <>
> #+END_SRC

Just the following works too, of course:

#+NAME: table_foo
| foo |
|-|
|  42 |
| 100 |

#+NAME: import
#+BEGIN_SRC python
import numpy as np
table = np.array(table).astype(np.float).flatten()
#+END_SRC

#+BEGIN_SRC python :noweb yes :var table=table_foo :tangle import_noweb.py
<>
#+END_SRC



Re: [O] noweb and :var statements

2019-10-06 Thread Sebastian Miele
Hi Ken!

Ken Mankoff  writes:

> I'm having with noweb and variables. Can someone explain what I'm
> doing wrong? For example, if I have this table:
>
> #+NAME: table_foo
> | foo |
> |-|
> |  42 |
> | 100 |
>
> And I want to import it into Python and use it, I can do that like this:
>
> #+NAME: import
> #+BEGIN_SRC python :var table=table_foo :session foo
> import numpy as np
> table = np.array(table).astype(np.float).flatten()
> #+END_SRC
>
> Eval of this block works, and if I tangle it, I see:
>
>> table=[[42], [100]]
>> import numpy as np
>> table = np.array(table).astype(np.float).flatten()
>
> But if I want to use that block elsewhere via noweb, it doesn't seem to work:
>
> #+BEGIN_SRC python :results output drawer :noweb yes :session foo :tangle 
> import_noweb.py
> <>
> #+END_SRC
>
> The code runs and in a clean *foo* session I do have my table
> variable, but I *also* get an error. The buffer contains the text at
> the bottom of this message, and the tangled code in import_noweb.py is
> only "nil".
>
> How can I 1) run noweb blocks with variables and 2) tangle noweb
> blocks with variables (i.e. tangle tables into source files).

Section 15.10 (Noweb Reference Syntax) of the manual says that e.g.
<> (a noweb reference with parentheses) executes the
NAMEd block with the specified binding and inserts the results of the
execution during tangling. That probably is why the table variable is
there in the session. But the results of executing <> at that
place were not what was intended.

If it were something like

#+NAME: import
#+BEGIN_SRC python :var table=table_foo :results output
import numpy as np
table = np.array(table).astype(np.float).flatten()
CODE
#+END_SRC

where CODE is replaced by some Python code that prints the wanted Python
code, it would work. (Note the omission of the :session and the addition
of :results output. See section 15.5 (Results of Evaluation) of the
manual for the reasons.)

As far as I understand the manual there may be no way to directly attain
what you are trying.

However, something like the following may suit your use case. (For the
header-args property see section 15.2 (Using Header Arguments) of the
manual.)

* A Heading
:PROPERTIES:
:header-args: :var table=table_foo
:END:

#+NAME: table_foo
| foo |
|-|
|  42 |
| 100 |

#+NAME: import
#+BEGIN_SRC python
import numpy as np
table = np.array(table).astype(np.float).flatten()
#+END_SRC

#+BEGIN_SRC python :noweb yes :tangle import_noweb.py
<>
#+END_SRC

Best wishes
Sebastian



[O] Handling of org-edit-src-content-indentation

2019-10-06 Thread Sebastian Miele
Dear fellows!

GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) of 
2019-08-29
Org mode version 9.2.6 (release_9.2.6-544-gd215c3 @ 
/home/w/borg/emacs/org/lisp/)

The variable org-edit-src-content-indentation has a default value of 2.
Buffer-local values for that variable currently are not respected when
using org-edit-src-code. Buffer-local values for this variable are set
in e.g. worg/.dir-locals.el.

The bug can be fixed by changing

  org-edit-src-content-indentation

into

  (with-current-buffer (marker-buffer org-src--beg-marker)
org-edit-src-content-indentation)

in the definition of org-src--contents-for-write-back. However, the
general patterns in the org-src.el suggest, that something similar to

  (defvar-local org-src--preserve-indentation nil)
  (put 'org-src--preserve-indentation 'permanent-local t)

should be introduced, set up, and used.

But except following the pattern, I see no advantage in the latter
approach, even two slight disadvantages. The first beeing that it uses
more lines of code, and the second being so minor and opinionated that I
don't mention it.

Which route shall I take when preparing a patch?

Best wishes
Sebastian



Re: [O] Bug: COMMENT and noweb-ref

2019-10-02 Thread Sebastian Miele
First, here is a patch introducing tests concerning Org comments and
tangling.
>From c769435b9ab11f7a3b5ff5f1ec2df95ae2c6aa32 Mon Sep 17 00:00:00 2001
From: Sebastian Miele 
Date: Wed, 2 Oct 2019 13:02:46 +
Subject: [PATCH] ob-tangle: Add tests

* testing/lisp/test-ob-tangle.el (ob-tangle/commented-src-blocks):
  (ob-tangle/commented-src-blocks-with-nowebref): Add tests.
---
 testing/lisp/test-ob-tangle.el | 85 ++
 1 file changed, 85 insertions(+)

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 47c31dff5..675f0714b 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -296,6 +296,91 @@ another block
(org-split-string (buffer-string
  (delete-file file))
 
+(ert-deftest ob-tangle/commented-src-blocks ()
+  "Test omission of commented src blocks."
+  (should
+   (equal '("A")
+ (let ((file (make-temp-file "org-tangle-")))
+   (unwind-protect
+   (progn
+ (org-test-with-temp-text-in-file
+ (format "#+property: header-args :tangle %S
+* A
+
+  #+BEGIN_SRC emacs-lisp
+  A
+  #+END_SRC
+
+* COMMENT B
+
+  #+BEGIN_SRC emacs-lisp
+  B
+  #+END_SRC
+
+* C
+
+  # #+BEGIN_SRC emacs-lisp
+  # C
+  # #+END_SRC
+
+* D
+
+  #+BEGIN_COMMENT
+  #+BEGIN_SRC emacs-lisp
+  D
+  #+END_SRC
+  #+END_COMMENT"
+ file)
+   (org-babel-tangle))
+ (with-temp-buffer
+   (insert-file-contents file)
+   (org-split-string (buffer-string
+ (delete-file file))
+
+(ert-deftest ob-tangle/commented-src-blocks-with-nowebref ()
+  "Test omission of commented src blocks with nowebref."
+  (should
+   (equal '("A")
+ (let ((file (make-temp-file "org-tangle-")))
+   (unwind-protect
+   (progn
+ (org-test-with-temp-text-in-file
+ (format "#+property: header-args :tangle %S
+* A
+
+  #+BEGIN_SRC elisp :noweb yes
+  A
+  <>
+  <>
+  <>
+  #+END_SRC
+
+* COMMENT B
+
+  #+BEGIN_SRC elisp :noweb-ref B
+  B
+  #+END_SRC
+
+* C
+
+  # #+BEGIN_SRC elisp :noweb-ref C
+  # C
+  # #+END_SRC
+
+* D
+
+  #+BEGIN_COMMENT
+  #+BEGIN_SRC elisp :noweb-ref D
+  D
+  #+END_SRC
+  #+END_COMMENT"
+ file)
+   (org-babel-tangle))
+ (with-temp-buffer
+   (insert-file-contents file)
+   (org-split-string (buffer-string
+ (delete-file file))
+
 (provide 'test-ob-tangle)
 
 ;;; test-ob-tangle.el ends here
-- 
2.23.0



Re: [O] [RFC] Document level property drawer

2019-10-01 Thread Sebastian Miele
Marco Wahl  writes:

> [..]
>
> I think the distinction between Org file and Org subtree should be kept
> to a minimum.  Wouldn't it be nice if Org files can be considered as Org
> subtrees?

Yes, this would be very nice.

I have a related question or proposal.

Up until now, I basically do not use property drawers except absolutely
necessary, because properties are invisible by default. Properties "need
to be inserted into a [..] drawer", and "in order to look inside the
drawer, you need to move point to the drawer line and press ‘’
there."

A place that comes to mind where I really would like to use properties
is the header-args property in order to specify parameters related to
tangling for all src blocks in certain subtrees.

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?

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.



Re: [O] Bug: COMMENT and noweb-ref

2019-09-26 Thread Sebastian Miele
In the following days I will try to fix it and write a regression test.

However, in the unlikely case that this is a feature and not a bug,
please let me know. Please also let me know, if anyone is already on it.

Sebastian Miele  writes:

> org-babel-tangle on
>
>   * A
>
> #+BEGIN_SRC elisp :tangle yes :noweb yes
> ;; A
> <>
> #+END_SRC
>
>   * COMMENT B
>
> #+BEGIN_SRC elisp :noweb-ref B
> ;; B
> #+END_SRC
>
>   * COMMENT C
>
> #+BEGIN_SRC elisp :tangle yes
> ;; C
> #+END_SRC
>
> produces a file with A and B in it. Expected: Just A. Changing
>
> #+BEGIN_SRC elisp :noweb-ref B
> ;; B
> #+END_SRC
>
> to
>
> # #+BEGIN_SRC elisp :noweb-ref B
> # ;; B
> # #+END_SRC
>
> does yield the expected result.



[O] Non-printable Characters in Bug Reports

2019-09-21 Thread Sebastian Miele
My last bug report on this list was prepared with org-submit-bug-report
in an Emacs with a minimal configuration. From there I copy/pasted the
contents of the resulting mail buffer to an mu4e mail buffer in my fully
configured usual Emacs. Then I finished the bug report and hit send.

mu4e noticed non-printable characters in the mail and asked what to do
about it. The mail contained e.g. something like

  ("ftp" :follow
 #[257 "\301\300\302^CQ!\207" ["ftp" browse-url ":"] 5
 "\n\n(fn URL)"])

where ^C was not ^ followed by C, but the way Emacs dispays some
particular non-printing character.

I told mu4e to replace the characters. Apparently, all non-printable
characters have been replaced by ASCII periods.

Is there a best practice? Leave or replace?



[O] Bug: Comments and Hiding of Emphasis Markers [9.2.6 (release_9.2.6-539-g1fd07c @ /home/w/borg/emacs/org/lisp/)]

2019-09-21 Thread Sebastian Miele
An Org file like

  # -*- lexical-binding: t; -*-
  *bold*

is dispayed as

  # -- lexical-binding: t; --
  bold

where 'bold' is bold and '- lexical-binding: t; -' is not. Expected: In
comments emphasis marker characters are no emphasis markers and despite
hiding of emphasis markers, something like '# *a*' is still dispayed as
'# *a*'.


Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29
Package: Org mode version 9.2.6 (release_9.2.6-539-g1fd07c @ 
/home/w/borg/emacs/org/lisp/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-hide-emphasis-markers t
 org-occur-hook '(org-first-headline-recenter)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow eww :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
   ("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys")
   ("file+emacs") ("shell" :follow org-link--open-shell)
   ("news" :follow
#[257 "\301\300\302.Q!\207" ["news" browse-url ":"] 5
  "\n\n(fn URL)"]
)
   ("mailto" :follow
#[257 "\301\300\302.Q!\207" ["mailto" browse-url ":"]
  5 "\n\n(fn URL)"]
)
   ("https" :follow
#[257 "\301\300\302.Q!\207" ["https" browse-url ":"]
  5 "\n\n(fn URL)"]
)
   ("http" :follow
#[257 "\301\300\302.Q!\207" ["http" browse-url ":"] 5
  "\n\n(fn URL)"]
)
   ("ftp" :follow
#[257 "\301\300\302.Q!\207" ["ftp" browse-url ":"] 5
  "\n\n(fn URL)"]
)
   ("help" :follow org-link--open-elisp)
   ("file" :complete org-link-complete-file)
   ("elisp" :follow org-link--open-elisp)
   ("doi" :follow org-link--open-doi))
 org-link-elisp-confirm-function 'yes-or-no-p
 org-attach-id-to-path-function 'org-attach-id-folder-format
 )



Re: [O] Bug: COMMENT and noweb-ref

2019-09-16 Thread Sebastian Miele
GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) of 
2019-08-29
Org mode version 9.2.6 (release_9.2.6-538-g23113f @ 
/home/w/borg/emacs/org/lisp/)



[O] Bug: COMMENT and noweb-ref

2019-09-16 Thread Sebastian Miele
org-babel-tangle on

  * A

#+BEGIN_SRC elisp :tangle yes :noweb yes
;; A
<>
#+END_SRC

  * COMMENT B

#+BEGIN_SRC elisp :noweb-ref B
;; B
#+END_SRC

  * COMMENT C

#+BEGIN_SRC elisp :tangle yes
;; C
#+END_SRC

produces a file with A and B in it. Expected: Just A. Changing

#+BEGIN_SRC elisp :noweb-ref B
;; B
#+END_SRC

to

# #+BEGIN_SRC elisp :noweb-ref B
# ;; B
# #+END_SRC

does yield the expected result.



[O] [PATCH] org-manual: Fix typo

2019-04-24 Thread Sebastian Miele
* doc/org-manual.org (Footnotes): Fix typo.
---
 doc/org-manual.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index cf58f75b4..3c16edc4a 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21473,7 +21473,7 @@ through ~word-wrap~.
 
 [fn:149] Also see the variable ~org-adapt-indentation~.
 
-[fn:150] Because =LEVEL=2= has 3 stars, =LEVEL=3= has 4 stars, and so
+[fn:150] Because =LEVEL=2= has 3 stars, =LEVEL=3= has 5 stars, and so
 on.
 
 [fn:151] For a server to host files, consider using a WebDAV server,
-- 
2.21.0




[O] [PATCH] org-manual: Minor fixes

2019-04-17 Thread Sebastian Miele
* doc/org-manual.org (Motion): Fix the names of the four functions
  bound to C-c C-n, C-c C-p, C-c C-f, and C-c C-b.
---
 doc/org-manual.org | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b818b4bae..95f35a233 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -612,25 +612,25 @@ invisible edits and process them.
 
 The following commands jump to other headlines in the buffer.
 
-- {{{kbd(C-c C-n)}}} (~outline-next-visible-heading~) ::
+- {{{kbd(C-c C-n)}}} (~org-next-visible-heading~) ::
 
   #+kindex: C-c C-n
   #+findex: outline-next-visible-heading
   Next heading.
 
-- {{{kbd(C-c C-p)}}} (~outline-previous-visible-heading~) ::
+- {{{kbd(C-c C-p)}}} (~org-previous-visible-heading~) ::
 
   #+kindex: C-c C-p
   #+findex: outline-previous-visible-heading
   Previous heading.
 
-- {{{kbd(C-c C-f)}}} (~org-forward-same-level~) ::
+- {{{kbd(C-c C-f)}}} (~org-forward-heading-same-level~) ::
 
   #+kindex: C-c C-f
   #+findex: org-forward-same-level
   Next heading same level.
 
-- {{{kbd(C-c C-b)}}} (~org-backward-same-level~) ::
+- {{{kbd(C-c C-b)}}} (~org-backward-heading-same-level~) ::
 
   #+kindex: C-c C-b
   #+findex: org-backward-same-level
-- 
2.21.0




Re: [O] [PATCH] ob-core: Add edit-prep in org-babel-make-language-alias

2019-03-19 Thread Sebastian Miele


Nicolas Goaziou  writes:
> Could you provide a commit message for your patch?

* lisp/ob-core.el (org-babel-make-language-alias): Add edit-prep to
  the list of defalias'ed functions.
---
 lisp/ob-core.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 02efa1dc9..7591e99ca 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3135,7 +3135,8 @@ after the babel API for OLD-type source blocks is fully 
defined.
 Callers of this function will probably want to add an entry to
 `org-src-lang-modes' as well."
   (dolist (fn '("execute" "expand-body" "prep-session"
-   "variable-assignments" "load-session"))
+   "variable-assignments" "load-session"
+   "edit-prep"))
 (let ((sym (intern-soft (concat "org-babel-" fn ":" old
   (when (and sym (fboundp sym))
(defalias (intern (concat "org-babel-" fn ":" new)) sym
-- 
2.21.0




[O] [PATCH] ob-core: Add edit-prep in org-babel-make-language-alias

2019-03-17 Thread Sebastian Miele
---
 lisp/ob-core.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index fbeb46bb0..8168328de 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3135,7 +3135,8 @@ after the babel API for OLD-type source blocks is fully 
defined.
 Callers of this function will probably want to add an entry to
 `org-src-lang-modes' as well."
   (dolist (fn '("execute" "expand-body" "prep-session"
-   "variable-assignments" "load-session"))
+   "variable-assignments" "load-session"
+   "edit-prep"))
 (let ((sym (intern-soft (concat "org-babel-" fn ":" old
   (when (and sym (fboundp sym))
(defalias (intern (concat "org-babel-" fn ":" new)) sym
-- 
2.21.0




Re: [O] [PATCH 2/2] test-ob-emacs-lisp: Test :lexical src block header argument

2019-03-15 Thread Sebastian Miele


Nicolas Goaziou  writes:

> However, from experience, having to fix a regression when your only
> indication comes from a test you do not fully understand is a pain. To
> see what I mean, have a look at tests in
> "test-ob-header-arg-defaults.el" and imagine one of them fails…

After looking into test-ob-header-arg-defaults.el and its accompanying
Org file for two hours I still do not understand everything that's going
on there. You are right. And I now have a solid desire and strategy to
circumnavigate the production of such problems in the future. Thank you
for the input.

Best wishes!



Re: [O] [PATCH 2/2] test-ob-emacs-lisp: Test :lexical src block header argument

2019-03-14 Thread Sebastian Miele
Nicolas Goaziou  writes:

> [...]
>
> 
> However, your tests are very convoluted. It is better than no test, but
> if, unfortunately, one of them fail in some distant future, it may take
> more time understanding what happens in the test than actually fixing
> the bug.
>
> Would you mind rewriting them with simple macros like, e.g.,
> `org-test-with-temp-text', and use as little helper functions as
> possible? IMO, code repetition in tests is not a problem.
> 

After some initial tooth-grinding, I did rewrite them, and actually like
the result more than the previous version. Thank you for the suggestion!

Here is the updated patch:

* testing/lisp/test-ob-emacs-lisp.el
  (ob-emacs-lisp/dynamic-lexical-execute,
  ob-emacs-lisp/dynamic-lexical-edit): Add tests that check the
  correct handling of the :lexical header argument when executing
  source blocks and when creating editing buffers for source blocks.
---
 testing/lisp/test-ob-emacs-lisp.el | 89 ++
 1 file changed, 89 insertions(+)

diff --git a/testing/lisp/test-ob-emacs-lisp.el 
b/testing/lisp/test-ob-emacs-lisp.el
index 078cad988..24a373f86 100644
--- a/testing/lisp/test-ob-emacs-lisp.el
+++ b/testing/lisp/test-ob-emacs-lisp.el
@@ -76,6 +76,95 @@
  (buffer-substring-no-properties (line-beginning-position 2)
  (line-end-position 2))
 
+(ert-deftest ob-emacs-lisp/dynamic-lexical-execute ()
+  (cl-flet ((execute (text)
+  (org-test-with-temp-text-in-file text
+   (org-babel-next-src-block)
+   (org-babel-execute-maybe)
+   (re-search-forward "results" nil t)
+   (re-search-forward ": " nil t)
+   (buffer-substring-no-properties (point) (point-at-eol)
+
+(should (string= "dynamic" (execute "
+#+begin_src emacs-lisp :lexical no :results verbatim
+(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x
+#+end_src")))
+
+(should (string= "lexical" (execute "
+#+begin_src emacs-lisp :lexical yes :results verbatim
+(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x
+#+end_src")))
+
+(should (string= "dynamic" (let ((x 'dynamic)) (execute "
+#+begin_src emacs-lisp :lexical no :results verbatim
+x
+#+end_src"
+
+(should (string= "lexical" (let ((x 'dynamic)) (execute "
+#+begin_src emacs-lisp :lexical '((x . lexical)) :results verbatim
+x
+#+end_src"
+
+;; Src block execution uses `eval'. As of 2019-02-26, `eval' does
+;; not dynamically bind `lexical-binding' to the value of its
+;; LEXICAL parameter. Hence, (eval 'lexical-binding LEXICAL)
+;; evaluates to the same value that just `lexical-binding'
+;; evaluates to, even if LEXICAL is different. So tests like the
+;; following do not work here:
+;;
+;; (should (string= "t" (execute "
+;; #+begin_src emacs-lisp :lexical yes :results verbatim
+;; lexical-binding
+;; #+end_src")))
+;;
+;; However, the corresponding test in
+;; `ob-emacs-lisp/dynamic-lexical-edit' does work.
+))
+
+(ert-deftest ob-emacs-lisp/dynamic-lexical-edit ()
+  (cl-flet ((execute (text)
+  (org-test-with-temp-text-in-file text
+   (org-babel-next-src-block)
+   (org-edit-src-code)
+   (goto-char (point-max))
+   (prog1 (eval-last-sexp 0)
+ (org-edit-src-exit)
+
+(should (eq 'dynamic (execute "
+#+begin_src emacs-lisp :lexical no :results verbatim
+(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x
+#+end_src")))
+
+(should (eq 'lexical (execute "
+#+begin_src emacs-lisp :lexical yes :results verbatim
+(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x
+#+end_src")))
+
+(should (eq 'dynamic (let ((x 'dynamic)) (execute "
+#+begin_src emacs-lisp :lexical no :results verbatim
+x
+#+end_src"
+
+(should (eq 'lexical (let ((x 'dynamic)) (execute "
+#+begin_src emacs-lisp :lexical '((x . lexical)) :results verbatim
+x
+#+end_src"
+
+(should (equal nil (execute "
+#+begin_src emacs-lisp :lexical no :results verbatim
+lexical-binding
+#+end_src")))
+
+(should (equal t (execute "
+#+begin_src emacs-lisp :lexical yes :results verbatim
+lexical-binding
+#+end_src")))
+
+(should (equal '((x . 0)) (execute "
+#+begin_src emacs-lisp :lexical '((x . 0)) :results verbatim
+lexical-binding
+#+end_src")
+
 (provide 'test-ob-emacs-lisp)
 
  ;;; test-ob-emacs-lisp.el ends here
-- 
2.21.0




[O] [PATCH 1/2] ob-emacs-lisp: Set `lexical-binding' in edit buffers

2019-03-14 Thread Sebastian Miele
* lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp,
  org-babel-emacs-lisp-lexical): Factor out the conversion of the
  :lexical source block argument to a form that is appropriate for
  `lexical-binding' and the LEXICAL argument to `eval'.

* lisp/ob-emacs-lisp.el (org-babel-edit-prep:emacs-lisp): Set
  `lexical-binding'.

* lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp):
  Update docstring.

* etc/ORG-NEWS: Create entry about this under Miscellaneous.
---
 etc/ORG-NEWS  |  6 ++
 lisp/ob-emacs-lisp.el | 24 
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 039ad4c69..15af28bfd 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -160,6 +160,8 @@ dynamic block in ~org-dynamic-block-alist~.
 *** ~org-table-cell-down~
 *** ~org-table-cell-left~
 *** ~org-table-cell-right~
+*** ~org-babel-emacs-lisp-lexical~
+*** ~org-babel-edit-prep:emacs-lisp~
 ** Removed functions
 *** ~org-babel-set-current-result-hash~
 
@@ -193,6 +195,10 @@ The ~:mkdirp~ header argument used to only work for 
~:tangle~ tangle
 files. Now ~:mkdirp~ works for ~:dir~ too. This is more convenient for
 specify default directory and with ~:file~ header argument.
 
+*** ob-emacs-lisp sets ~lexical-binding~ in Org edit buffers
+When editing an Elisp src block, the editing buffer's
+~lexical-binding~ is set according to the src block's =:lexical=
+parameter.
 * Version 9.2
 ** Incompatible changes
 *** Removal of OrgStruct mode mode and radio lists
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index cd86f4a20..ab7dac879 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -43,7 +43,8 @@
 A value of \"yes\" or t causes source blocks to be eval'd using
 lexical scoping.  It can also be an alist mapping symbols to
 their value.  It is used as the optional LEXICAL argument to
-`eval', which see.")
+`eval', which see.  And it is used as the value for
+`lexical-binding' in buffers created by `org-edit-src-code'.")
 
 (defun org-babel-expand-body:emacs-lisp (body params)
   "Expand BODY according to PARAMS, return the expanded body."
@@ -71,9 +72,7 @@ their value.  It is used as the optional LEXICAL argument to
   (member "pp" result-params))
   (concat "(pp " body ")")
 body))
-(if (listp lexical)
-lexical
-  (member lexical '("yes" "t"))
+(org-babel-emacs-lisp-lexical lexical
   (org-babel-result-cond result-params
(let ((print-level nil)
   (print-length nil))
@@ -88,6 +87,23 @@ their value.  It is used as the optional LEXICAL argument to
  (org-babel-pick-name (cdr (assq :rowname-names params))
   (cdr (assq :rownames params
 
+(defun org-babel-emacs-lisp-lexical (lexical)
+  "Interpret :lexical source block argument.
+Convert LEXICAL into the form appropriate for `lexical-binding'
+and the LEXICAL argument to `eval'."
+  (if (listp lexical)
+  lexical
+(not (null (member lexical '("yes" "t"))
+
+(defun org-babel-edit-prep:emacs-lisp (info)
+  "Set `lexical-binding' in Org edit buffer.
+Set `lexical-binding' in Org edit buffer according to the
+corresponding :lexical source block argument."
+  (setq lexical-binding
+(org-babel-emacs-lisp-lexical
+ (org-babel-read
+  (cdr (assq :lexical (nth 2 info)))
+
 (org-babel-make-language-alias "elisp" "emacs-lisp")
 
 (provide 'ob-emacs-lisp)
-- 
2.21.0




[O] [PATCH 2/2] test-ob-emacs-lisp: Test :lexical src block header argument

2019-03-14 Thread Sebastian Miele
* testing/lisp/test-ob-emacs-lisp.el
  (test-ob-emacs-lisp-dynamic-lexical-text,
  test-ob-emacs-lisp-dynamic-lexical-expr,
  ob-emacs-lisp/dynamic-lexical-execute,
  ob-emacs-lisp/dynamic-lexical-edit): Add tests that check the
  correct handling of the :lexical header argument when executing
  source blocks and when creating editing buffers for source blocks.
---
 testing/lisp/test-ob-emacs-lisp.el | 86 ++
 1 file changed, 86 insertions(+)

diff --git a/testing/lisp/test-ob-emacs-lisp.el 
b/testing/lisp/test-ob-emacs-lisp.el
index 078cad988..a48f0c7dd 100644
--- a/testing/lisp/test-ob-emacs-lisp.el
+++ b/testing/lisp/test-ob-emacs-lisp.el
@@ -76,6 +76,92 @@
  (buffer-substring-no-properties (line-beginning-position 2)
  (line-end-position 2))
 
+(defun test-ob-emacs-lisp-dynamic-lexical-text (expr lexical)
+  (concat "\n"
+ "#+begin_src emacs-lisp :lexical " lexical " :results verbatim\n"
+ (format "%S" expr) "\n"
+ "#+end_src"))
+
+(defvar test-ob-emacs-lisp-dynamic-lexical-expr
+  '(let ((x 'dynamic))
+ (funcall
+  (let ((x 'lexical))
+   (lambda () x)
+
+(ert-deftest ob-emacs-lisp/dynamic-lexical-execute ()
+  (cl-flet ((execute (text)
+  (org-test-with-temp-text-in-file text
+   (org-babel-next-src-block)
+   (org-babel-execute-maybe)
+   (re-search-forward "results" nil t)
+   (re-search-forward ": " nil t)
+   (buffer-substring-no-properties (point) (point-at-eol)
+;;
+(cl-flet ((text (lexical)
+   (test-ob-emacs-lisp-dynamic-lexical-text
+test-ob-emacs-lisp-dynamic-lexical-expr
+lexical)))
+  (should (string= "dynamic" (execute (text "no" 
+  (should (string= "lexical" (execute (text "yes")
+;;
+(cl-flet ((text (lexical)
+   (test-ob-emacs-lisp-dynamic-lexical-text
+'x
+lexical)))
+  (should (string= "dynamic" (let ((x 'dynamic))
+  (execute (text "no")
+  (should (string= "lexical" (execute (text "'((x . lexical))")
+;;
+;; Src block execution uses `eval'. `eval' does not dynamically
+;; bind `lexical-binding' to the value of its LEXICAL
+;; parameter. Hence, (eval 'lexical-binding LEXICAL) evaluates to
+;; the same value that just `lexical-binding' evaluates to, no
+;; matter what is given as the LEXICAL parameter to eval. So the
+;; following does not work as intended:
+;;
+;;(cl-flet ((text (lexical)
+;; (test-ob-emacs-lisp-dynamic-lexical-text
+;;  'lexical-binding
+;;  lexical)))
+;;  (should (string= "nil"   (execute (text "no"
+;;  (should (string= "t" (execute (text "yes"   
+;;  (should (string= "((x . 0))" (execute (text "'((x . 0))")
+))
+
+(ert-deftest ob-emacs-lisp/dynamic-lexical-edit ()
+  (cl-flet ((execute (text)
+  (org-test-with-temp-text-in-file text
+   (org-babel-next-src-block)
+   (org-edit-src-code)
+   (goto-char (point-max))
+   (prog1 (eval-last-sexp 0)
+ (org-edit-src-exit)
+;;
+(cl-flet ((text (lexical)
+   (test-ob-emacs-lisp-dynamic-lexical-text
+test-ob-emacs-lisp-dynamic-lexical-expr
+lexical)))
+  (should (eq 'dynamic (execute (text "no" 
+  (should (eq 'lexical (execute (text "yes")
+;;
+(cl-flet ((text (lexical)
+   (test-ob-emacs-lisp-dynamic-lexical-text
+'x
+lexical)))
+  (should (eq 'dynamic (let ((x 'dynamic))
+(execute (text "no")
+  (should (eq 'lexical (execute (text "'((x . lexical))")
+;;
+(cl-flet ((text (lexical)
+   (test-ob-emacs-lisp-dynamic-lexical-text
+'lexical-binding
+lexical)))
+  (should (equal nil(execute (text "no"
+  (should (equal t  (execute (text "yes"   
+  (should (equal '((x . 0)) (execute (text "'((x . 0))")
+))
+
+
 (provide 'test-ob-emacs-lisp)
 
  ;;; test-ob-emacs-lisp.el ends here
-- 
2.21.0




Re: [O] [PATCH] ob-emacs-lisp: Set `lexical-binding' in source editing buffers

2019-02-22 Thread Sebastian Miele
On Tue, Feb 12, 2019 at 9:41 AM Nicolas Goaziou  wrote:
>
> [...]
>
> Thank you! Some comments follow.
>
> > -`eval', which see.")
> > +`eval', which see. And it is used as the value for
> > +`lexical-binding' in buffers created by `org-edit-src-code'.")
>
> You need to add two spaces after full stops.
>
> > +(defun org-babel-emacs-lisp-lexical (lexical)
> > +  "Convert :lexical source block argument LEXICAL into the form
> > +appropriate for `lexical-binding' and the LEXICAL argument to
> > +`eval'."
>
> The first sentence in a docstring needs to fit on a single line.
>
> Could you add a test or two for that feature? Could you also add an
> ORG-NEWS entry?

I did all the changes you suggested. I will send the new patch after I
managed to setup and get acquainted with mail in Emacs (mu4e).



[O] [PATCH] ob-emacs-lisp: Set `lexical-binding' in source editing buffers

2019-02-10 Thread Sebastian Miele
* lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp,
  org-babel-emacs-lisp-lexical): Factor out the conversion of the
  :lexical source block argument to a form that is appropriate for
  `lexical-binding' and the LEXICAL argument to `eval'.

* lisp/ob-emacs-lisp.el (org-babel-edit-prep:emacs-lisp): Set
  `lexical-binding'.

* lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp):
  Update docstring.

TINYCHANGE
---
 lisp/ob-emacs-lisp.el | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index cd86f4a20..17952069e 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -43,7 +43,8 @@
 A value of \"yes\" or t causes source blocks to be eval'd using
 lexical scoping.  It can also be an alist mapping symbols to
 their value.  It is used as the optional LEXICAL argument to
-`eval', which see.")
+`eval', which see. And it is used as the value for
+`lexical-binding' in buffers created by `org-edit-src-code'.")

 (defun org-babel-expand-body:emacs-lisp (body params)
   "Expand BODY according to PARAMS, return the expanded body."
@@ -71,9 +72,7 @@ their value.  It is used as the optional LEXICAL argument to
(member "pp" result-params))
(concat "(pp " body ")")
  body))
- (if (listp lexical)
- lexical
-   (member lexical '("yes" "t"))
+ (org-babel-emacs-lisp-lexical lexical
   (org-babel-result-cond result-params
 (let ((print-level nil)
   (print-length nil))
@@ -88,6 +87,22 @@ their value.  It is used as the optional LEXICAL argument to
  (org-babel-pick-name (cdr (assq :rowname-names params))
   (cdr (assq :rownames params

+(defun org-babel-emacs-lisp-lexical (lexical)
+  "Convert :lexical source block argument LEXICAL into the form
+appropriate for `lexical-binding' and the LEXICAL argument to
+`eval'."
+  (if (listp lexical)
+  lexical
+(not (null (member lexical '("yes" "t"))
+
+(defun org-babel-edit-prep:emacs-lisp (info)
+  "Set `lexical-binding' according to :lexical source block
+argument."
+  (setq lexical-binding
+(org-babel-emacs-lisp-lexical
+ (org-babel-read
+  (cdr (assq :lexical (nth 2 info)))
+
 (org-babel-make-language-alias "elisp" "emacs-lisp")

 (provide 'ob-emacs-lisp)
-- 
2.20.1