[feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

Over the years of using Org I often have a need to add a short note
about how to proceed with some task:

* REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome lists 
about all kinds of interesting topics :BOOKMARK:
:PROPERTIES:
:CREATED: [2020-03-15 Sun 18:59]
:Source: https://github.com/sindresorhus/awesome
:END:
:LOGBOOK:
CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
- Refiled on [2020-03-16 Mon 23:59]
:END:

In the above example, the short note is "check again, subscribe".
The note is not fixed, but changes as I progress with completing the
task.

This is even more useful for delegated or HOLD tasks where I often need
to add a short note why the task is delegated or put on hold:

** HOLD Finish the text prop org-mode | make babel support org file links in 
header args (:file or :dir) 
[[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri] 
CuNbARBshearstrength]] :HOLD:
:PROPERTIES:
:CREATED: [2020-07-20 Mon 16:53]
:SHOWFROMDATE: 2020-08-15
:END:
:LOGBOOK:
- State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
  Finish the text prop org-mode
- Refiled on [2020-07-20 Mon 17:15]
CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
:END:

Seeing this note directly in the headline without a need to dig into the
task body / LOGBOOK drawer is really handy.

In this last example, I had to duplicate the note taken using built-in
note mechanism into headline, which was inconvenient. It would be handy
if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
the headline to show the last note taken for this task. Then, I could
easily see the reason why the task is blocked or what I am supposed to
do with the task right in agenda view or in the folded headline.
Something like the following

** HOLD [!] make babel support org... :HOLD:
:LOGBOOK:
- State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
  Finish the text prop org-mode
- Refiled on [2020-07-20 Mon 17:15]
CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
:END:

The cookie would be replaced by the last note text, according to
user-defined format (say, "[%s] |"):

** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
:LOGBOOK:
- State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
  Finish the text prop org-mode
- Refiled on [2020-07-20 Mon 17:15]
CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
:END:

What do you think?

Best,
Ihor

Re: Problem in 9.3: (next-error) broken

[Kyle Meyer]

Tory S. Anderson writes:

> I discovered teh cause of this error is that new versions of orgmode
> sets next-error-function and so breaks the. I've added a hook to clear
> this in orgmode and I can navigate my grep properly again.

I'm not having any luck triggering the issue, but in any case there
seems to be something missing from that explanation.  Org has set
next-error-function to org-occur-next-match since dd2346134 (Implement
next-error and previous-error functionality for sparse trees,
2011-01-06), and the definition of org-occur-next-match hasn't changed
substantially since.

Re: [PATCH] Re: Re: org-forward-heading-same-level and the invisible-ok argument

[Ihor Radchenko]

> The issue with that is that it reintroduces the thing the patch is
> trying to fix, as it considers any partially invisible line as fully
> invisible (while the opposite should be the case).

Oops. Sorry, I wrote that function without much thinking.
Indeed, it should be

(defun org--line-visible-p ()
  "Return t if the current line is partially visible."
  (save-restriction
(narrow-to-region (line-beginning-position) (1- (line-end-position)))
(let ((visible nil)
  (p (point-min)))
  (while (and (not visible)
  (< p (point-max)))
(when (not (org-invisible-p p))
  (setq visible t))
(setq p (next-single-char-property-change p 'invisible)))
  visible)))

> I also don't see
> much of a difference when profiling, unless I severely screwed up.  I
> just manually prepared a buffer with 10k invisible headings (each 83
> chars long) and plugged a visible one of the same level above and below
> the huge invisible block.  C-c C-f does take a second plus change in
> that case for both cases.

I also tested on one of my largest org files. There is not much
difference and your version should be acceptable. 

> which basically removes any relevant slowdown.
> But I'd really only recommend going that far if necessary, given it adds
> a random magic number.  Thoughts?

I do not think it will make much difference. Mapcar will anyway apply
#'org-invisible-p for all points at the headline (well, all, but 3
points). Probably, it is easier if you just use seq-every-p instead of
mapcar on (number-sequence max-pos min-pos -1). The result of
seq-every-p will be inverse of the currently used expression.

Best,
Ihor

D  writes:

>>> +(mapcar #'org-invisible-p
>>> +(number-sequence (line-beginning-position)
>>> + (1- (line-end-position)
>>
>> This is a bad idea. org--line-visible-p will be called for every single
>> invisible headline. If you check every single point at every single
>> invisible headline, it can be extremely slow.
>
> Hm, of course it would only check invisible headlines of the same level,
> thanks to the logic of the navigation command.  However, I do see the
> concern.
>
>> Better do something like below (or maybe even without narrow-to-region,
>> not sure if that may cause significant overhead):
>> 
>> (defun org--line-visible-p ()
>>   "Return t if the current line is partially visible."
>>   (save-restriction
>> (narrow-to-region (line-beginning-position) (1- (line-end-position)))
>> (let ((visible t)
>>(p (point-min)))
>>   (while (and visible (< p (point-max)))
>>  (when (org-invisible-p p)
>>   (setq visible nil))
>> (setq p (next-single-char-property-change p 'invisible)))
>>   visible)))
>
> The issue with that is that it reintroduces the thing the patch is
> trying to fix, as it considers any partially invisible line as fully
> invisible (while the opposite should be the case).  I also don't see
> much of a difference when profiling, unless I severely screwed up.  I
> just manually prepared a buffer with 10k invisible headings (each 83
> chars long) and plugged a visible one of the same level above and below
> the huge invisible block.  C-c C-f does take a second plus change in
> that case for both cases.
>
> The main issue is that a hot-circuit approach would only ever optimize
> navigating across many visible blocks, if we want a partially visible
> heading to be treated like a visible one (instead of an invisible one
> like it is at the moment).  However, we could use a similar hack as the
> original implementation and only check a couple of characters, if
> performance really is a concern there.  In that case, I think it would
> be best to check the *last* few characters (as it makes more sense that
> the stars at the beginning are hidden than the actual title at the end).
>  That would mean to replace the original implementation with something like
>
> (defun org--line-visible-p ()
>   "Return t if the current line is partially visible."
>   (let ((min-pos (max (line-beginning-position)
> (- (line-end-position) 3)))
>   (max-pos (1- (line-end-position
> (and
>  (memq nil
>  (mapcar #'org-invisible-p
>  (number-sequence min-pos max-pos)))
>  t)))
>
> which basically removes any relevant slowdown.
> But I'd really only recommend going that far if necessary, given it adds
> a random magic number.  Thoughts?
>
> Cheers,
> D.

Re: Bug: org-capture entry sometimes ends without newline, garbles next headline [9.3.6 (9.3.6-elpa @ /home/arne/Disy/.emacs.d/elpa/org-9.3.6/)]

[Kyle Meyer]

Dr. Arne Babenhauserheide writes:

> Sometimes when I use org-capture to create a new headline, that headline
> ends with a non-empty partial line that isn’t terminated by a newline.
>
> This causes the next headline to be corrupted, because the * is appended
> to the last line of the new entry.

I believe this issue has already been resolved on the master branch.
There have been a few bug reports and commits in this area; I think
6882478ca (capture: Fix org-capture-place-entry narrow bounds,
2020-05-29) is the most recent fix.

Default value and docstring of org-attach-store-link-p

[Ihor Radchenko]

The default value of org-attach-store-link-p is nil for now.
Would it make more sense to set it to something else (say, 'attach)?
I believe that 'attach or t would be better as a default.

Thoughts?

Also, the docstring does not mention that there may be several different
non-nil values. It is only reflected in the :type field of defcustom.

Best,
Ihor

Re: Help debugging R source code block output problem with :session

[Dylan Schwilk]

Hi Jack,

The patch does fix that issue -- but it introduces a different bug 
for code blocks with ~:session~: the R block now only produces 
output from the last statement evaluated.


#+begin_src R :results output :exports both :session
4.0 * 3.5
log(10)  # natural log
log10(10)
(3 + 1) * 5
3^-1
1/0
#+end_src

#+results:
: [1] Inf

Without the ~:session header~ the output is as it was before the 
patch:


#+results:
: [1] 14
: [1] 2.302585
: [1] 1
: [1] 20
: [1] 0.333
: [1] Inf


-Dylan

Re: Help debugging R source code block output problem with :session

[Jack Kamm]

Hi Dylan,

I'm able to reproduce your error. I think this same bug has been
previously reported at [1]. As discussed there, the reason is that
substrings ending in ">" get stripped out by
org-babel-comint-with-output because it thinks they are prompts (in
particular, they match comint-prompt-regexp).

I'm attaching a patch to solve the issue. It replaces
org-babel-comint-with-output, with an R call to capture.output. I think
this approach is simpler and more robust, since it doesn't need to do
any parsing to remove prompts or other unwanted outputs.

I haven't committed to ob-R.el before, so thought it would be best to
solicit feedback here before merging this in.

Cheers,
Jack

[1] https://orgmode.org/list/875zgjh8wn@gmail.com/

>From 1dc8e2d2cb01a4e6b82342ea8d8c965df8f5222c Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Fri, 28 Aug 2020 19:16:05 -0700
Subject: [PATCH] ob-R: Fix prompt mangling in session output

* lisp/ob-R.el (org-babel-R-evaluate-session): Replace
call to org-babel-comint-with-output with ess-send-to-buffer and
additional wrapper R code.

Fixes https://orgmode.org/list/875zgjh8wn@gmail.com/ and
https://orgmode.org/list/87r1rqled0.fsf@havana/
---
 lisp/ob-R.el | 79 
 1 file changed, 36 insertions(+), 43 deletions(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 5e9d35f58..d69cf23db 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -412,49 +412,42 @@ (defun org-babel-R-evaluate-session
 If RESULT-TYPE equals `output' then return standard output as a
 string.  If RESULT-TYPE equals `value' then return the value of the
 last statement in BODY, as elisp."
-  (cl-case result-type
-(value
- (with-temp-buffer
-   (insert (org-babel-chomp body))
-   (let ((ess-local-process-name
-	  (process-name (get-buffer-process session)))
-	 (ess-eval-visibly-p nil))
-	 (ess-eval-buffer nil)))
- (let ((tmp-file (org-babel-temp-file "R-")))
-   (org-babel-comint-eval-invisibly-and-wait-for-file
-	session tmp-file
-	(format org-babel-R-write-object-command
-		(if row-names-p "TRUE" "FALSE")
-		(if column-names-p
-		(if row-names-p "NA" "TRUE")
-		  "FALSE")
-		".Last.value" (org-babel-process-file-name tmp-file 'noquote)))
-   (org-babel-R-process-value-result
-	(org-babel-result-cond result-params
-	  (with-temp-buffer
-	(insert-file-contents tmp-file)
-	(org-babel-chomp (buffer-string) "\n"))
-	  (org-babel-import-elisp-from-file tmp-file '(16)))
-	column-names-p)))
-(output
- (mapconcat
-  'org-babel-chomp
-  (butlast
-   (delq nil
-	 (mapcar
-	  (lambda (line) (when (> (length line) 0) line))
-	  (mapcar
-	   (lambda (line) ;; cleanup extra prompts left in output
-		 (if (string-match
-		  "^\\([>+.]\\([ ][>.+]\\)*[ ]\\)"
-		  (car (split-string line "\n")))
-		 (substring line (match-end 1))
-		   line))
-	   (org-babel-comint-with-output (session org-babel-R-eoe-output)
-		 (insert (mapconcat 'org-babel-chomp
-(list body org-babel-R-eoe-indicator)
-"\n"))
-		 (inferior-ess-send-input)) "\n"
+  (let ((ess-local-process-name
+	 (process-name (get-buffer-process session)))
+	(ess-eval-visibly-p nil))
+(cl-case result-type
+  (value
+   (with-temp-buffer
+	 (insert (org-babel-chomp body))
+	 (ess-eval-buffer nil))
+   (let ((tmp-file (org-babel-temp-file "R-")))
+	 (org-babel-comint-eval-invisibly-and-wait-for-file
+	  session tmp-file
+	  (format org-babel-R-write-object-command
+		  (if row-names-p "TRUE" "FALSE")
+		  (if column-names-p
+		  (if row-names-p "NA" "TRUE")
+		"FALSE")
+		  ".Last.value" (org-babel-process-file-name tmp-file 'noquote)))
+	 (org-babel-R-process-value-result
+	  (org-babel-result-cond result-params
+	(with-temp-buffer
+	  (insert-file-contents tmp-file)
+	  (org-babel-chomp (buffer-string) "\n"))
+	(org-babel-import-elisp-from-file tmp-file '(16)))
+	  column-names-p)))
+  (output
+   (let ((tmp-file (org-babel-temp-file "R-")))
+	 (with-temp-buffer
+	   (insert (format "capture.output({
+%s
+}, file='%s')"
+			   body tmp-file))
+	   (ess-eval-buffer))
+	 (ess-wait-for-process)
+	 (with-temp-buffer
+	   (insert-file-contents tmp-file)
+	   (buffer-string)))
 
 (defun org-babel-R-process-value-result (result column-names-p)
   "R-specific processing of return value.
-- 
2.28.0

Help debugging R source code block output problem with :session

[Dylan Schwilk]

I returned to an org file this week and found that I am getting 
some strange source code block output for R code when I use the 
:session header. I have been able to duplicate this with a minimal 
init file. I strongly suspect it is some problem at my end but 
perhaps folks here can help me know here to look? It occurs with a 
minimal emacs initialization.


First, here is a small org file example of the problem. In the 
second results block the ">" appears to be treated as a prompt 
line to strip from output but only when a session is started. This 
happens with any ">" in output when the :session header occurs. 
the problem is dramatic when printing tibbles where the column 
modes are enclosed in angle brackets.


test.org



** Test org babel R output prompt problem
#+begin_src R :results output
print("  ")
print("one  three")
print("end")
#+end_src

#+RESULTS:
: [1] "  "
: [1] "one  three"
: [1] "end"

#+begin_src R :results output :session "NEW"
print("  ")
print("one  three")
print("end")
#+end_src

#+RESULTS:
: [1] "<
: <
: "
: [1] "one <
: three"
: [1] "end"
<<<

The second block produces the bad output. This occurs with a 
minimal setup.

I start emacs with

emacs -Q -l "~/debugorg.el"


where debugorg.el is:




require 'package)
add-to-list 'package-archives '("melpa" . 
"https://melpa.org/packages/";) t)
add-to-list 'package-archives '("org" . 
"https://orgmode.org/elpa/";) t)

package-initialize)

require 'ess-site)

(org-babel-do-load-languages
'org-babel-load-languages
'((R . t)))
<<

emacs version 26.3
org-mode version 9.3.7
ess version 18.10.3snapshot

--

Re: babel default header args as functions

[Matt Huszagh]

Matt Huszagh  writes:

> I've added the ability in my own configuration to use lambda functions
> that evaluate to a string as babel default header arguments, instead of
> just the plain strings currently allowed. Would anyone else be
> interested in this feature? Shall I prepare a patch?
>
> There are a number of use cases for this, but to give you an idea,
> here's one I'm using myself.
>
>   (setq org-babel-default-header-args:latex
> `((:file . (lambda ()
>  (concat "img/"
>  (sha1 (org-element-property :value 
> (org-element-at-point)))
>  (by-backend '((html . "-html") (t . "-org")))
>  ".svg")
>
> This computes a filename based on the hash of the block contents.

I've generated a patch for this. Please let me know your thoughts. I
believe this adds valuable flexibility to default header
arguments.

Thanks!
Matt

>From 3dfb1066b211fdcc5e3ea1da8d36aa115dde9f9b Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Fri, 28 Aug 2020 11:05:59 -0700
Subject: [PATCH] ob-core.el: Add ability to use closures as default header
 arguments

* lisp/ob-core.el (org-babel-default-header-args): Document ability to
use functions.
(eval-default-headers): New function to generate default header
arguments, which adds the ability to evaluate function arguments at
runtime.
(org-babel-get-src-block-info): Use new header argument evaluate
function when retreiving src block info.

The closures are evaluated at runtime.
---
 lisp/ob-core.el | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 578622232..4a22f17e7 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -473,7 +473,23 @@ For the format of SAFE-LIST, see `org-babel-safe-header-args'."
 (defvar org-babel-default-header-args
   '((:session . "none") (:results . "replace") (:exports . "code")
 (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no"))
-  "Default arguments to use when evaluating a source block.")
+  "Default arguments to use when evaluating a source block.
+
+This is a list in which each element is an alist.  Each key
+corresponds to a header argument, and each value to that header's
+value.  The value can either be a string or a closure that
+evaluates to a string at runtime.  For instance, imagine you'd
+like to set the file name output of a latex source block to a
+sha1 of its contents.  We could achieve this with:
+
+(defun org-src-sha ()
+  (let ((elem (org-element-at-point)))
+(concat (sha1 (org-element-property :value elem)) \".svg\")))
+
+(setq org-babel-default-header-args:latex
+  `((:results . \"file link replace\")
+(:file . (lambda () (org-src-sha)")
+
 (put 'org-babel-default-header-args 'safe-local-variable
  (org-babel-header-args-safe-fn org-babel-safe-header-args))
 
@@ -584,6 +600,18 @@ the outer-most code block.")
 
 (defvar *this*)
 
+(defun eval-default-headers (headers)
+  "Compute default header list set with HEADERS.
+
+  Evaluate all default header arguments set to functions prior to
+  returning the list of header arguments."
+  (let ((lst nil))
+(dolist (elem (eval headers t))
+  (if (listp (cdr elem))
+  (push `(,(car elem) . ,(funcall (cdr elem))) lst)
+(push elem lst)))
+lst))
+
 (defun org-babel-get-src-block-info (&optional light datum)
   "Extract information from a source block or inline source block.
 
@@ -615,7 +643,7 @@ a list with the following pattern:
 	   (apply #'org-babel-merge-params
 		  (if inline org-babel-default-inline-header-args
 			org-babel-default-header-args)
-		  (and (boundp lang-headers) (eval lang-headers t))
+		  (and (boundp lang-headers) (eval-default-headers lang-headers))
 		  (append
 		   ;; If DATUM is provided, make sure we get node
 		   ;; properties applicable to its location within
-- 
2.28.0

Re: [PATCH] Re: Re: org-forward-heading-same-level and the invisible-ok argument

[D]

>> + (mapcar #'org-invisible-p
>> + (number-sequence (line-beginning-position)
>> +  (1- (line-end-position)
>
> This is a bad idea. org--line-visible-p will be called for every single
> invisible headline. If you check every single point at every single
> invisible headline, it can be extremely slow.

Hm, of course it would only check invisible headlines of the same level,
thanks to the logic of the navigation command.  However, I do see the
concern.

> Better do something like below (or maybe even without narrow-to-region,
> not sure if that may cause significant overhead):
> 
> (defun org--line-visible-p ()
>   "Return t if the current line is partially visible."
>   (save-restriction
> (narrow-to-region (line-beginning-position) (1- (line-end-position)))
> (let ((visible t)
> (p (point-min)))
>   (while (and visible (< p (point-max)))
>   (when (org-invisible-p p)
>   (setq visible nil))
> (setq p (next-single-char-property-change p 'invisible)))
>   visible)))

The issue with that is that it reintroduces the thing the patch is
trying to fix, as it considers any partially invisible line as fully
invisible (while the opposite should be the case).  I also don't see
much of a difference when profiling, unless I severely screwed up.  I
just manually prepared a buffer with 10k invisible headings (each 83
chars long) and plugged a visible one of the same level above and below
the huge invisible block.  C-c C-f does take a second plus change in
that case for both cases.

The main issue is that a hot-circuit approach would only ever optimize
navigating across many visible blocks, if we want a partially visible
heading to be treated like a visible one (instead of an invisible one
like it is at the moment).  However, we could use a similar hack as the
original implementation and only check a couple of characters, if
performance really is a concern there.  In that case, I think it would
be best to check the *last* few characters (as it makes more sense that
the stars at the beginning are hidden than the actual title at the end).
 That would mean to replace the original implementation with something like

(defun org--line-visible-p ()
  "Return t if the current line is partially visible."
  (let ((min-pos (max (line-beginning-position)
  (- (line-end-position) 3)))
(max-pos (1- (line-end-position
(and
 (memq nil
   (mapcar #'org-invisible-p
   (number-sequence min-pos max-pos)))
 t)))

which basically removes any relevant slowdown.
But I'd really only recommend going that far if necessary, given it adds
a random magic number.  Thoughts?

Cheers,
D.

[PATCH[ Re: Indirect buffers, org-store-link, and org-insert-link

[Maxim Nikulin]

It seems I have managed to fix store/insert link for indirect buffers by 
applying changes similar to

https://orgmode.org/list/8162z2tf8n.fsf...@gmail.com/
to another couple of code fragments.

Due to monkey-typing approach I am unsure that I have not broken 
something else.


>From 3d42f1e659b2c797629e6c041b38ae67dbe099a1 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Fri, 28 Aug 2020 14:49:03 +
Subject: [PATCH] ol.el: Fix store and insert link in indirect buffer

* lisp/ol.el(org-store-link): Store link with CUSTOM_ID anchor
in indirect buffer.
(org-insert-link): Do not add file name to search and CUSTOM_ID
links pointed to the same file when called from indirect buffer.

When a subtree was open in an indirect buffer, wrong argument
of `abbreviate-file-name' prevented storing link to a CUSTOM_ID
anchor. Internal link to a header line or to a CUSTOM_ID anchor
was created with file name instead of concise form.
This is a follow up of 784e5f1488.

TINYCHANGE
---
 lisp/ol.el | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index 76a9aca2b..951bb74e7 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1699,8 +1699,10 @@ non-nil."
 	  (push (list link desc) org-stored-links)
 	  (message "Stored: %s" (or desc link))
 	  (when custom-id
-	(setq link (concat "file:" (abbreviate-file-name
-	(buffer-file-name)) "::#" custom-id))
+	(setq link (concat "file:"
+			   (abbreviate-file-name
+(buffer-file-name (buffer-base-buffer)))
+			   "::#" custom-id))
 	(push (list link desc) org-stored-links)))
 	(car org-stored-links)
 
@@ -1841,13 +1843,14 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
 ;; Check if we are linking to the current file with a search
 ;; option If yes, simplify the link by using only the search
 ;; option.
-(when (and buffer-file-name
+(when (and (buffer-file-name (buffer-base-buffer))
 	   (let ((case-fold-search nil))
 		 (string-match "\\`file:\\(.+?\\)::" link)))
   (let ((path (match-string-no-properties 1 link))
 	(search (substring-no-properties link (match-end 0
 	(save-match-data
-	  (when (equal (file-truename buffer-file-name) (file-truename path))
+	  (when (equal (file-truename (buffer-file-name (buffer-base-buffer)))
+		   (file-truename path))
 	;; We are linking to this same file, with a search option
 	(setq link search)
 
-- 
2.17.1

Re: [PATCH] Re: Re: org-forward-heading-same-level and the invisible-ok argument

[Ihor Radchenko]

> +  (mapcar #'org-invisible-p
> +  (number-sequence (line-beginning-position)
> +   (1- (line-end-position)

This is a bad idea. org--line-visible-p will be called for every single
invisible headline. If you check every single point at every single
invisible headline, it can be extremely slow.

Better do something like below (or maybe even without narrow-to-region,
not sure if that may cause significant overhead):

(defun org--line-visible-p ()
  "Return t if the current line is partially visible."
  (save-restriction
(narrow-to-region (line-beginning-position) (1- (line-end-position)))
(let ((visible t)
  (p (point-min)))
  (while (and visible (< p (point-max)))
(when (org-invisible-p p)
  (setq visible nil))
(setq p (next-single-char-property-change p 'invisible)))
  visible)))

Best,
Ihor


D  writes:

>> I do not think that setting visibility the leading stars is a correct
>> approach to control the movement commands. After second though about the
>> issue you raised in the first email, I think that it would make more
>> sense for org-forward-heading-same-level to check if any part of the
>> heading line is visible to decide if we need to skip it (instead of
>> current approach checking only the point at the beginning of the
>> headline). Any mode aiming to make org-forward-heading-same-level skip a
>> heading will then just need to make the whole heading invisible.
>> Skipping partially visible headlines would be a violation of the
>> docstring.
>
> Good point!  I think this would be a more or less reasonable patch, then.
>
> Cheers,
> D.
> From 4c0f638104f689780de317af5f715384152459bd Mon Sep 17 00:00:00 2001
> From: "D. Williams" 
> Date: Fri, 28 Aug 2020 14:15:31 +0200
> Subject: [PATCH] org.el: let heading navigation check the entire heading for
>  visibility
>
> * org.el (org-forward-heading-same-level): check complete heading instead of 
> the first char
>
> TINYCHANGE
> ---
>  lisp/org.el | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 71dbc611e..26f815e19 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -20478,6 +20478,15 @@ entry."
>   ((looking-at-p re) (forward-line))
>   (t (throw 'exit t
>  
> +(defun org--line-visible-p ()
> +  "Return t if the current line is partially visible."
> +  (and
> +   (memq nil
> +  (mapcar #'org-invisible-p
> +  (number-sequence (line-beginning-position)
> +   (1- (line-end-position)
> +   t))
> +
>  (defun org-forward-heading-same-level (arg &optional invisible-ok)
>"Move forward to the ARG'th subheading at same level as this one.
>  Stop at the first and last subheadings of a superior heading.
> @@ -20499,8 +20508,7 @@ non-nil it will also look at invisible ones."
>   (cond ((< l level) (setq count 0))
> ((and (= l level)
>   (or invisible-ok
> - (not (org-invisible-p
> -   (line-beginning-position)
> + (org--line-visible-p)))
>  (cl-decf count)
>  (when (= l level) (setq result (point)))
>   (goto-char result))
> -- 
> 2.26.2

Bug: org-capture entry sometimes ends without newline, garbles next headline [9.3.6 (9.3.6-elpa @ /home/arne/Disy/.emacs.d/elpa/org-9.3.6/)]

[Dr. Arne Babenhauserheide]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Sometimes when I use org-capture to create a new headline, that headline
ends with a non-empty partial line that isn’t terminated by a newline.

This causes the next headline to be corrupted, because the * is appended
to the last line of the new entry.

Example:

* new entry
some text * old entry

I tried adding the empty-lines options and empty-lines-before and
empty-lines-after, but this did not fix the problem.

This sometimes causes entries to no longer be recognized as headlines,
so my task planning does not show them (for example in org-agenda view,
clocktable, and kanban.el).

It would be great if it could be ensured that capturing a new entry can
never modify the first line of another entry.

Best wishes,
Arne

-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

[PATCH] Re: Re: org-forward-heading-same-level and the invisible-ok argument

[D]

> I do not think that setting visibility the leading stars is a correct
> approach to control the movement commands. After second though about the
> issue you raised in the first email, I think that it would make more
> sense for org-forward-heading-same-level to check if any part of the
> heading line is visible to decide if we need to skip it (instead of
> current approach checking only the point at the beginning of the
> headline). Any mode aiming to make org-forward-heading-same-level skip a
> heading will then just need to make the whole heading invisible.
> Skipping partially visible headlines would be a violation of the
> docstring.

Good point!  I think this would be a more or less reasonable patch, then.

Cheers,
D.
>From 4c0f638104f689780de317af5f715384152459bd Mon Sep 17 00:00:00 2001
From: "D. Williams" 
Date: Fri, 28 Aug 2020 14:15:31 +0200
Subject: [PATCH] org.el: let heading navigation check the entire heading for
 visibility

* org.el (org-forward-heading-same-level): check complete heading instead of the first char

TINYCHANGE
---
 lisp/org.el | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 71dbc611e..26f815e19 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20478,6 +20478,15 @@ entry."
 		((looking-at-p re) (forward-line))
 		(t (throw 'exit t
 
+(defun org--line-visible-p ()
+  "Return t if the current line is partially visible."
+  (and
+   (memq nil
+	 (mapcar #'org-invisible-p
+		 (number-sequence (line-beginning-position)
+  (1- (line-end-position)
+   t))
+
 (defun org-forward-heading-same-level (arg &optional invisible-ok)
   "Move forward to the ARG'th subheading at same level as this one.
 Stop at the first and last subheadings of a superior heading.
@@ -20499,8 +20508,7 @@ non-nil it will also look at invisible ones."
 	(cond ((< l level) (setq count 0))
 		  ((and (= l level)
 			(or invisible-ok
-			(not (org-invisible-p
-  (line-beginning-position)
+			(org--line-visible-p)))
 		   (cl-decf count)
 		   (when (= l level) (setq result (point)))
 	(goto-char result))
-- 
2.26.2