[ELPA] programmer-dvorak input method

[ELPA] programmer-dvorak input method

[Joakim Jalap]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

Hello party people!

I thought I'd give this another go. Attached is a file with a new input
method. Maybe somebody other than me will find it useful :). John
thought it would fit best in ELPA.

I have signed the FSF papers.

-- Joakim


[-- Attachment #2: programmer-dvorak.el --]
[-- Type: application/emacs-lisp, Size: 2806 bytes --]

Re: [ELPA] programmer-dvorak input method

[Eli Zaretskii]

> From: Joakim Jalap <joakim.jalap@fastmail.com>
> Date: Mon, 28 Dec 2015 11:00:12 +0100
> 
> I thought I'd give this another go. Attached is a file with a new input
> method. Maybe somebody other than me will find it useful :). John
> thought it would fit best in ELPA.

Thanks.

Two comments:

 . Could you please expand the doc string so as to explain a bit more
   about the utility of this input method?  Who would like to use it
   and for what purposes?

 . I rather think that input methods should all be bundled: they are
   too small to justify a separate package, and too basic to ask users
   to download them when they need them.

Re: [ELPA] programmer-dvorak input method

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>  . I rather think that input methods should all be bundled: they are
>    too small to justify a separate package, and too basic to ask users
>    to download them when they need them.

I'm not against that, provided they need little maintenance after having been
added. Does this mean created an "extra-inputs" project on ELPA, into which
all these additions get added?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] programmer-dvorak input method

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Joakim Jalap <joakim.jalap@fastmail.com>,  emacs-devel@gnu.org
> Date: Mon, 28 Dec 2015 12:33:21 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >  . I rather think that input methods should all be bundled: they are
> >    too small to justify a separate package, and too basic to ask users
> >    to download them when they need them.
> 
> I'm not against that, provided they need little maintenance after having been
> added. Does this mean created an "extra-inputs" project on ELPA, into which
> all these additions get added?

If that question was for me, I'm not sure I understand it.

Re: [ELPA] programmer-dvorak input method

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> >  . I rather think that input methods should all be bundled: they are
>> >    too small to justify a separate package, and too basic to ask users
>> >    to download them when they need them.
>> 
>> I'm not against that, provided they need little maintenance after having been
>> added. Does this mean created an "extra-inputs" project on ELPA, into which
>> all these additions get added?

> If that question was for me, I'm not sure I understand it.

It was for you. So I'll just ask back: What were you suggesting the answer be
to your point above?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] programmer-dvorak input method

[Joakim Jalap]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> >  . I rather think that input methods should all be bundled: they are
>>> >    too small to justify a separate package, and too basic to ask users
>>> >    to download them when they need them.
>>> 
>>> I'm not against that, provided they need little maintenance after having been
>>> added. Does this mean created an "extra-inputs" project on ELPA, into which
>>> all these additions get added?
>
>> If that question was for me, I'm not sure I understand it.
>
> It was for you. So I'll just ask back: What were you suggesting the answer be
> to your point above?

If I may be so bold as to speak for Eli, what I _think_ he meant was
that input methods should be bundled with "core" Emacs, and not reside
in ELPA, since they impose no maintenance burden. And personally I think
that sounds good. :)

But I'm new to the game, so I leave it up to you guys to make the best
decision :)

Re: [ELPA] programmer-dvorak input method

[Eli Zaretskii]

> From: Joakim Jalap <joakim.jalap@fastmail.com>
> Date: Tue, 29 Dec 2015 09:31:57 +0100
> 
> John Wiegley <jwiegley@gmail.com> writes:
> 
> >>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> >  . I rather think that input methods should all be bundled: they are
> >>> >    too small to justify a separate package, and too basic to ask users
> >>> >    to download them when they need them.
> >>> 
> >>> I'm not against that, provided they need little maintenance after having been
> >>> added. Does this mean created an "extra-inputs" project on ELPA, into which
> >>> all these additions get added?
> >
> >> If that question was for me, I'm not sure I understand it.
> >
> > It was for you. So I'll just ask back: What were you suggesting the answer be
> > to your point above?
> 
> If I may be so bold as to speak for Eli, what I _think_ he meant was
> that input methods should be bundled with "core" Emacs, and not reside
> in ELPA

Yes, that's what I meant.  Sorry for my ambiguous wording.

Re: [ELPA] programmer-dvorak input method

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> If I may be so bold as to speak for Eli, what I _think_ he meant was
>> that input methods should be bundled with "core" Emacs, and not reside
>> in ELPA

> Yes, that's what I meant.  Sorry for my ambiguous wording.

Ah, OK, that's fine with me then.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: [ELPA] programmer-dvorak input method

[Joakim Jalap]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>
>  . Could you please expand the doc string so as to explain a bit more
>    about the utility of this input method?  Who would like to use it
>    and for what purposes?
>

Thanks for the feedback. :)

Is this better?


[-- Attachment #2: programmer-dvorak.el --]
[-- Type: application/emacs-lisp, Size: 2869 bytes --]

Re: [ELPA] programmer-dvorak input method

[Eli Zaretskii]

> From: Joakim Jalap <joakim.jalap@fastmail.com>
> Date: Tue, 29 Dec 2015 09:15:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >
> >  . Could you please expand the doc string so as to explain a bit more
> >    about the utility of this input method?  Who would like to use it
> >    and for what purposes?
> >
> 
> Thanks for the feedback. :)
> 
> Is this better?

Yes, thanks.

Re: [ELPA] programmer-dvorak input method

[Eli Zaretskii]

> From: Joakim Jalap <joakim.jalap@fastmail.com>
> Date: Tue, 29 Dec 2015 09:15:25 +0100
> 
> >  . Could you please expand the doc string so as to explain a bit more
> >    about the utility of this input method?  Who would like to use it
> >    and for what purposes?
> >
> 
> Thanks for the feedback. :)
> 
> Is this better?

Thanks, pushed to emacs-25.

(I deleted the autoload cookie at the end, since it's not needed --
leim-list.el defines it automatically.)

Re: [ELPA] programmer-dvorak input method

[joakim.jalap]

Thanks! That's my first contribution!

Time to break out the bubbly!

On Thu, Dec 31, 2015, at 05:04 PM, Eli Zaretskii wrote:
> > From: Joakim Jalap <joakim.jalap@fastmail.com>
> > Date: Tue, 29 Dec 2015 09:15:25 +0100
> > 
> > >  . Could you please expand the doc string so as to explain a bit more
> > >    about the utility of this input method?  Who would like to use it
> > >    and for what purposes?
> > >
> > 
> > Thanks for the feedback. :)
> > 
> > Is this better?
> 
> Thanks, pushed to emacs-25.
> 
> (I deleted the autoload cookie at the end, since it's not needed --
> leim-list.el defines it automatically.)