Link without the sentence-ending period being made part of the url https://github.com/rougier/svg-tag-mode/pull/61

Please consider merging the fix-tag-format branch.

It consists mostly of cleanup. I did that last year, but because I could never get this package to work, neither before nor after this cleanup, I did not submit it until now.

Now I have looked into it more and found the bugs that prevented this from working before.

The value returned by ushin-shapes--build-tag does not have the expected form. I have pushed a commit to fix that to the mentioned branch.

Additionally there is a regression in svg-tag-mode. You can find the pull-request for that at https://github.com/rougier/svg-tag-mode/pull/61.

Hey!

I've pushed some minor cleanup to the "silencio" branch. I've tested locally, but am unsure how I could test it on sourcehut, so I'm not pushing to "master" directly.

(I don't even know where I can find the build results for the "master" branch of this repository. Please add a link at https://todo.sr.ht/~ushin/ushin.)

By the way, the mentioned "extension to ox-texinfo" has been merged into Org a few releases ago.

I was wondering about the lambda that are allegedly needed to work around a regression in Emacs. The commit that mentioned that, did not add more information. What is the effect of that bug, and has it been reported?

When I suggested that we drop support for Emacs releases before 28.1 and start using shorthands, I mentioned that I don't think it's urgent that we do that.

I changed my mind. Last week, whenever I tried to work on Hyperdrive, I felt an irresistible urge to shorten long lines first, only to abort each time, because in some cases that would lead to some rather ugly line-wrapping. Personally I would still prefer that, but I understand that tastes are different.

A lot of that line wrapping won't be necessary anymore once we switch to using shorthands.

So I propose we do the following, as soon as possible, and in this order.

1. Merge the menu branch.
2. Merge other inflight branches.
3. Require Emacs 28.1 and remove old compatibility code.
4. Start using shorthands.
5. Shorten lines that are still too long.

I would be happy to do 4 and 5. I can also do 3, but if there is backward compatibility that is not explicitly marked as such, I might miss it, since I am not that familiar with the code yet. So someone else might want to do that part.

What do you think, now that you had a week to think about it -- has the time for Emacs 28 and shorthands come yet? I seemed you were all very much on board -- after all I was the only one who didn't want to do it immediately. ;)

I am generally very much in favor of "get the current thing of this kind, if this is at all possible in this context" functions, and then using them everywhere. This avoids having to re-implement such logic over and over, and having these competing implementations differ in correctness and functionality.

I recently improved such functions in Forge and would be interested in working on such functions in Hyperdrive too. Looking at hyperdrive--context-entry, that doesn't seem to cover much ground yet.

It also falls back to reading a drive if none is found. It probably would make sense to move that into a second function hyperdrive-select-entry, and to use that in commands' interactive forms. This function could support two modes of operation:

1. Always prompt for an entry, defaulting to the current entry.
2. If any, use the current entry without offering using completing-read or requiring confirmation. Else prompt for an entry.

And this could be made user customizable. I.e., we would pick a default for each command that uses this selection function, but users could add or remove commands from a list of commands that always prompt.

Consider automating the generation of function/command/variable documentation directly from their docstrings.

That might not be possible because the convention is to use the imperative mood in docstrings, while info manuals it is not. We seem to be following the respective conventions in both places already.

The extensions to ox-texinfo.el, which produce the above texi output, have been merged into org, and are documented in its manual. If you want to look at more examples, I suggest the transient manual.

However we don't use commands such as @defopt and @deffn, and we use free form lists to list key bindings.

Here is a short excerpt from magit's info manual, that shows what a key binding and an option is supposed to look like, when (more or less) following the conventions:

‘U’ (‘magit-unstage-all’)
     Remove all changes from the staging area.

 -- User Option: magit-unstage-committed
     This option controls whether ‘magit-unstage’ "unstages" committed
     changes by reversing them in the index but not the working tree.
     The alternative is to raise an error.

Writing even such simple definitions in texinfo is IMO unbearable:

@table @asis

[...]

@item @kbd{U} (@code{magit-unstage-all})
@kindex U
@findex magit-unstage-all
Remove all changes from the staging area.
@end table

@defopt magit-unstage-committed
This option controls whether @code{magit-unstage} "unstages" committed
changes by reversing them in the index but not the working tree.
The alternative is to raise an error.
@end defopt

which is why I use org instead. But writing it using the same constructs that are being used for org's own manual itself, is not much better.

So I have written an extension to ox-texinfo that accept some special formatting that looks very close to the eventual output in the info file, instead of like the intermediate mess in the texi file. The org source for the above info output is just this:

- Key: U (magit-unstage-all) ::

  Remove all changes from the staging area.

- User Option: magit-unstage-committed ::

  This option controls whether ~magit-unstage~ "unstages" committed
  changes by reversing them in the index but not the working tree.
  The alternative is to raise an error.

Friendly ping!

"~tarsius" outgoing@sr.ht writes:

Perfect, thanks!

Great!