> From: Max Nikulin
> Date: Fri, 26 Apr 2024 16:53:23 +0700
>
> On 26/04/2024 15:17, Protesilaos Stavrou wrote:
>> Since we are now using labels for the HTML export, I think it makes
>> sense to optionally use those for the anchor tags as well.
> [...]
>
>> +(defcustom org-html-footnote-use-label-
> From: Ihor Radchenko
> Date: Sun, 28 Apr 2024 10:22:50 +
>
> Protesilaos Stavrou writes:
>
>>> See the attached tentative patch.
>>
>>> [... 144 lines elided]
>>
>> Thank you! I just tried it. I encountered two problems with it, which I
>> am addressing with the two attached patches (feel f
> From: Ihor Radchenko
> Date: Sun, 28 Apr 2024 10:37:58 +
>
> Protesilaos Stavrou writes:
>
>> Since we are now using labels for the HTML export, I think it makes
>> sense to optionally use those for the anchor tags as well.
>>
>> See the attached patch for a possible way of doing this.
>>
>
On 02/05/2024 21:55, Ihor Radchenko wrote:
vitalij writes:
in org-babel-sh-evaluate
file:~/.emacs.d/elpa/org-9.6.28/ob-shell.el::300
this do apply: (process-file "/tmp/babel-NfRG9P/sh-script-jmKNA4"
"/tmp/babel-NfRG9P/sh-stdin-o3CEm5" # nil nil)
I don't allow executables in /tmp folder!
On 02/05/2024 18:15, Ihor Radchenko wrote:
May you try the attached patch (on top of the latest main)?
Does it feel better?
I see regressions only (Emacs 28).
[[#foo]]
[[#bar]]
SPC causes permanent appearance of square brackets for [[#foo]].
I do not like flashes especially since they do not
On 03/05/2024 13:59, Protesilaos Stavrou wrote:
From: Max Nikulin Fri, 26 Apr 2024 16:53:23 +0700
Another option may be to rely on the existing one:
`org-html-prefer-user-labels'
Yes, sure. It is fine to reuse an existing user option. Though reading
through its docstring and the code, I cannot
Ihor Radchenko writes:
>> but more importantly, based on that description I would expect the following
>> test document to parse into three separate plain lists, but it parses as a
>> single plain list with 3 items:
>>
>> ```
>> 1. foo
>> - bar
>> - lorem :: ipsum
>> ```
>>
>> [1] https://orgmo
Nafiz Islam writes:
>> > Would you be interested to submit a patch?
>> If I finish writing a patch for it. Sure.
You may refer to https://orgmode.org/worg/org-contribute.html
And feel free to ask anything if you have questions.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more ab
Max Nikulin writes:
>> Yes, sure. It is fine to reuse an existing user option. Though reading
>> through its docstring and the code, I cannot tell what this is doing
>> exactly. Is it applying to all HTML elements, or just headings?
>>
>> On my end, I have that option set to nil, but exported he
Pedro Andres Aranda Gutierrez writes:
> It would be great to have a thing-at-point handler that returns a cell in
> and org table. The most simple use case is to have a table in an org-file
> with data that you need to transfer to an online Web page. Being able to
> (copy-as-kill ...) a cell's co
Protesilaos Stavrou writes:
>>> Since we are now using labels for the HTML export, I think it makes
>>> sense to optionally use those for the anchor tags as well.
>> ...
>> We can indeed add such option, but is it of any practical use?
>> Do you have examples of workflows when such new option wil
Max Nikulin writes:
> What I do not like in `org-babel-read' is false positive for escaped
> quote when actually backslash is escaped:
>
> (org-babel-read "\"1\" 2 \"3\"" t)
> "1\\"
This is a bug.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2028bb15c
Matt writes:
> Since we're considering this for all babel backends, "interpreter-args"
> wouldn't describe gcc or other compilers. What about :command-args,
> :command-args, :cmd-args? "Command" is the only thing I can think of that
> describes all of the languages, other than maybe "binary"
João Pedro writes:
> All right so if I understand correctly, we'd like to deprecate switches
> from the parser and introduce :key val pairs for each switch, but no one
> has gotten to it yet?
Yes
> If that's the case, I'd propose something like
>
> - (-|+)n => :number-lines (yes|*no*|continue)
"Cook, Malcolm" writes:
>>May you prepare a patch modifying doc/org-manual.org with your suggestions?
>>See https://orgmode.org/worg/org-contribute.html
>
> Glad to try. How's this?
Thanks!
Applied, onto main, with modifications.
I merged your new section into previous section explaining how to
Max Nikulin writes:
> On 02/05/2024 18:15, Ihor Radchenko wrote:
>> May you try the attached patch (on top of the latest main)?
>> Does it feel better?
>
> I see regressions only (Emacs 28).
>
> [[#foo]]
> [[#bar]]
>
> SPC causes permanent appearance of square brackets for [[#foo]].
That's minor
When I select any capture command, most crucially including the one from my
gnus emails and most simply just my save my own text, I am blocked by the error
Capture template ‘i’: Wrong type argument: sequencep, org-display-buffer-split
[9.6.15 (release_9.6.15 @ /home/torysa/emacs/.emacs.d/strai
web...@toryanderson.com (Tory S. Anderson) writes:
> When I select any capture command, most crucially including the one from my
> gnus emails and most simply just my save my own text, I am blocked by the
> error
>
> Capture template ‘i’: Wrong type argument: sequencep,
> org-display-buffer-spl
IIRC I wrote the part about there being two types of lists at the syntax level,
which are bulleted and numbered, descriptive are effectively bulleted in the
context of this behavior, but I think it is fine to say multiple.
With regard to the stated behavior about consecutive being parsed separatel
Hi,
Thanks for getting things going on this again João.
Based on what is in org-element-example-block-parser
and org-element-src-block-parser I think
:number-lines (yes|no|continue) as João proposes
:indent (preserve|align|???) not sure about naming
:labels (link|keep|remove
On 03/05/2024 18:14, Ihor Radchenko wrote:
Max Nikulin writes:
Yes, sure. It is fine to reuse an existing user option. Though reading
through its docstring and the code, I cannot tell what this is doing
exactly. Is it applying to all HTML elements, or just headings?
On my end, I have that opti
Hi Ihor, of course this was just an example. The thing-at-point would make it
easier to write a copy-as-kill-cell function.
Best,/PA
Enviado desde mi iPhone
> El 3 may 2024, a las 13:17, Ihor Radchenko escribió:
>
> Pedro Andres Aranda Gutierrez writes:
>
>> It would be great to have a t
Pedro Andres Aranda Gutierrez writes:
>>> It would be great to have a thing-at-point handler that returns a cell in
>>> and org table. The most simple use case is to have a table in an org-file
>>> with data that you need to transfer to an online Web page. Being able to
>>> (copy-as-kill ...) a c
On 2024-05-02, 17:41 +0700, Max Nikulin wrote:
> `condition-case' may help to avoid the internal `shortdoc--groups'
> variable here. As to completion, it is better to ask for public API.
> However emacs developers likely will decline such request.
>
> Consider the following just as ideas.
>
>
So far I have written this code...
(defun org-capture-expand-headline (headline)
"Expand functions, symbols and strings for HEADLINE.
When HEADLINE is a function, call it. When it is a form, evaluate
it. When it is a variable, return its value. When it is a string,
treat it as a headlin
When I create a clocktable, its entries are links to heading text:
[ [file:/path/to/meetings.org::*featureset meeting][featureset meeting] ]
But in my meetings.org file there are dozens of headings that simply read:
```
* featureset meeting
```
so all clocktable links to these meetings poi
never mind. package-initilalize if called in .emacs once will not repeat
or warn despite being not needed there normally. at least in 27.
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
Em sexta, 03/05/2024 às 10:12 (-07), Tom Gillespie escreveu:
> Hi,
>Thanks for getting things going on this again João.
No problem! I've been meaning to get my feet wet on some Org-mode
hacking for a while now.
> Based on what is in org-element-example-block-parser
> and org-element-src-blo
Hi,
Ok so I don't know whether this is a bug or intended behaviour (though
if its the latter I propose we reconsider), but if I have the following
#+begin_src emacs-lisp :noweb yes :comments noweb :tangle /tmp/foo.el
(progn
<>)
#+end_src
#+name: foo
#+begin_src emacs-lisp
(message "foo")
#+end
> From: Rudolf Adamkovič
> To: emacs-orgmode@gnu.org
> Cc: Rudolf Adamkovič
> Subject: [PATCH] Auto-complete PRINT_BIBLIOGRAPHY with a trailing
> colon
> Message-ID: <20240502162033.16420-1-rud...@adamkovic.org>
>
> * lisp/org.el (org-options-keywords): Add a trailing colon to the
> 'PRIN
Pedro Andres Aranda Gutierrez writes:
>> * lisp/org.el (org-options-keywords): Add a trailing colon to the
>> 'PRINT_BIBLIOGRAPHY' keyword to avoid unnecessary user confusion.
>
> Hi Rudolf,
>
> I don't see any confusion by not having a trailing colon in
> #+print_bibliography. Where would there
31 matches
Mail list logo
