From: Philip Kaludercic <philipk@posteo.net>
To: Manuel Giraud <manuel@ledu-giraud.fr>
Cc: Manuel Giraud via "Emacs development discussions." <emacs-devel@gnu.org>
Subject: Re: [ELPA] new single file package: mpdired.el
Date: Fri, 08 Mar 2024 11:26:22 +0000 [thread overview]
Message-ID: <877cid55i9.fsf@posteo.net> (raw)
In-Reply-To: <878r2tug4b.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Fri, 08 Mar 2024 12:17:56 +0100")
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
next prev parent reply other threads:[~2024-03-08 11:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 9:26 [ELPA] new single file package: mpdired.el Manuel Giraud via Emacs development discussions.
2024-03-08 10:25 ` Philip Kaludercic
2024-03-08 11:17 ` Manuel Giraud via Emacs development discussions.
2024-03-08 11:26 ` Philip Kaludercic [this message]
2024-03-08 12:22 ` Manuel Giraud via Emacs development discussions.
2024-03-08 13:18 ` Philip Kaludercic
2024-03-08 16:25 ` Manuel Giraud via Emacs development discussions.
2024-03-08 16:34 ` Philip Kaludercic
2024-03-08 17:06 ` Manuel Giraud via Emacs development discussions.
2024-03-08 17:29 ` Philip Kaludercic
2024-03-09 13:18 ` Manuel Giraud via Emacs development discussions.
2024-03-09 13:36 ` Philip Kaludercic
2024-03-10 16:00 ` Manuel Giraud via Emacs development discussions.
2024-03-10 17:03 ` Philip Kaludercic
2024-03-10 17:43 ` Manuel Giraud via Emacs development discussions.
2024-03-10 17:49 ` Manuel Giraud via Emacs development discussions.
2024-03-10 18:03 ` Manuel Giraud via Emacs development discussions.
2024-03-10 18:15 ` Philip Kaludercic
2024-03-10 19:24 ` Eli Zaretskii
2024-03-11 8:44 ` Manuel Giraud via Emacs development discussions.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877cid55i9.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=emacs-devel@gnu.org \
--cc=manuel@ledu-giraud.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).