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://gi
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
> 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-
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
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 on
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
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 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 h
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
>> + (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 sin
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 3d42f1e659b2c7
> + (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
i
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.
--
> 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
14 matches
Mail list logo
