> 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,
> 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 ca
> 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 the
> 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 welcome
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 in
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
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 curre
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
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 an
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:
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.
Ar
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 dete
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 Or
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 co
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!
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 alre
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.
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
#+BE
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
>
>
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,
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.
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
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
> &qu
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 buff
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
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 entri
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 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.
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 v
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 star
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
>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
nk 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]
* 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.
* 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
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?
> Cu
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-ar
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
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
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,
>
> 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 kno
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 |
> |-|
> |
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:
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 current
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
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
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
>
> #+
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 lik
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: Ju
* 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-w
* 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/d
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
---
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
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
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
* 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-lis
* 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
so
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 st
* 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-lis
62 matches
Mail list logo
