can I profile this, or does anyone have a guess of what could be causing it?
Thank you!
Sebastian
.
Removing it solves my issue:
(org-link-set-parameters "id" :follow #'org-roam-id-open)
Thanks!
Sebastian Wålinder writes:
> I have been reading through the code, and it appears that org-id doesn't
> store the actual positions of ids within all files.
>
> It's instead fetch
I have been reading through the code, and it appears that org-id doesn't store
the actual positions of ids within all files.
It's instead fetched every time the link is accessed. There must be something
strange going on with the org cache causing this issue.
Sebastian Wålinder writes
Hello!
I often use org-id to create persistent links to headings like this:
* Foo
:PROPERTIES:
:ID: BAR
:END:
[[BAR][Link]]
However, after inserting a line above foo, following the link BAR will take me
to the wrong line, because the org-id database hasn't been updated with the
> 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
> 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: 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
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
/q8adc2srnbipkahbwffwg006d09yk02g-emacs-git-20230618.0/share/emacs/30.0.50/lisp/org/)`
Thanks!
Sebastian
, the org element cache takes 100 mb, and so each
new indirect buffer consumes an additional 100 mbs of memory.
I also wonder if this means the caching is performed by each indirect buffer
independently, and doesn't carry over.
Thoughts?
Thanks,
Sebastian
te a new RESULTS tag,
and insert 3 in there.
Thoughts?
Best,
Sebastian
On Mon, 27 Dec 2021 13:28:08 +,
Juan Manuel Macías wrote:
> Sebastian P. Luque writes:
>> Thank you, Juan. Unfortunately, there is a price for this solution
>> as it is now impossible to name and refer to this segment as usual:
> I see. Have you tried the option with
On Mon, 27 Dec 2021 07:41:59 +,
Juan Manuel Macías wrote:
[...]
> If you use the caption package (https://www.ctan.org/pkg/caption), you
> can indicate in each figure the width of the caption. In this case,
> you would have to introduce the code using raw latex via the
> `:caption'
I recently updated my packages and after the update the clock tables are
not working anymore. I reran an report from june and here too the
matching didn't work anymore.
#+BEGIN: clocktable :scope file :maxlevel 4 :match "traj"
#+CAPTION: Clock summary at [2021-08-06 Fr 08:48]
| Headline
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
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 o
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
*
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
with the developer tools open still).
This issue is causing my own JavaScript code to not run (as it is
inserted before the end of the tag).
Thanks in advance for the eventual fix.
Kind regards,
Sebastian Berntsson
Emacs : GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.28, cairo version
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
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
code or verbatim objects are
hidden, when org-hide-emphasis-markers is t.
Best wishes
Sebastian
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
ch form
(progn (goto-char (match-beginning 0)) (match-end 0))
;; Post-match form
(goto-char (match-end 0))
;; face for this match
(0 font-lock-variable-name-face t))
Commenting out this code snippet, the fontfying / HTML-export problem goes
away.
Cheers,
sebastian
On Tue, Nov 3, 2020 at
Hi Jack,
I have cloned the git master. Running without configuration ("make
vanilla"), emacs correctly fontifies the source block and it also gets
exported to HTML. It seems that it is a configuration problem. Sorry for
not double checking first!
Many thanks for your help!
Cheers,
Hi Jack,
thanks for replying!
The error does not happen using "emacs -q" (built-in package: org 9.3). I
haven't tried with the git version yet. i will and let you know.
Cheers,
Sebastian
On Sun, Nov 1, 2020 at 9:19 PM Jack Kamm wrote:
> Hi Sebastian --
>
> >
Hi,
I am using emacs 27.1 and org-plus-contrib 20201026.
I am having problems with the fontification of python and ipython source
blocks when the code contains curly brackets "{}" (other course blocks are
ok). For instance, the following snippet
#+BEGIN_SRC python :results drawer
import
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
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.
>
> >
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
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
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.
&
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
r
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
y :noweb-ref it is not possible to do something like
<>. Only <>, i.e. plain inclusion, is possible.
Best wishes
Sebastian
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 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
, 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
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
.
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]
* 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
* 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
eading
> ** 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
IN_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
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
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 usin
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
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 |
> |-|
> |
ND:
#+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
.
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
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
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
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:
* 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
* 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
---
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
---
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, 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
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
* 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
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
* 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
On Sat, 10 Nov 2018 08:30:50 +0100,
Nicolas Goaziou wrote:
[...]
> I cannot reproduce your error. You may want to upgrade Org.
I'm already using the latest Org from Elpa (9.1.14), and get the error
with:
$ emacs -q -l emacs_pkg_init.el
╭─ [ emacs_pkg_init.el ]
│ (setq package-archives
│
Nicolas Goaziou writes:
AFAICT, it still doesn't work. I get the exact same result as
detailed above.
That’s odd, I can’t reproduce your example anymore. Is your Emacs
session still the same one as earlier today? While implementing
the patch I had to C-0 M-x org-refile occasionally,
BTW this reminds me of some issues I ran into on master a while
back. When a refile target has a headline containing a slash,
there are some issues:
1. When an existing headline contains a slash, completing-read
will display the target as »A\/Slash«. However, when entering the
string
Hello Nicolas,
Nicolas Goaziou writes:
I still cannot make it work property.
With the following document:
--8<---cut
here---start->8---
* Foo
** Bar
* Foo2
--8<---cut
here---end--->8---
Trying to refile "Foo2"
* org.el (org--refile-new-path): Add.
(org-refile): Use it.
(org-refile-new-child): Support creating new root nodes.
* test-org.el (test-org/org-refile): Add test.
While ‘org-refile’ currently supports creating new headlines when
refiling, only one single headline can be created this way. For
* org.el (org--refile-new-path): Add.
(org-refile): Use it.
(org-refile-new-child): Support creating new root nodes.
* test-org.el (test-org/org-refile): Add test.
While ‘org-refile’ currently supports creating new headlines when
refiling, only one single headline can be created this way. For
Sebastian Reuße writes:
+ (if (and (string-match "\\`\\(.*\\)/\\([^/]+\\)\\'" answ)
I realize this is overly restrictive if you don’t have
‘org-refile-use-outline-path’ set to ‘file’ and want to refile
under a newly created root headline. AFAICT this would also have
bee
Hello Nicolas,
Nicolas Goaziou writes:
Compiling your patch generates the following warnings.
org.el:11417:1:Warning: Unused lexical variable ‘parent’
org.el:11417:1:Warning: Unused lexical variable ‘child’
org.el:11417:1:Warning: Unused lexical variable
‘parent-target’
* org.el (org--refile-new-path): Add.
(org-refile): Use it.
(org-refile-new-child): Make new nodes more compact.
* test-org.el (test-org/org-refile): Add test.
While ‘org-refile’ currently supports creating new headlines when
refiling, only one single headline can be created this way. For
* org.el (org--refile-new-path): Add.
(org-refile): Use it.
(org-refile-new-child): Make new nodes more compact.
* test-org.el (test-org/org-refile): Add test.
While ‘org-refile’ currently supports creating new headlines when
refiling, only one single headline can be created this way. For
Heikki Lehvaslaiho writes:
> (string-collate-lessp "ß" "ssa" "de_DE.utf-8") ; nil
> (string-lessp "ß" "ssa") ; nil
This shows us that your Emacs installation does not support alphabetic
sorting at all, regardless of case, and instead only sorts
lexicographically (i.e.,
Heikki Lehvaslaiho writes:
> x86_64-apple-darwin14.5.0
Looking at the C source of ‘string-collate-lessp’ (src/fns.c), it looks
like there exists a case where Emacs itself will fall back on
‘string-lessp’ even when ‘string-collate-lessp’ is invoked.
#else /* !__STDC_ISO_10646__,
; "X" "de_DE.utf-8" t)
(string-collate-lessp "a" "x" "fi_FI.utf-8" nil)
(string-collate-lessp "a" "X" "fi_FI.utf-8" t)
Kind regards,
Sebastian
--
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay
On Wed, 11 Apr 2018 13:17:49 +0200,
Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Hello, "Sebastian P. Luque" <splu...@gmail.com> writes:
>> When `org-startup-align-all-tables' is t, then editing the cookie
>> in a table causes subsequent tabbing insid
Hello,
When `org-startup-align-all-tables' is t, then editing the cookie in
a table causes subsequent tabbing inside the table to throw the
following trace:
------
Debugger entered--Lisp error: (args-out-of-range #("abcde" 0 1
Hello Nicolas,
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Sebastian Reuße <s...@wirrsal.net> writes:
>> I was also wondering if it might make sense to tweak
>> ‘org-complex-heading-regexp’ so that the respective capture group
>> captures an empty string.
* test-org.el (test-org/sort-entries): Test with empty headings.
---
testing/lisp/test-org.el | 10 ++
1 file changed, 10 insertions(+)
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 33769aafa..8c98fce4d 100644
--- a/testing/lisp/test-org.el
+++
So, I’ve noticed that when sorting a subtree (alphabetically or numerically),
‘org-sort-entries’ will raise an error arising from the call to
‘org-sort-remove-invisible’ (lines 8761 and 8766 in bc7b24d0d).
I’m following up with a test. The error is triggered by the capture group in
* org.el (org-sort-entries): Guard against empty headings when sorting
alphabetically, numerically.
Due to how ‘org-complex-heading-regexp’ is defined, the title capture group
currently returns nil in empty headings, which we don’t want to pass on to
‘org-sort-remove-invisible’.
---
lisp/org.el
Sorry, I committed this one without using the compat-shimmed version of
‘string-collate-lessp’. Amended.
Kind regards,
SR
--
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay
* org.el (org-string<): Add.
(org-op-to-function): Use it.
(org-string> etc.): Use collated comparison.
Cf. commit 551d2f1fe.
---
lisp/org.el | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index ac1ad3c75..24923ad4f 100644
--- a/lisp/org.el
* test-org-list.el (test-org-list/sort): Take case-sensitive
vs. insensitive sorting into account.
---
testing/lisp/test-org-list.el | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/testing/lisp/test-org-list.el
* test-org-table.el (test-org-table/sort-lines): Fix and improve
testcase.
Sorting and reversing «a C b» should result in «C b a», not in «b a
C». This test did not fail previously only because
org-table-sort-lines had an issue whereby sorts were always
case-sensitive.
---
1 - 100 of 1015 matches
Mail list logo
