Hi,
AUCTeX has taken back this change, realizing that texmathp.el is also used
in contexts where the mechanisms of AUCTeX to find out about LaTeX packages
being used does not work. I do think this is already fixed in the latest
AUCTeX version. At least it is fixed in their git.
- Carsten
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
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.
> + (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 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
>> + (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
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?
>
>
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
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
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.
> 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
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
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
13 matches
Mail list logo