Subject: bug#78823: [BUG] 31.0.50; org-babel-execute-src-block: Wrong type argument: integer-or-marker-p, nil

From: Philip Kaludercic <[email-masked]>
Date: Sun, 13 Jul 2025 19:08:18 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: Stefan Monnier <[email-masked]>
>> Cc: Ihor Radchenko <[email-masked]>,  Philip Kaludercic
>>  <[email-masked]>,  Michael Albinus <[email-masked]>,
>>   [email-masked],  [email-masked],  [email-masked]
>> Date: Sun, 13 Jul 2025 10:39:36 -0400
>> 
>> >> I am looking into this again, and I stumbled upon `package-report-bug'.
>> >> I am wondering if it can be used as a centralized command to submit bug
>> >> reports + provide an API for package to plug into.
>> >> This kind of idea sounds better than creating aliases outside the
>> >> package namespace.

In my eyes, that was the intention of that command.  By API you probably
mean that packages can support collecting and aggravating custom data?

My instinctual solution would be to use the package symbol and add a
property that may contain a function we can invoke (probably without any
arguments) to generate a part of the bug report.  The simplest solution
would just be to pass that function to the post-hooks argument of
`reporter-submit-bug-report'.

>> +1
>
> FWIW, I don't think a hook is a proper solution here.  Hooks are local
> to buffers and set up by major modes (otherwise a package-specific
> hook makes no sense), but no one said that a user will want to invoke
> the bug-reporting command from a buffer under that package's mode.
> And then there are packages that provide only minor modes if at all,
> and packages that provide a very long list of modes, etc.
>
> So on balance, I'd go with a command that asks the user about what
> package he/she wants to submit a bug report.  If we can intelligently
> guess the package, we can offer that as the default.  More automation
> should only be considered after we have enough experience.

Sounds good.