> You are right, I mention that elsewhere but forgot to do so here and in
> the commentary.  Do you think the package should be renamed to avoid
> further confusion?

I don't think names matter enough to warrant renaming, no.


        Stefan

Hi Philip,

ELPA update [2023-03-26 17:02:26] wrote:
> Version 0.1.1 of package Auto-Header has just been released in GNU ELPA.
> You can now find it in M-x list-packages RET.
>
> Auto-Header describes itself as:
>
>   ====================================
>   Automatically find the right headers
>   ====================================
>
> More at https://elpa.gnu.org/packages/auto-header.html
>

>> I think keeping the two separate is easier for maintenance.  Otherwise
>> there will be too much for me to take care of.

The main benefit is for the end-users (and often for the longer-term maintenance).

>> In theory, we can have an indeterminate number of Denote extensions:
>> some small, some large.  How useful those are depends on the user's
>> preferences and requirements.  Setting a precedent where we keep those
>> decoupled from the "core" will help us avoid uncertainty.
>
> I agree. Any updates regarding the inclusion of denote-menu into elpa?

Sorry, I'm more reactive than proactive these days.
I just added it to elpa.git, it should appear in GNU(-devel) ELPA

>>> Hmm... I don't know what was the problem, but running the script
>>> manually did build the tarball.  So the immediate problem is fixed but
>>> its source probably not, so keep an eye out for next time.
>>
>> Okay, thanks. For my packages I haven't observed any issues so I wonder
>> why TMR would be the odd one out. Then there is the issue that the
>> modus-themes 4 don't seem to build. But you are probably already aware
>> of that.
>
> I have been meaning to look into the modus-themes error, but haven't
> found the time for it.  Sorry!
>
> I don't know if there is any correlation here as, for example, my
> 'substitute' and 'fontaine' package did build properly in the last few

> I'll let you know when I find out a bit more about what's going on.

Hmm... I don't know what was the problem, but running the script
manually did build the tarball.  So the immediate problem is fixed but
its source probably not, so keep an eye out for next time.


        Stefan

Daniel Mendler [2023-01-28 11:39:39] wrote:
> Still stuck at 2023-01-01: https://elpa.gnu.org/devel/tmr.html

Hmm... Indeed.

I see that elpa.gnu.org saw the update, but the "rebuild" script
doesn't say anything about tmr, so it not only didn't fail but it didn't
even try to rebuild the tarball.  That's a new one.

I'll let you know when I find out a bit more about what's going on.


        Stefan

> `denote-menu' is an extension to the elpa package `denote' and provides
> an interface for viewing your denote files that goes beyond using the
> standard `dired' emacs command to view your `denote-directory'.

Sounds very nice, but I wonder if it wouldn't be nicer to integrate it
directly into the `denote` package so users don't need to install this
additional package.


        Stefan

> Now we have long log messages displayed as <pre class>
> ```
> <pre class="commit">Revert some code to Mako templates (see <a
> href="https://todo.sr.ht/~somenxavierb/cagen-tasks/21)">https://todo.sr.ht/~somenxavierb/cagen-tasks/21)</a></pre>
> ```

FWIW, the log message format recommended by the GNU coding standards
suffers from refilling operations if you treat it as "just human text".
Also commit messages occasionally contain quoted code samples.

There's a good case to be made that commit messages should abide by
a lightweight markup format like Markdown, so they can be prettified and
adjusted to narrow screens, but I don't know how to get there.

Nguyễn Gia Phong [2022-12-11 01:24:53] wrote:
> On 2022-12-10 at 10:22-05:00, Stefan Monnier wrote:
>> > Wouldn't Emacs benefit from [CI email hook]
>> > for every installed change?
>> For Emacs, yes.  For many of my own repos,
>> no (e.g. ones used to host research papers).
> I wonder for private repos like these, if it'd be better to have a
> client pre-push hook that formats patches between local and remote
> and sends them to collaborators.

I suspect nowadays most people have an email setup which does not allow
a batch script to send email (because of the need for SMTP AUTH).

>>[ Another reason I'm interested is that I'm playing with sr.ht to see
>>  a bit how it would work for Emacs development, and currently we send
>>  such email notifications to a public mailing list and we'd like to
>>  keep that functionality.  ]
> For the Emacs case, if you host your own sr.ht instance you could add any
> git hooks you want to your service.

Good point.  Doesn't help for my own personal use-case, OTOH.

> It's not as convenient as getting the hosted service publicly.

[ My impression is that hosting sr.ht is a fair bit of work, so I'm not
  completely sure how that will work: we'd need someone to volunteer to
  set it up and maintain it, but I haven't heard anyone step up yet.  ]