Re: [ELPA] new single file package: mpdired.el

[Philip Kaludercic]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
> First thanks for your all your inputs!
>
> [...]
>
>> In the end a Git repository will have to be created.  I don't think one
>> should have to be ashamed of the commit history (most people won't
>> care), but it is also fine to discard the current history and replace it
>> with a fresh repository.
>
> Ok.  Maybe I'll start with a fresh history if I feel like it.
>
>> By default, we would like to mirror some external repository.  It
>> doesn't have to be hosted by some large Git forge, just something that
>> can be synchronised regularly.  The alternative to this would be to have
>> a branch in elpa.git that would have to be manually updated (either by
>> yourself if you get access to the repository, or by someone here on the
>> mailing list with access that would see your message).  You can imagine
>> that we want to avoid the latter setup, since it creates more
>> friction.
>
> Of course, I'd also like to avoid this latter setup.  Just to be sure,
> you confirm that a git repo is unavoidable?  Could it be a just tarball
> available on web server?

Technically yes, but the ELPA build system would have to be updated just
for this use-case.

>> From experience, it is usually helpful to have a Git repository with
>> multiple files, for files like a README or an .elpaignore file or if you
>> decide to split up the file into multiple files at some point.
>
> Yes, you're right maybe I'd like to add a texinfo later for instance.
>
>> If you dislike Github, you could also take a look at Sourcehut or
>> Codeberg for hosting.
>
> Ok.  If a git forge is mandatory, I'll ponder which one I'd prefer to
> use.

As I said, a git forge in that sense is not necessarily needed, you
could also just host the git repository from some website over https://.

>>> Anyway for the braves and curious, here is the current version of this
>>> package.  It is called MPDired and is yet another client to Music Player
>>> Daemon.  It features a Dired-like user interface.  Previously I was a
>>> Mingus user so MPDired might have some legacy to it.
>>
>> Here some comments
>
> For the rest of your comments inline, I'll just ask on those I don't
> understand.
>
> [...]
>
>>>   "n"      #'mpdired-next-line
>>>   "<down>" #'mpdired-next-line
>>
>> Perhaps one could also rebind a few commands here, like `next-line'.
>
> I don't understand what you mean here.

It is possible to remap a command, without having to bind a key.  See
(elisp) Remapping Commands.  The advantage is that if the user has any
custom bindings, say for next-line, then they would automatically be
inherited.  That is comfortable from a user-perspective, because the
major-mode aligns more with their usual intuition.

> [...]
>
>>> (defun mpdired-change-marks (&optional old new)
>>>   "Changes mark from OLD to NEW.  It asks the user for OLD and NEW."
>>>   (interactive
>>>    (let* ((cursor-in-echo-area t)
>>>       (old (progn (message "Change (old mark): ") (read-char)))
>>>       (new (progn (message  "Change %c marks to (new mark): " old)
>>>                   (read-char))))
>>
>> Why not use read-char's PROMPT argument?
>
> I did not know about it and it is copy-pasto from dired ;-)

I don't know if there are any peculiar edge-cases either, perhaps
someone else knows more?

> Thanks.

-- 
        Philip Kaludercic on peregrine