This patch is for testing purposes only, although the implementation for
LaTeX backend is perfectly usable.
The basic syntax of the new element is:
{lorem ipsum dolor}
=> LaTeX: \foo{lorem ipsum dolor}
Nested elements are possible, as well as the inclusion of other elements
such as macros,
Björn Bidar writes:
> The problem is that org-mode leaves the agenda command selection frame around
> after selecting the specific agenda to be displayed
I cannot reproduce on the latest main using the latest Emacs master.
May you please provide a reproducer starting from emacs -Q?
See
Ihor Radchenko writes:
> Björn Bidar writes:
>> I noticed thatOrg-agenda leaves frame around if org-agenda-window-setup
>> is set to other-frame since
>> 78dc58508ddbf97b6f44c0a6dd222eab3d13b50a.
>
> May you please explain more what the problem is?
The problem is that org-mode leaves the
gerard.vermeu...@posteo.net writes:
>>> May you please provide more details?
>>
> This is different of what I saw before:
>
> When splitting python blocks in an org file I got a long list of
> warnings:
> Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org
> buffer #
Edgar Lux writes:
> I am trying to exclude different sub-trees (a.k.a. headings or sections),
> depending on the exporter backend. I am familiar with =:noexport:= to exclude
> selected sections (disregarding the backend). I found a solution, but it is
> only intended for a specific backend:
>
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>> Note that only the first 5 patchs are real patchs. The remaining things
>> are just a demo how it could be used. The current async (ob-comint)
>> depends on writing UUIDs in org files, and, that's why I couldn't use it
>> as a demo. I'm
Björn Bidar writes:
> I noticed thatOrg-agenda leaves frame around if org-agenda-window-setup
> is set to other-frame since
> 78dc58508ddbf97b6f44c0a6dd222eab3d13b50a.
May you please explain more what the problem is?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org
Ruiyang Wu writes:
> I recently started to get the following warning from emacs when loading org
> mode:
> Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by
> aliasing to ‘org-cycle-hide-block-startup’
>
> I have this in my init file:
> (setq org-hide-block-startup t)
>
>
Nathaniel Nicandro writes:
> I think I found a bug where the condition for `org-src-fontify-natively`
> in `org-src-fontify-meta-lines-and-blocks-1` wasn't handling the block
> type. `org-src-fontify-natively` says it should fontify src blocks
> only, but the condition didn't have that
Derek Chen-Becker writes:
> I started getting an error after updating to the latest commit on main:
>
> Invalid capture target specification: (file+headline org-default-notes-file
> "Tasks")
>
> I bisected it down to 0a58a53edac955381266e49bd68d1140fbece33e, but I can't
> tell from the commit
Max Nikulin writes:
> On 19/02/2024 02:36, Martin Edström wrote:
>> +Since this is a shell-command, remember to use single-quotes
>> +around \\='%i\\=', not double-quotes! Else a math fragment such
>> +as \"$y = 200$\" gets butchered into only \" = 200\"."
>
> I am afraid, the code, not the
Bruno Barbier writes:
> Note that only the first 5 patchs are real patchs. The remaining things
> are just a demo how it could be used. The current async (ob-comint)
> depends on writing UUIDs in org files, and, that's why I couldn't use it
> as a demo. I'm thinking about dropping the patch:
Hi Rudy,
Note that I am not an org maintainer; just trying to help :-)
Rudi C writes:
>> Why is `:eval never` not as good ? You don't have to write it on each
>> code block; you may set it globally, per file, per headline, etc.
>
> The main reason is that I also use source blocks for babel
I noticed thatOrg-agenda leaves frame around if org-agenda-window-setup
is set to other-frame since
78dc58508ddbf97b6f44c0a6dd222eab3d13b50a.
Reverting the commit/loading the file before the change fixes the issue.
Emacs : GNU Emacs 30.0.50 (build 1, x86_64-suse-linux-gnu, GTK+ Version
14 matches
Mail list logo
