Ihor Radchenko writes:
>
> This is known.
> #+STARTUP options are handled before buffer-local variables take effect.
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003
> Handled.
>
I have read the thread but I can not figure a solution. I tried to
search "early local" you proposed in the
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> This is not true. We can generate a precise TeXinfo markup from Org
> files
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Many times I need to "save" an annotation point in the pdf-tools
>> annotations buffer. So I defined a new link type and the function to
>> store it. The link is stored with the structure:
>>
>>
Juan Manuel Macías writes:
> Many times I need to "save" an annotation point in the pdf-tools
> annotations buffer. So I defined a new link type and the function to
> store it. The link is stored with the structure:
>
> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p.
On Thu, 8 Feb 2024, at 1:02 PM, Ihor Radchenko wrote:
> I have some thoughts about rewording your changes to the manual and
> ORG-NEWS. See the attached patch on top of yours.
Thanks, makes sense -- wasn't sure whether to keep this as a separate patch or
not, I have squashed into the attached
Dear Ihor,
Ihor Radchenko writes:
>> My question: Is this the intended way to suppress bookmark creation?
>
> I think so.
Great!
> We first introduced `org-capture-bookmark' and only then added
> `org-bookmark-names-plist'. Maybe we should obsolete
> `org-capture-bookmark' to avoid confusion.
Ihor Radchenko writes:
> Jack Kamm writes:
>
>> On executing any python session block I am getting the following error
>> which I think is caused by the above:
>>
>> Debugger entered--Lisp error: (void-variable buffer-name)
>
> That's a mystery.
It looks like 'when-let*' doesn't accept
Jack Kamm writes:
> On executing any python session block I am getting the following error
> which I think is caused by the above:
>
> Debugger entered--Lisp error: (void-variable buffer-name)
That's a mystery.
> Also, make shows a byte-compiler warning about this:
>
> Compiling
>
Jason May writes:
> This request was prompted by an issue encounted in org-journal, and it
> probably exists in org-roam and other similar packages.
>
> Ignoring blank lines sounds like a reasonable approach.
It is reasonable, but I am not convinced that it is important enough to
make changes
Chang Xiaoduan writes:
> I have been experimenting with org-num-mode recently. I find that if an
> org-mode file enables org-num-mode on startup by adding:
>
> ```emacs-lisp
> #+STARTUP: num
> ```
>
> and if there is a file local prop line:
>
> ```emacs-lisp
> # -*- org-num-skip-unnumbered: t;
Loki wang writes:
> Emacs : GNU Emacs 29.1 (build 1, aarch64-apple-darwin23.2.0, Carbon Version
> 170 AppKit 2487.3)
> of 2023-12-20
> Package: Org mode version 9.6.18 ( @
> /Users/wangjian/.emacs.d/elpa/org-9.6.18/)
Thanks for reporting!
May you also share the warning text? I am
Max Nikulin writes:
>> [...]> The prompt is displayed twice because fetching is attempted twice
>> - when
>> reading startup options and when initializing macros. This is
>> sub-optimal, but expected.
>
> Are names of macros necessary for some purpose before export is started?
With the current
Max Nikulin writes:
> On 08/02/2024 00:10, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> It is a bit more tricky. Current file may be remote as well. Browsers
>>> have concept of same origin for applying security and privacy measures.
>>> Org needs something similar.
>>
>> May you please
Ihor Radchenko writes:
> <2024-02-22 18:30-20:00> is a valid timestamp. Agenda not handling it is
> an oversight that should be fixed.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=62956196d
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more
"Rick Lupton" writes:
> On Sat, 3 Feb 2024, at 1:10 PM, Ihor Radchenko wrote:
>> In my testing, I used #+name: as link target.
>> However, what I missed is that #+name targets are matched even when
>> `org-link-search-must-match-exact-headline' is set to 'query-to-create.
>> The docstring is not
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.
Hi,
Sourcehut is known for unusual interface that looks foreign for users
coming from GitHub background.
Some SourceHut projects employ an approach to use Github-compatible
terminology and link to the corresponding Sourcehut pages:
[Issues] [Pull requests] [Discussions] [Wiki]
I suggest doing
Tim Wichmann writes:
> during last OrgMeetup, I proposed a new user option
> `org-refile-bookmark', similar to the already existing option
> `org-capture-bookmark'. Setting this new option to nil, `org-refile’
> would not create a bookmark when refiling. (Use case: I am using
> alphapapa's
"Rick Lupton" writes:
>> It looks like we cannot simply rely on narrowing to determine the
>> created heading level.
>
> I think you're right. I have extended `org-link-search' to accept an
> optional argument describing the org element where newly created headings
> should go as subheadings.
On 03/02/2024 03:03, Ihor Radchenko wrote:
Max Nikulin writes:
#+setupfile: http://localhost:8000/setup-1234567890.org
I am trying to decline attempts to download the remote resource by
hitting "n" (skip), but Org still tries to fetch that file and does it
twice. I see in the *Messages*
On 08/02/2024 00:10, Ihor Radchenko wrote:
Max Nikulin writes:
It is a bit more tricky. Current file may be remote as well. Browsers
have concept of same origin for applying security and privacy measures.
Org needs something similar.
May you please elaborate?
Consider a file opened as
On Sat, 3 Feb 2024, at 1:10 PM, Ihor Radchenko wrote:
> I'd prefer to avoid using global variables here.
> `org-entry-property-inherited-from' dates to pre-lexical binding times
> and is a potential source of subtle bugs if several `org-entry-get'
> calls happen unexpectedly to the code, changing
On Sat, 3 Feb 2024, at 1:10 PM, Ihor Radchenko wrote:
> In my testing, I used #+name: as link target.
> However, what I missed is that #+name targets are matched even when
> `org-link-search-must-match-exact-headline' is set to 'query-to-create.
> The docstring is not accurate there and must be
23 matches
Mail list logo
