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
* 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
* 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
---
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.
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
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
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
* 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
* 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
---
* 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
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/)
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:
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
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
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
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
>
> #+
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-tan
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
>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
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 C
* 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
* 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
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
.
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]
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, whe
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
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
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
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.
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 Hea
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
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:
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
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
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:
>
>
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 |
> |-|
> |
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?
>
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.
&
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
> &quo
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
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.
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.
>
> >
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
>
>
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
&g
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
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.
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
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." Thi
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.
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
*
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 o
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
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
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
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 fontificatio
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
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
> From: Eli Zaretskii
> Date: Tue, 2023-09-05 14:54 +0300
>
> […]
>
> So we could decide that this command needs to become smarter when the
> visual line includes invisible text. That is, improve the command
> without making any Org-specific changes anywhere. Patches to that
> effect are
> From: Eli Zaretskii
> Date: Wed, 2023-09-06 15:16 +0300
>
>> From: Ihor Radchenko
>> Date: Wed, 06 Sep 2023 08:23:23 +
>>
>> Eli Zaretskii writes:
>>
>> >> The following would do it. I think I tested it rather thoroughly.
>> >> During testing I found another bug that is addressed by
> From: Eli Zaretskii
> Date: Thu, 2023-09-07 13:19 +0300
>
>> From: Ihor Radchenko
>> Cc: i...@whxvd.name, 65...@debbugs.gnu.org, emacs-orgmode@gnu.org
>> Date: Thu, 07 Sep 2023 10:00:49 +
>>
>> Eli Zaretskii writes:
>>
>> > Then perhaps just a special value for buffer-invisibility-spec,
In an emacs -Q, create an Org buffer with the following contents:
--8<---cut here---start->8---
* AB
** C
--8<---cut here---end--->8---
Fold the subtree under the heading AB, so that only a single line is
displayed (ending
> From: Ihor Radchenko
> Date: Wed, 2023-09-06 08:30 +
>
> Eli Zaretskii writes:
>
>>> It would also make sense to group the two edits together via
>>> `combine-after-change-calls', although a more universal way to know that
>>> certain edits are a part of the same known command (even when
62 matches
Mail list logo
