Re: [GSoC] A late proposal: a modern send-email

[惠轶群 <huiyiqun@gmail.com>]

2016-03-26 17:52 GMT+08:00 惠轶群 <huiyiqun@gmail.com>:
> 2016-03-26 14:18 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
>> On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 <huiyiqun@gmail.com> wrote:
>>> 2016-03-26 2:16 GMT+08:00 Junio C Hamano <gitster@pobox.com>:
>>>> 惠轶群 <huiyiqun@gmail.com> writes:
>>>>
>>>>> # Purpose
>>>>> The current implementation of send-email is based on perl and has only
>>>>> a tui, it has two problems:
>>>>> - user must install a ton of dependencies before submit a single patch.
>>>>> - tui and parameter are both not quite friendly to new users.
>>>>
>>>> Is "a ton of dependencies" true?  "apt-cache show git-email"
>>>> suggests otherwise.  Is "a ton of dependencies" truly a problem?
>>>> "apt-get install" would resolve the dependencies for you.
>>>
>>> There are three perl packages needed to send patch through gmail:
>>> - perl-mime-tools
>>> - perl-net-smtp-ssl
>>> - perl-authen-sasl
>>>
>>> Yes, not too many, but is it better none of them?
>>
>> Are you sure using a GUI does not have any dependencies?
>>
>>> What's more, when I try to send mails, I was first disrupted by
>>> "no perl-mime-tools" then by "no perl-net-smtp-ssl or perl-authen-sasl".
>>> Then I think, why not just a mailto link?
>>>
>>>>> # Plan
>>>>> So I propose to implement following:
>>>>> - Allow user to send mail via a [`mailto`
>>>>> link](https://en.wikipedia.org/wiki/Mailto). so that users could
>>>>> complete the mail in their favorite email clients such as gmail, mutt,
>>>>> alpine and even gmail for android through
>>>>
>>>> IIRC, GMail on Android is incapable of sending a "text/plain", so
>>>> that part may not fly well.
>>>
>>> Really? As much as I known, GMail on Android is capable of sending
>>> a "text/plain" while Inbox is not.
>>
>> How do you plan in integrating GMail on Android so that it can send
>> patches which exists on your computer?
>
> No, if you could have termux a try, you will find that it's suitable for simple
> development. it has a apt, so you could have clang, neovim, tmux, cmake
> and so on.
>
> In fact, I recently use my nexus 7 with termux as a portable
> development environment.
> A bluetooth keyboard is needed, of course.

This is not applicable to all people, but It make the git more free, isn't it?

>>>>> - Build a simple email client (maybe a web components based web app or
>>>>> wxwidgets based GUI client, they are both cross-platform) which is
>>>>> easy to use for sending patch without disrupting the mailbox format.
>>
>> I think introducing a GUI may lead to much more dependencies. Many git
>> developers already have perl packages in their system but they don't
>> have wxwidgets.
>
> wxwidgets seems not a good choice. But if I build the GUI via web app,
> I could import required js and css from Internet directly, so the users do
> not need the dependencies on their computer.
>
>>>> I suspect it would yield a better result if the plan were to update
>>>> a popular email client and make it possible to tell it to read an
>>>> existing text file (i.e. mbox) without corrupting its contents.
>>>> People do not have to learn a new mail client if done that way.
>>>
>>> Maybe a plugin? I'm not sure.
>>
>> You could make a plugin. That would simply things.
>>
>>> If above `mail-to` is implemented, user could just using any mail
>>> client, but a mail client adaptive for patch would be better:
>>> - Do not allow user to edit the diff part
>>> - always 'plan/text'
>>> - visual