Ihor Radchenko writes:
> Duplicate of https://list.orgmode.org/orgmode/875y46xyr8.fsf@localhost/
>
> Canceled.
Well, sort of. This particular bug is about parameterized environments,
not TikZ per se, but I get where you are coming from, looking at the bug
as a core developer, from below.
Ok here's an updated patch. Please let me know if there's anything else.
On Sun, Jun 30, 2024 at 4:30 AM Rudolf Adamkovič
wrote:
> Nathan Nichols writes:
>
> > +(defun org-html-normalize-str-or-fn (input args)
>
> How about
>
> org-html-normalize-string-or-function
>
> instead of
>
>
Ihor Radchenko writes:
> Again, we know this problem, and we normally force the prompt to be
> something more unique when creating sessions. But we do not touch the
> prompt when you point Org to an existing interactive shell buffer - that
> could be a surprise if Org mode changes the prompts by
Ihor Radchenko writes:
>> https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md
>
> I am looking at this gitlab link, and they way it is implemented is
> simply setting PROMPT in a way that adds these escape sequences to the
> original PROMPT value.
Max Nikulin writes:
> On 30/06/2024 22:28, Ihor Radchenko wrote:
>> I do not see a great benefit of re-implementing session support via
>> actual terminal. (I think we agree here).
>
> `shell' and so comint allocates "actual" pty.
Are you sure?
--
Ihor Radchenko // yantar92,
Org mode
Dear fellow Emacsians,
We are excitedly calling for your participation for EmacsConf 2024,
planned for December 7 and 8, 2024 (Sat-Sun)! Please submit your
proposal by September 20, 2024 (Friday). See below for details on
how to send in your proposal, or chat with us about them and about
other
On 30/06/2024 22:28, Ihor Radchenko wrote:
I do not see a great benefit of re-implementing session support via
actual terminal. (I think we agree here).
`shell' and so comint allocates "actual" pty. I expect that bracketed
paste is just some escape sequences delimiting pasted text (fcntl
Max Nikulin writes:
> ... ob-shell might offer variants for sessions: dumb
> stdin, source a temporary file, or bracketed paste. Anything besides
> stdin (with its confusing differences from interactive sessions) is
> almost certainly requires shell-specific code. And `shell' is likely not
>
On 30/06/2024 18:06, Ihor Radchenko wrote:
Max Nikulin writes:
https://debbugs.gnu.org/67259
Notice that the report is for *interactive* sessions. Org babel sessions
are not so interactive. They are to maintain state, not to interact with
users directly...
You are not right. We have
Sharon Kimble writes:
>> Any chance you can share the problematic part, so that we can diagnose
>> what is off?
>
> The problem was caused by the file/folder getting too big, and it was
> totalling 584.35 mbs! It was all because of git, because when I totally
> removed and deleted the git
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ihor Radchenko writes:
> Sharon Kimble writes:
>
>> I've tried my command on another project, and it works there, so I've
>> gone back to the problematic file/project and then started splitting
>> with the first chapter now working using my
Max Nikulin writes:
> https://debbugs.gnu.org/67259
>
> Notice that the report is for *interactive* sessions. Org babel sessions
> are not so interactive. They are to maintain state, not to interact with
> users directly...
You are not right. We have legitimate cases when people can switch to
Rudolf Adamkovič writes:
> The Org manual states that LaTeX fragments are
>
> Environments of any kind. The only requirement is that the ‘\begin’
> statement appears on a new line, preceded by only whitespace.
>
> yet, the Org document
>
> #+OPTIONS: tex:dvisvgm
>
> \begin{array}{cc|c}
>
Ihor Radchenko writes:
> Stefan Kangas writes:
>
>> There is a reference to `header-arguments-alist', but I can't find any
>> such variable in the tree.
>>
>> ./lisp/org/ob-core.el:2517:`header-arguments-alist' see the docstring for
>
> It is not referring to a variable, but to ARGUMENTS slot
On 18/11/2023 22:51, Matt wrote:
On Fri, 17 Nov 2023 23:07:57 +0100 Matt wrote ---
The second claim has nothing to do with Org Babel. I was able to
confirm it and provide the steps to reproduce. I think it would make
sense to report it upstream and let them decide if it's expected
Ihor Radchenko writes:
> Rudolf Adamkovič writes:
>
> This is because of how `orgtbl-to-generic' is implemented. It is taking
> pieces from the full ox.el exporter, hard-coding certain things. For
> example, it always removes special table lines:
>
> ;; Since we are going to export using a
It's weird because with swapping "<>" and "/" with escape-syntax character has
no problem in the table:
#+BEGIN_SRC emacs-lisp
(list (list 1 2) (list "\<>" "\/") 'hline (list 3 4) (list 5 6))
#+end_src
#+RESULTS:
| 1 | 2 |
| <> | / |
|+---|
| 3 | 4 |
| 5 | 6 |
On 6/30/24 11:43 AM,
Nathan Nichols writes:
> +(defun org-html-normalize-str-or-fn (input args)
How about
org-html-normalize-string-or-function
instead of
org-html-normalize-str-or-fn
to match
org-element-normalize-string
and make searching easier?
Rudy
--
"Great minds discuss ideas; average minds
The Org manual states that LaTeX fragments are
Environments of any kind. The only requirement is that the ‘\begin’
statement appears on a new line, preceded by only whitespace.
yet, the Org document
#+OPTIONS: tex:dvisvgm
\begin{array}{cc|c}
P & Q & P \iff Q \\
\hline
0 & 0
"S. Sajad Hosseini Balef" writes:
> It's seems related to the "<>" bacuse with any other strings I haven't
> such issue.
>From what I see, the culprit is the "/" because, as soon as it appears,
Org Babel drops the row from the output. Then, when I replace the "/"
with something different, such
20 matches
Mail list logo
