Re: Org mode version 9.7-pre (9.7-pre-n/a-g093879

[Jason May]

I think you're right.

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.

For more significant syntax violations such as your example, perhaps
org-entry-get and other functions should raise errors instead of
silently returning nil?

I'm going to investigate how it might be possible to initiate an org-
lint if an exception situation was to arise in org-journal.




On February 7, 2024, Ihor Radchenko  wrote:
> Jason May  writes:
>
> > Extraneous content (e.g. blank lines) in the PROPERTIES drawer
> > cause =org-entry-get= to return nil without indication of any
> problem.
> >
> > Desired behavior: =org-entry-get= should be forgiving.
> > It should ignore blank PROPERTIES lines, or any line with invalid
> > syntax.
> > A message to the *Warnings* buffer might be appropriate.
>
> Blank lines in properties might be an ok change.
> I am not so sure about invalid syntax.
>
> Consider
>
> :PROPERTIES:
> :PROP1: val1
> :PROP2: this line was
> accidentally modified
> :END:
>
> Property drawer not being recognized is more likely to be noticed
> compared to `org-entry-get' returning incomplete "this line was".
>
> In any case, M-x org-lint will report problems with property drawers.
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Jack Kamm]

Ihor Radchenko  writes:

>> I agree that it would be good to redesign it, but am not sure where to
>> start.
>
> For example,
>
> 1. Change `org-babel-comint-async-register' to return UUID and to store
>PARAMS as passed by the backend (current approach with PARAMS being
>derived from src blocks prevents backends to transform src block
>PARAMS dynamically).
> 2. Change `org-babel-insert-result' to handle :async t specially,
>inserting something reliable, like #+async:  in place of result
>without performing extra transformations.
> 3. Change `org-babel-insert-result' to accept an internal parameter
>that will make it replace #+async:  keyword rather than perform
>normal result insertion.
> 4. Change `org-babel-comint-async-filter' to use the previously passed
>PARAMS, remove :async t from them, and arrange the call to
>`org-babel-insert-result' to replace the #+async:  keyword.

That all sounds reasonable...if you work on this, let me know if you
want any help with testing.

Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Jack Kamm]

Bruno Barbier  writes:

> FWIW, I've been trying to use asynchronous blocks for everything, not
> only the source blocks that are based on the comint mode.  I think it
> would be good if ob-core itself could provide an asynchronous API.  I've
> modified my Org so that it does have such an API.  This is work in
> progress; let me describe it.
>
> I've modified ob-core itself to allow asynchronicity.  In the
> asynchrosous case, instead of calling:
>
>   (org-babel-execute:LANG body params)
>
> I'm calling:
>
>   (org-babel-schedule:LANG body params handle-result)
>
> where `org-babel-schedule:LANG' is in charge of calling `handle-result'
> with the result (or the error) when it is known; `handle-result' takes
> care to call `org-babel-insert-result' at the correct place (and
> `org-babel-insert-result' is only called with a real result).

Sounds interesting, a couple questions:

1. Which languages have you implemented/tested this on?

2. Does it apply for sessions, nonsessions, or both?

> While the execution is pending, I'm using the same technique that Org is
> using when a source block is being edited: the result is left untouched,
> but below an overlay.  The overlay is used to know where to insert the
> result and to display the status/progress of the execution.  If the file
> is closed and the execution fails, nothing is lost, the old result is
> still available.

Also interesting, I think it's worth exploring/testing this overlay idea
out. Does that mean that output is asynchronously printing into the Org
buffer? It sounds cool but I wonder if it might cause problems while
trying to edit another part of the buffer.

Re: Async Python src block behavior with :dir header property

[Jack Kamm]

Ihor Radchenko  writes:

> +(defun org-babel-session-buffer ( info)
> +  "Return buffer name for session associated with current code block.
> +Return nil when no such live buffer with process exists.
> +When INFO is non-nil, it should be a list returned by
> +`org-babel-get-src-block-info'.
> +This function uses org-babel-session-buffer: function to
> +retrieve backend-specific session buffer name."
> +  (when-let* ((info (or info (org-babel-get-src-block-info 'no-eval)))
> +  (lang (nth 0 info))
> +  (session (cdr (assq :session (nth 2 info
> +  (cmd (intern (concat "org-babel-session-buffer:" lang)))
> +  buffer-name)

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)

Also, make shows a byte-compiler warning about this:

  Compiling 
/home/jack/src/org-mode/2024-01-async-file-results-dir/lisp/ob-core.el...
  
  In org-babel-session-buffer:
  ob-core.el:785:15: Warning: reference to free variable ‘buffer-name’

Re: help with gnus-icalendar.el and orgmode agenda

[Stephen J. Eglen]

> <2024-02-22 18:30-20:00> is a valid timestamp. Agenda not handling it is
> an oversight that should be fixed.

Thanks for checking this.  If the agenda could parse these, great.
However, with a workaround (C-c C-c on the timestamp), I can handle this 
for now.

Incidentally, org-lint says the following:

  4422 low   Potentially malformed timestamp <2024-02-22 18:30-20:00>.
  Parsed as: <2024-02-22 Thu 18:30-20:00>

which helped me catch a few other timestamps.

Best wishes,

Stephen

Re: Translation of the Org mode manual (was: Translation of manuals (was: SES manual French translation))

[Ihor Radchenko]

Richard Stallman  writes:

> Using Org format for the source of a document, and converting it to
> texi for processing (for instance, through TeX) would be a fine method
> to use, if it worked.  But it doesn't actually work.
>
> The problem is that it cannot work, given Org format as it exists now.
> It cannot properly represent manuals that use the GNU standard style
> because it does not have ways to represent all the distinctions that
> are needed.
> ...

This is not true. We can generate a precise TeXinfo markup from Org
files even now using export snippets: @@texinfo:@@

So, Org mode manual in particular can be adapted if absolutely
necessary.

Another question is that having native Org mode constructs for
manual-specific markup would make things less verbose and ad-hoc. But
that question is out of scope of this particular discussion, which is
focused on translation tools.

> I would like Org format to be extended in this way.
>
> Texinfo format is often misunderstood.  People write GNU manuals
> without knowing of all these constructs, so they use the wrong
> construct.  If Org format were extended to do _the whole job_, we
> could convert all manuals to Org format once and for all.
>
> A few years ago I raised this idea, but nobody wanted to work on it.

Your idea is not forgotten. But the resources for Org mode development
are limited. In particular, I am currently not prioritizing adding
brand-new features in favour of helping contributors, improving the
existing functionality, and fixing the existing problems.

If somebody is interested to work on adding new Org mode features like
custom inline markup, please contact Org mode mailing list. We can guide
the volunteers through the contribution process and help with any
questions when they arise.
See https://orgmode.org/worg/org-contribute.html

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: help with gnus-icalendar.el and orgmode agenda

[Ihor Radchenko]

"Stephen J. Eglen"  writes:

> When I use this package on icalendar attachments, it creates entries
> that look like this:
>
> ...
><2024-02-22 18:30-20:00>
>
> Note that the timestamp DOES NOT include a day of the week.  With the
> default settings of org-time-stamp-formats, i.e. 
>
> ("%Y-%m-%d %a" . "%Y-%m-%d %a %H:%M")
>
> this means that the agenda does not show this entry -- which defeats the
> purpose of me saving the icalendar entry!  If I manually add the dayname
> then the agenda item appears.

<2024-02-22 18:30-20:00> is a valid timestamp. Agenda not handling it is
an oversight that should be fixed.

That said...

>(format "<%s %s-%s%s>" start-date start-time end-time repeat)
>
> which does not include the dayname.

could certainly be improved. Having a day name increases readability.
Also, we may change the format in future, adding time zones as well.
I recommend using `org-time-stamp-format' when creating Org mode
timestamps or even `org-element-timestamp-interpreter'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

help with gnus-icalendar.el and orgmode agenda

[Stephen J. Eglen]

hi,

I have the following snippet set up so that mu4e will parse icalendar
attachments and add them to an org file ... this seems to be the
standard prescription:

(when (fboundp 'gnus-icalendar-org-setup)
  (setq gnus-icalendar-org-capture-file "~/todo.org")
  (setq gnus-icalendar-org-capture-headline '("Calendar"))
  (gnus-icalendar-org-setup))

gnus-icalendar.el is part of Emacs, authored by Jan Tatarik (cc'ed).

When I use this package on icalendar attachments, it creates entries
that look like this:

** [#B] subject of email
:PROPERTIES:
:ICAL_EVENT: t
...
:END:

   <2024-02-22 18:30-20:00>

Note that the timestamp DOES NOT include a day of the week.  With the
default settings of org-time-stamp-formats, i.e. 

("%Y-%m-%d %a" . "%Y-%m-%d %a %H:%M")

this means that the agenda does not show this entry -- which defeats the
purpose of me saving the icalendar entry!  If I manually add the dayname
then the agenda item appears.

Looking inside gnus-icalendar.el, the relevant defun seems to be
gnus-icalendar-event--org-timestamp that creates the timestamp.
e.g. it includes this text to generate the timestamp:

   (format "<%s %s-%s%s>" start-date start-time end-time repeat)

which does not include the dayname.

What is the best way to improve this code?

Best wishes,

Stephen


 

Question regarding org-capture-bookmark and org-bookmark-names-plist

[Tim Wichmann]

Hi all,

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 org-bookmark-heading package and want to prevent that each
captured/refiled entry gets an id.)

I was just about to send the corresponding feature request when I
stumbled across the documentation of `org-bookmark-names-plist'.  It
states: „When a key does not show up in the property list, the
corresponding bookmark is not set.“

So, there is no need for a new user option: I simply have to remove the
:last-refile key from the plist, and no bookmark will be created on
refiling.

My question: Is this the intended way to suppress bookmark creation?  If
so: Why is there the extra user option `org-capture-bookmark'?  Isn't it
superfluous, as the same behavior can be achieved by removing the
:last-capture keyword from the plist?  (Note, moreover, that currently
the :last-capture-marker bookmark is created even in case
`org-capture-bookmark' is set to nil, see `org-refile'.)


Best regards,
  Tim.

Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bruno Barbier]

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>> While the execution is pending, I'm using the same technique that Org is
>> using when a source block is being edited: the result is left untouched,
>> but below an overlay.  The overlay is used to know where to insert the
>> result and to display the status/progress of the execution.  If the file
>> is closed and the execution fails, nothing is lost, the old result is
>> still available.
>>
>> If that technique looks safe enough and interesting, I can prepare a set
>> of patches so that we can discuss it further and, maybe, add it in Org.
>
> Using overlay also sounds good.
>
> I am wondering what you do when there is no result yet or when user
> edits whatever is under the overlay,
> but that's just a technical detail.

I don't think it's really robust yet. We'll see how to improve/change
it.

I'll prepare the set of patchs.


Bruno


>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Christopher M. Miles]

+1!

Ihor Radchenko  writes:

> I conclude that `org-no-popups' and `org-switch-to-buffer-other-window'
> should not be used in Org mode.
>
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=78dc58508
>
> Other issues raised in this thread need more thought.


-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [BUG] Org may fetch remote content without asking user consent

[Ihor Radchenko]

Max Nikulin  writes:

> On 07/02/2024 23:12, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> #+setupfile: /dav:localhost#8000:/msg-123456.org
> [...]
>> I think we can enable checking for anything where `file-remote-p'
>> returns non-nil.

> ... In addition, TRAMP locations should be 
> checked against `org-safe-remote-resources' as well.

This is what I propose. `file-remote-p' will return non-nil on TRAMP locations.

> 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?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Org mode version 9.7-pre (9.7-pre-n/a-g093879

[Ihor Radchenko]

Jason May  writes:

> Extraneous content (e.g. blank lines) in the PROPERTIES drawer
> cause =org-entry-get= to return nil without indication of any problem.
>
> Desired behavior: =org-entry-get= should be forgiving.
> It should ignore blank PROPERTIES lines, or any line with invalid
> syntax.
> A message to the *Warnings* buffer might be appropriate.

Blank lines in properties might be an ok change.
I am not so sure about invalid syntax.

Consider

:PROPERTIES:
:PROP1: val1
:PROP2: this line was
accidentally modified
:END:

Property drawer not being recognized is more likely to be noticed
compared to `org-entry-get' returning incomplete "this line was".

In any case, M-x org-lint will report problems with property drawers.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org element cache had to reset [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Neil MacLaren]

Thanks, Ihor! I have upgraded Org and will send another bug report if I
have further trouble.

Thanks,

Neil

On Wed, Feb 7, 2024 at 11:28 AM Ihor Radchenko  wrote:

> Neil MacLaren  writes:
>
> > What exactly did I do?
> >
> > I was trying to fix deadlines for repeating tasks in an org buffer by
> hand.
> > I then tried to reload my Org Agenda and it wouldn't load. I tried pkill
> > -SIGUSR2 emacs but didn't understand the error messages. I narrowed the
> > problem down to a specific file but couldn't get past that. Then, I
> reload
> > emacs again (probably the fourth or fifth time I had done so) and got
> this
> > message:
> >
> > ⛔ Warning (org-element-cache): org-element--cache: Org parser error in
> > admin-tasks.org::53243. Resetting.
> >  The error was: (wrong-type-argument integer-or-marker-p nil)
> >  Backtrace:
> > nil
> >  Please report this to Org mode mailing list (M-x org-submit-bug-report).
> >
> > I don't know if I can get you all a backtrace, though, because Emacs and
> > Org Mode are working now.
> >
> > I know this isn't a great bug report, but I hope it helps. System info
> > below.
>
> Thanks for reporting!
> We had known parser errors in Org 9.6.6.
> Some of them have been fixed in the latest stable Org 9.6.18 and some
> other have been fixed on the development version Org 9.7-pre.
>
> If you can, please upgrade Org mode and let us know if you keep seeing
> this or similar warnings.
>
> Handled.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] Org may fetch remote content without asking user consent

[Max Nikulin]

On 07/02/2024 23:12, Ihor Radchenko wrote:

Max Nikulin writes:


#+setupfile: /dav:localhost#8000:/msg-123456.org

[...]

I think we can enable checking for anything where `file-remote-p'
returns non-nil.


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. In addition, TRAMP locations should be 
checked against `org-safe-remote-resources' as well.

Re: [BUG] Org element cache had to reset [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Neil MacLaren  writes:

> What exactly did I do?
>
> I was trying to fix deadlines for repeating tasks in an org buffer by hand.
> I then tried to reload my Org Agenda and it wouldn't load. I tried pkill
> -SIGUSR2 emacs but didn't understand the error messages. I narrowed the
> problem down to a specific file but couldn't get past that. Then, I reload
> emacs again (probably the fourth or fifth time I had done so) and got this
> message:
>
> ⛔ Warning (org-element-cache): org-element--cache: Org parser error in
> admin-tasks.org::53243. Resetting.
>  The error was: (wrong-type-argument integer-or-marker-p nil)
>  Backtrace:
> nil
>  Please report this to Org mode mailing list (M-x org-submit-bug-report).
>
> I don't know if I can get you all a backtrace, though, because Emacs and
> Org Mode are working now.
>
> I know this isn't a great bug report, but I hope it helps. System info
> below.

Thanks for reporting!
We had known parser errors in Org 9.6.6.
Some of them have been fixed in the latest stable Org 9.6.18 and some
other have been fixed on the development version Org 9.7-pre.

If you can, please upgrade Org mode and let us know if you keep seeing
this or similar warnings.

Handled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Fix org-agenda-skip-scheduled-if-deadline-is-shown bug

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> No response from Bastien.
>
> Yes, sorry for that. In general, don't wait for my answer unless you
> really needed it: you've got pre-approval as co-maintainer, I don't
> want my current lack of availability to be a blocker.

No blocker here. In this particular case, the question was not to
Bastien the maintainer, but to Bastien the committer :) Because you
could remember details about the discussed feature that I cannot easily
derive from the list archives.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Fix org-agenda-skip-scheduled-if-deadline-is-shown bug

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> No response from Bastien.

Yes, sorry for that. In general, don't wait for my answer unless you
really needed it: you've got pre-approval as co-maintainer, I don't
want my current lack of availability to be a blocker.

Thanks,

-- 
 Bastien Guerry

Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Bruno Barbier  writes:

> FWIW, I've been trying to use asynchronous blocks for everything, not
> only the source blocks that are based on the comint mode.  I think it
> would be good if ob-core itself could provide an asynchronous API.  I've
> modified my Org so that it does have such an API.  This is work in
> progress; let me describe it.
>
> I've modified ob-core itself to allow asynchronicity.  In the
> asynchrosous case, instead of calling:
>
>   (org-babel-execute:LANG body params)
>
> I'm calling:
>
>   (org-babel-schedule:LANG body params handle-result)
>
> where `org-babel-schedule:LANG' is in charge of calling `handle-result'
> with the result (or the error) when it is known; `handle-result' takes
> care to call `org-babel-insert-result' at the correct place (and
> `org-babel-insert-result' is only called with a real result).

LGTM.

> While the execution is pending, I'm using the same technique that Org is
> using when a source block is being edited: the result is left untouched,
> but below an overlay.  The overlay is used to know where to insert the
> result and to display the status/progress of the execution.  If the file
> is closed and the execution fails, nothing is lost, the old result is
> still available.
>
> If that technique looks safe enough and interesting, I can prepare a set
> of patches so that we can discuss it further and, maybe, add it in Org.

Using overlay also sounds good.

I am wondering what you do when there is no result yet or when user
edits whatever is under the overlay, but that's just a technical detail.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org may fetch remote content without asking user consent

[Ihor Radchenko]

Max Nikulin  writes:

> Consider the following .org file:
>
> --- 8< ---
> #+setupfile: /dav:localhost#8000:/msg-123456.org
> --- >8 ---
>
> When Emacs opens it, HTTP server (plain HTTP, not WebDAV is used for 
> test) logs contain
> ...
> Emacs *Messages* buffer:
>
> Tramp: Opening connection for localhost using dav...failed
> ...
> No dialog whether the file should be downloaded is displayed.
>
> My expectation is that Org should not connect to remote servers in 
> default configuration unless it is explicitly approved by the user.

We only protect from files matching `org-url-p'.
TRAMP files are not checked.

I think we can enable checking for anything where `file-remote-p'
returns non-nil.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Invalid capture datetree capture templates (newly introduced) [9.7-pre (release_9.6.18-1145-g10d286 @ /home/jds6696/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Justin Silverman  writes:

> I have been using the same capture templates for years now without problem. 
> Recently updated org and noticed a new bug.
>
> Example: the following capture template now produces an error:
> let: Invalid capture target specification: (file+olp+datetree 
> "~/Dropbox/org/mtx-michelle.org")
>
> ("mp" "meeting psu" entry (file+olp+datetree "~/Dropbox/org/meetings_psu.org")
>  "* MEETING %u with %? :MEETING:\n "
>  :jump-to-captured t
>  :tree-type month)

> Org no longer allows the third argument in (file+olp+datetree 
> "~/Dropbox/org/meetings_psu.org") to be omitted. Everything works if I embed 
> the datetree under a headline "foo" and make the capture template

Duplicate of https://list.orgmode.org/878r3xfm90.fsf@localhost/T/#t
Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] Invalid capture datetree capture templates (newly introduced) [9.7-pre (release_9.6.18-1145-g10d286 @ /home/jds6696/.emacs.d/straight/build/org/)]

[Justin Silverman]

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



Your bug report will be posted to the Org mailing list.


I have been using the same capture templates for years now without problem. 
Recently updated org and noticed a new bug.

Example: the following capture template now produces an error:
let: Invalid capture target specification: (file+olp+datetree 
"~/Dropbox/org/mtx-michelle.org")

("mp" "meeting psu" entry (file+olp+datetree "~/Dropbox/org/meetings_psu.org")
   "* MEETING %u with %? :MEETING:\n "
   :jump-to-captured t
   :tree-type month)

Org no longer allows the third argument in (file+olp+datetree 
"~/Dropbox/org/meetings_psu.org") to be omitted. Everything works if I embed 
the datetree under a headline "foo" and make the capture template


("mp" "meeting psu" entry (file+olp+datetree "~/Dropbox/org/meetings_psu.org" 
"foo")
   "* MEETING %u with %? :MEETING:\n "
   :jump-to-captured t
   :tree-type month)

Thanks!
Justin

Emacs  : GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.40, 
cairo version 1.18.0)
Package: Org mode version 9.7-pre (release_9.6.18-1145-g10d286 @ 
/home/jds6696/.emacs.d/straight/build/org/)

Re: [BUG] repeated warnings about org-element-at-point "cannot be used in non-Org buffer" [9.7 (9.7-??-57b94f3 @ /Users/cstevens/.emacs.d/.local/straight/build-29.2/org/)]

[Daniel Clemente]

Thanks, I replaced org-cycle/org-global-cycle with
outline-cycle/outline-cycle-buffer, and then the outlining works.

On Tue, 6 Feb 2024 at 18:56, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> > I also see the warnings. In my case it's because I'm using outline-minor
> > mode in an elisp file. I'm not sure it's supported, but it worked years
> > ago: ...
>
> It is not supported by Org mode.
> The modern outline mode has `outline-cycle'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [PATCH] Fix org-agenda-skip-scheduled-if-deadline-is-shown bug

[Ihor Radchenko]

Ihor Radchenko  writes:

> Right. This is because after 72c3f5e8e refactoring,
> `org-agenda-skip-scheduled-if-deadline-is-shown' is only respected when
> the deadline is actually shown.
>
> However, judging from the discussion of the original feature request
> (https://list.orgmode.org/cac10t-n8f+evxf7vgcmt48r5ovody030av1cj3xyx02pif0...@mail.gmail.com/T/#u),
> it looks like the purpose of 'repeated-after-deadline value is broader
> than just hiding scheduled record when the deadline record is actually
> in agenda. AFAIU, the purpose is hiding the scheduled information
> completely and unconditionally once the agenda day is beyond the
> deadline.
>
> But then `org-agenda-skip-scheduled-if-deadline-is-shown' does not look
> like the right place for this customization. It would make more sense to
> have a dedicated custom variable for this. WDYT?

No response from Bastien. I am going ahead with introducing a new custom
option. The old option is removed, but remains supported for backwards
compatibility.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b26745b98

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] Org may fetch remote content without asking user consent

[Max Nikulin]

Consider the following .org file:

--- 8< ---
#+setupfile: /dav:localhost#8000:/msg-123456.org
--- >8 ---

When Emacs opens it, HTTP server (plain HTTP, not WebDAV is used for 
test) logs contain


python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [07/Feb/2024 17:34:52] code 501, message Unsupported 
method ('OPTIONS')
127.0.0.1 - - [07/Feb/2024 17:34:52] "OPTIONS /msg-123456.org HTTP/1.1" 
501 -
127.0.0.1 - - [07/Feb/2024 17:34:52] code 501, message Unsupported 
method ('OPTIONS')
127.0.0.1 - - [07/Feb/2024 17:34:52] "OPTIONS /msg-123456.org HTTP/1.1" 
501 -


Emacs *Messages* buffer:

Tramp: Opening connection for localhost using dav...failed
Unable to read file "/dav:localhost#8000:/msg-123456.org"
Tramp: Opening connection for localhost using dav...failed
Unable to read file "/dav:localhost#8000:/msg-123456.org"

No dialog whether the file should be downloaded is displayed.

My expectation is that Org should not connect to remote servers in 
default configuration unless it is explicitly approved by the user.


I am unsure what user option may be changed to mitigate the issue.

- Debian 12 bookworm
- Org commit 18d98e
- gvfs-backends (dependency of gnome-core) package is installed