mykie.el

mykie.el

[Ted Zlatanov]

I was intrigued by https://github.com/yuutayamada/mykie-el by Yato
Yamada (CC here).  It's GPL v3.

Here's an example of context-dependent usage:

(mykie:global-set-key "C-j"
   :default  '(progn
                (delete-trailing-whitespace)
                (case major-mode
                  (org-mode (org-return-indent))
                  (t        (newline-and-indent))))
   :C-u&eolp '(fill-region (point-at-bol) (point-at-eol))
   :region   'query-replace-regexp)

(many other keywords are available, e.g. :prog for activating only in
programming modes)
   
I think it's worth considering either making this part of
`global-set-key' or at least putting mykie.el in the Emacs core.  Unlike
most ELPA packages (GNU or otherwise), I think this one should be
available by default, like CUA.  I don't know if Yamada-san wants to
assign copyright and sign the Emacs contributor papers, but I hope he
does.

Ted

Re: mykie.el

[Bozhidar Batsov]

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

I was also intrigued by this package. Enhancing `global-set-key' in a
similar manner might be a huge win (after all - there are only so many good
keybindings available...).


On 3 January 2014 22:09, Ted Zlatanov <tzz@lifelogs.com> wrote:

> I was intrigued by https://github.com/yuutayamada/mykie-el by Yato
> Yamada (CC here).  It's GPL v3.
>
> Here's an example of context-dependent usage:
>
> (mykie:global-set-key "C-j"
>    :default  '(progn
>                 (delete-trailing-whitespace)
>                 (case major-mode
>                   (org-mode (org-return-indent))
>                   (t        (newline-and-indent))))
>    :C-u&eolp '(fill-region (point-at-bol) (point-at-eol))
>    :region   'query-replace-regexp)
>
> (many other keywords are available, e.g. :prog for activating only in
> programming modes)
>
> I think it's worth considering either making this part of
> `global-set-key' or at least putting mykie.el in the Emacs core.  Unlike
> most ELPA packages (GNU or otherwise), I think this one should be
> available by default, like CUA.  I don't know if Yamada-san wants to
> assign copyright and sign the Emacs contributor papers, but I hope he
> does.
>
> Ted
>
>
>

[-- Attachment #2: Type: text/html, Size: 1808 bytes --]

Re: mykie.el

[Yuta Yamada]

Hello emacssen, I'm author of the mykie.el.
I'm not sure this is correct way to reply this article.
Let's me know if this way is any problem by yours.


I'm glad someone interested about this package.
But about assigning copyright and signing the Emacs contributor papers is
I'm just worried whether I can keep developing at GitHub.
Is that ok? Or do I need something if I change this package's code?

Even if it's no, I don't care to assign copyright and sign the Emacs
contributor papers. But I'm just wondered.

BTW my name is Yuta Yamada. Not Yato.
(I'm not angry. don't worry Mr.Ted)

Yuta

Re: mykie.el, Re: mykie.el

[Ted Zlatanov]

On Fri, 03 Jan 2014 20:08:46 -0500 (EST) Yuta Yamada <cokesboy@gmail.com> wrote: 

YY> Hello emacssen, I'm author of the mykie.el.
YY> I'm not sure this is correct way to reply this article.
YY> Let's me know if this way is any problem by yours.

We got it :)

YY> I'm glad someone interested about this package.
YY> But about assigning copyright and signing the Emacs contributor papers is
YY> I'm just worried whether I can keep developing at GitHub.
YY> Is that ok? Or do I need something if I change this package's code?

Yes.  You need to have contributor papers on file, then your code can be
part of Emacs itself or in the GNU ELPA (enabled by default with Emacs,
unlike MELPA or Marmalade).

I am firmly in favor of putting mykie.el in the default set of packages
so new users can immediately use it.  I don't know how many others will
support this, and it may require some changes to the function calls and
to the internals.  But I'd love to show these examples in the Emacs docs
in addition to the current define-key examples that lack nuance.

This would happen after the code freeze in any case, so there's time.

The final approval rests with Stefan but I'm sure he will see reason ;)

YY> Even if it's no, I don't care to assign copyright and sign the Emacs
YY> contributor papers. But I'm just wondered.

Please do, I'm sure we'd love to have you in the developer group :)

YY> BTW my name is Yuta Yamada. Not Yato.
YY> (I'm not angry. don't worry Mr.Ted)

Heh heh.  I was careful but somehow wrote it wrong, sorry.

On Mon, 06 Jan 2014 00:31:23 -0500 Yuta Yamada <cokesboy@gmail.com> wrote: 

YY> Hello, mykie.el was updated recently to v0.1.1.
YY> Let's me introduce little bit to advance discussion.

YY> New version mykie can change order by each keybinds like this:

YY> (setq mykie:use-lazy-order t) ; <- this is requirement
YY> (mykie:set-keys nil ; <- nil means registering global-map
YY>    "C-0"
YY>    :default '(message "hi")
YY>    :C-u*2   '(message "howdy")
YY>    :C-u     '(message "hello")
YY>    :C-u*3   '(message "hey") ; <- you can't see
YY>    "C-1"
YY>    :default '(message "hi")
YY>    :C-u*3   '(message "howdy")
YY>    :C-u     '(message "hello")
YY>    :C-u*2   '(message "hey")) ; <- you can't see

YY> As you can see above example is reverse part of :C-u*2 and :C-u*3.
YY> This example is prior above :keyword and function pair without :default
YY> when you set t to `mykie:use-lazy-order'.
YY> So if you do this example, you can't execute C-0's :C-u*3 function and
YY> C-1's :C-u*2 function.
YY> Since mykie will execute :C-u's function.(:C-u*2 and :C-u*3 satisfy
YY> :C-u's condition too)

YY> This function can control order without conditional.
YY> I don't know how many people like this future,
YY> but I think it's easy to understand the function's structure.

I don't think it's a major difference for most users.  I think mykie.el
is primarily for beginners, who really need a simple way to define
context-sensitive keys without too much nuance.

YY> P.S. new version is added :err, :C-u&err, :region&err that activate
YY> function when current state have flymake or flycheck error too.

Oh that is *nice*.  Really nice.

Ted

enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams]

> GNU ELPA (enabled by default with Emacs, unlike MELPA or Marmalade).

Apropos: Why shouldn't GNU Emacs enable all three by default?

That would help GNU Emacs users more, I think.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

>> GNU ELPA (enabled by default with Emacs, unlike MELPA or Marmalade).
>
> Apropos: Why shouldn't GNU Emacs enable all three by default?
>
> That would help GNU Emacs users more, I think.

One easy answer is that MELPA and Marmalade are non under the control of
the Emacs prooject.

A more serious concern is that some (all?) of the packages MELPA offers
are development versions (i.e. unreleased, mostly untested). I know of
at least one case where unwary users obtained from MELPA a broken
package, causing much grief among users and developers alike.

RE: enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams]

> >> GNU ELPA (enabled by default with Emacs, unlike MELPA or
> >> Marmalade).
> >
> > Apropos: Why shouldn't GNU Emacs enable all three by default?
> >
> > That would help GNU Emacs users more, I think.
> 
> One easy answer is that MELPA and Marmalade are non under the
> control of the Emacs prooject.

So?  GNU Emacs is not responsible for whatever it might be that
those repos have or do.  And I think we (should) know by now
that most, if not all, of what they do can be helpful for Emacs
users.

> A more serious concern is that some (all?) of the packages MELPA
> offers are development versions (i.e. unreleased, mostly untested).

Even if that were true - so what?  And what's a "development
version"?  What does "unreleased" mean?  How tested is "tested"?

The fact that you would even think of writing "(all?)" is, I think,
indicative of how far off the mark you are on this.

> I know of at least one case where unwary users obtained from MELPA
> a broken package, causing much grief among users and developers
> alike.

So what?  See above.  GNU Emacs is not responsible for those repos
just because it might include their names in the list of repos 
available by default.  (If you want, provide a `parental-control'
command that lets a Mother Hen remove certain repos from the list
as a preventative measure. ;-))

When you buy a Samsung TV and it comes enabled for use by Netflix
(provided you subscribe), does that make Samsung responsible for
something that Netflix might offer?  Good luck with a law suit
that makes that claim.

Should `eww' give users access, by default, only to web sites
that GNU Emacs Dev (TM) has vetted ("tested", "released"...)?
Who will do all the vetting?

Think users, not lawyers.  This is not GNanny, or at least it
did not used to be.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Eric Brown]

Hi Drew,

Drew Adams <drew.adams@oracle.com> writes:

>> >> GNU ELPA (enabled by default with Emacs, unlike MELPA or
>> >> Marmalade).
>> >
>> > Apropos: Why shouldn't GNU Emacs enable all three by default?
>> >
>> > That would help GNU Emacs users more, I think.
>> 
>> One easy answer is that MELPA and Marmalade are non under the
>> control of the Emacs prooject.
>
> So?  GNU Emacs is not responsible for whatever it might be that
> those repos have or do.  And I think we (should) know by now
> that most, if not all, of what they do can be helpful for Emacs
> users.

I think this falls into the category of "should a GNU project recommend
repositories that contain non-free software?"

(vide, inter alia, "Real Men Do Not Attack Straw Men")

RMS and his defense of the FSF position (and composure in the face of
very shabby treatment) are remarkable.

> Should `eww' give users access, by default, only to web sites
> that GNU Emacs Dev (TM) has vetted ("tested", "released"...)?
> Who will do all the vetting?
>

If Emacs (or any GNU/FSF program) actively prevented the installation of
software, or surfing to a site of the users' choice, that would be
censorship.

It is another matter entirely to _recommend_ the software sites, because
the FSF believes that this constitutes some form of complicity in
leading someone astray. (Whether the end-user believes it is
immaterial.)

> Think users, not lawyers.  This is not GNanny, or at least it
> did not used to be.

It is trivial for a user to enable these repositories.

What is not trivial is endeavoring to maintain a libre software
installation, but having non-free repositories enabled.  It is truly
shocking that proprietary "feature-enhancing" extensions can get
installed onto a system by package managers, though the selected
software package (e.g. Chromium) was in fact libre.

From another perspective, it makes it difficult to develop software
systems for commercial purposes, because can't be sure that my company
can use for any purpose or redistribute the codes.  In principle, a repo
author may rise like a submarine, when he discovers that he could strike
it rich because of (unintended) license violations.  IANAL, but I
believe that unless otherwise stated, all rights are reserved.

Best regards,
Eric

RE: enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams]

Hi Eric,

> >> > Why shouldn't GNU Emacs enable all three by default?
> >> > That would help GNU Emacs users more, I think.
> >>
> >> One easy answer is that MELPA and Marmalade are non under the
> >> control of the Emacs prooject.
> >
> > So?  GNU Emacs is not responsible for whatever it might be that
> > those repos have or do.  And I think we (should) know by now
> > that most, if not all, of what they do can be helpful for Emacs
> > users.
> 
> I think this falls into the category of "should a GNU project
> recommend repositories that contain non-free software?"

Putting them in the available-by-default list does *not*
recommend them, IMO.  And it is certainly possible for GNU
Emacs to post a big banner saying that the ONLY repository
it recommends is its own ELPA repository, genuine GNU ELPA.
Nothing wrong with that.  Would that satisfy your
recommendation worry?

And anyway, nothing says that those repositories involve much
non-free software, or even any at all.

Without looking, I'd bet that the *overwhelming mass* of packages
in those two repositories are free software (GPL'd).  Why make
users jump through extra hoops to access all that free software,
even if there might also be a non-free package there somewhere?

Do you think that a downloading user cannot tell whether some
software is free or not?  If so, is this about trying to hide
that non-free software from their unsuspecting hands, so they
cannot make the awful mistake of not recognizing it?

If so, that kind of protection-by-ignorance is doomed to be
ineffective and even counterproductive in the long run, IMHO.

> RMS and his defense of the FSF position (and composure in
> the face of very shabby treatment) are remarkable.

Agreed 100%.  And so?  Has RMS said that listing those two
repositories would hurt free software?  Maybe a lawyer from
the FSF will chime in.  (As if we didn't get enough
software-development-by-legal-department these days..., but
I digress.)

> If Emacs (or any GNU/FSF program) actively prevented the
> installation of software, or surfing to a site of the users'
> choice, that would be censorship.

I did not suggest that.  I suggested listing those repos
by default.  That neither censors access to them nor
particularly recommends them (IMO).

How about my Samsung - Netflix analogy?  Do you think you'd
stand a chance if you sued Samsung because one of Netflix's
films offended you?  Is Samsung liable for bad Netflix films
because it makes Netflix available by default on your new TV?

Your public library (that nasty socialist institution!) no
doubt has some books that some people might find objectionable.
The library does make a selection - it decides what to make
available.  But that does not mean that the library censors
those books that are not in its catalog.  And it does not mean
that the library necessarily recommends each of its books for
each of its readers.

Some users perhaps should not read some books or install some
software packages, at least not until they feel they are ready
and want to do so.  That does not mean that books or software
that might be helpful to other users (even perhaps most users)
should not be made easily available to them.

It is my guess that the vast majority of packages in those two
repositories (a) are useful to at least _some_ Emacs users,
(b) are probably not poisonous to _any_ Emacs users, and (c)
are likely not at all problematic for _most_ Emacs users.
Do you have a different guess in this regard?  (Please note
the qualifiers, in particular "vast majority".)

If that is the case (folks here can make that judgment/guess),
then is it more helpful to users to add those two repositories
to the default list?  I think so. You are welcome to disagree.

> It is another matter entirely to _recommend_ the software
> sites, because the FSF believes that this constitutes some
> form of complicity in leading someone astray. (Whether the
> end-user believes it is immaterial.)

Sorry, I really do not see it that way.  But then, I am not
a lawyer.  I'm thinking about what could be most helpful for
most users (in my judgment).

I do not see simply listing MELPA by default as constituting
a blanket endorsement of everything on MELPA.  I cannot
imagine that any user would see it that way.  (A lawyer who
wants to make his job easier might see it that way, or at
least say that he does.)

> > Think users, not lawyers.  This is not GNanny, or at
> > least it did not used to be.
> 
> It is trivial for a user to enable these repositories.

Maybe so, but I have seen questions here and there about
doing so.  List them and it becomes even more trivial.
And no doubt it is just as trivial to remove one from the
list, or to simply ignore it, no?

And to enable them, they need to know they exist.  Listing
them by default obviates a separate discovery step: here
they are.

Just what are you trying to protect users or GNU Emacs
from?  It's a serious question.  I'd like to get a
specific answer.

So far, we've heard about the bogeyman of "(all?)" MELPA
packages destroying a user's environment or whatever
(nothing about free software in that scarefest).  That's
one extremely vague anecdote from Oscar about one user
having had one bad experience.  Sheesh.

And now we've gotten a vague catastrophe scenario from you
about free software being somehow polluted and dragged down
to depravity and degradation by inadvertent downloading of
non-free software.

But seriously, what is the *real track record* for the 1487
packages on MELPA and the *hundreds of thousands* of package
downloads from MELPA so far?  Any knowledge of mass suffering?
Any statistics about non-free software corrupting
free-software environments or users?

The experiment has been running for a while now.  Surely
we should know by now if there is a big problem here that
really needs preventing.  No?  What's the story - real
danger or not?

> What is not trivial is endeavoring to maintain a libre software
> installation, but having non-free repositories enabled.  It is truly
> shocking that proprietary "feature-enhancing" extensions can get
> installed onto a system by package managers, though the selected
> software package (e.g. Chromium) was in fact libre.

Any evidence that that has anything to do with the question
at hand?
 
> From another perspective, it makes it difficult to develop software
> systems for commercial purposes, because can't be sure that my
> company can use for any purpose or redistribute the codes.

I think you are really exaggerating there (but I am not a lawyer).

That sounds very much like the kind of thing one sometimes hears
in commercial companies about GNU (!) and why GNU software should
be avoided like the plague by companies because it supposedly
sucks all of the company's own software into a free-software
tainted purgatory.  Dueling bogeymen.

> In principle, a repo author may rise like a submarine, when he
> discovers that he could strike it rich because of (unintended)
> license violations.  IANAL, but I believe that unless otherwise
> stated, all rights are reserved.

Sounds like we need to hear from a law expert about this.
All of that sounds wildly exaggerated to me.

Just because a repository might have some packages (and is that
even sure?) that are not free software, even if it also has
hundreds of useful free-software packages (which I think is the
case), is it the end of the world for GNU Emacs to list that
repository?

In that scenario, I would say that the benefit (to users, and
to Emacs itself) would *FAR* outweigh whatever cost you imagine
to free software.

But perhaps (no doubt) I am not grasping the seriousness of the
threat to free software posed by listing these two repositories.
So far, I've seen nothing specific - only bogeymen and vague
Chicken Little alarmism.  Where's the beef?

I do appreciate the concern.  I suspect that it is misplaced.
But I, like you, am not a lawyer.  I realize that I am likely
seeing a small part of a bigger picture.  Lawyer input welcome.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Nic Ferrier]

Drew Adams <drew.adams@oracle.com> writes:

> I do appreciate the concern.  I suspect that it is misplaced.
> But I, like you, am not a lawyer.  I realize that I am likely
> seeing a small part of a bigger picture.  Lawyer input welcome.

I am not a lawyer either. I do run marmalade though.

Doing this is a terrible idea. Marmalade and MELPA don't co-operate
well.

Using an external repository, AT THIS STAGE, should still be a
deliberate choice for Emacs users IMO.


Nic Ferrier

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[David Kastrup]

Drew Adams <drew.adams@oracle.com> writes:

> Hi Eric,
>
>> >> > Why shouldn't GNU Emacs enable all three by default?
>> >> > That would help GNU Emacs users more, I think.
>> >>
>> >> One easy answer is that MELPA and Marmalade are non under the
>> >> control of the Emacs prooject.
>> >
>> > So?  GNU Emacs is not responsible for whatever it might be that
>> > those repos have or do.  And I think we (should) know by now
>> > that most, if not all, of what they do can be helpful for Emacs
>> > users.
>> 
>> I think this falls into the category of "should a GNU project
>> recommend repositories that contain non-free software?"
>
> Putting them in the available-by-default list does *not*
> recommend them, IMO.

No, it endorses them.  Much stronger.

-- 
David Kastrup

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Grim Schjetne]

Drew Adams <drew.adams@oracle.com> writes:

> Putting them in the available-by-default list does *not*
> recommend them, IMO.  And it is certainly possible for GNU
> Emacs to post a big banner saying that the ONLY repository
> it recommends is its own ELPA repository, genuine GNU ELPA.
> Nothing wrong with that.  Would that satisfy your
> recommendation worry?

A reluctant endorsement is still an endorsement.

> And anyway, nothing says that those repositories involve much
> non-free software, or even any at all.

I viewed a random package in Marmalade and it had no indication of a
license whatsoever. Perhaps the author intended to release it as free
software or could easily be convinced to do so, but as it stands now,
Marmalade is not completely free software.

> Without looking, I'd bet that the *overwhelming mass* of packages
> in those two repositories are free software (GPL'd).  Why make
> users jump through extra hoops to access all that free software,
> even if there might also be a non-free package there somewhere?
>
> Do you think that a downloading user cannot tell whether some
> software is free or not?  If so, is this about trying to hide
> that non-free software from their unsuspecting hands, so they
> cannot make the awful mistake of not recognizing it?

It seems like a reasonable assumption that the overwhelming mass is
licensed under the GPL, but I absolutely do think a user cannot tell
whether an unlabelled package is free or not, at least I can't, not
without consulting the author.

> If so, that kind of protection-by-ignorance is doomed to be
> ineffective and even counterproductive in the long run, IMHO.
>
>> RMS and his defense of the FSF position (and composure in
>> the face of very shabby treatment) are remarkable.
>
> Agreed 100%.  And so?  Has RMS said that listing those two
> repositories would hurt free software?  Maybe a lawyer from
> the FSF will chime in.  (As if we didn't get enough
> software-development-by-legal-department these days..., but
> I digress.)

You're suggesting it's a legal issue. I don't see how it is. It's not
illegal to recommend non-free software.

> How about my Samsung - Netflix analogy?  Do you think you'd
> stand a chance if you sued Samsung because one of Netflix's
> films offended you?  Is Samsung liable for bad Netflix films
> because it makes Netflix available by default on your new TV?

As far as I know it's not illegal to include Netflix in your products
either. It's a social problem, not a legal one, and yes, Samsung should
be held responsible for it. If they were distributing Busybox without
the source, that would be both a social and a legal issue.

> I think you are really exaggerating there (but I am not a lawyer).
>
> That sounds very much like the kind of thing one sometimes hears
> in commercial companies about GNU (!) and why GNU software should
> be avoided like the plague by companies because it supposedly
> sucks all of the company's own software into a free-software
> tainted purgatory.  Dueling bogeymen.

Although unrelated to the current discussion, Bradley Kuhn does a good
job explaining why some companies oppose copyleft software of which they
are not sole copyright holders:
http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

--
GS

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Stephen Berman]

On Tue, 07 Jan 2014 15:41:28 +0100 Grim Schjetne <gs@schjetne.se> wrote:

> Drew Adams <drew.adams@oracle.com> writes:
>
>> And anyway, nothing says that those repositories involve much
>> non-free software, or even any at all.
>
> I viewed a random package in Marmalade and it had no indication of a
> license whatsoever. Perhaps the author intended to release it as free
> software or could easily be convinced to do so, but as it stands now,
> Marmalade is not completely free software.
>
>> Without looking, I'd bet that the *overwhelming mass* of packages
>> in those two repositories are free software (GPL'd).  Why make
>> users jump through extra hoops to access all that free software,
>> even if there might also be a non-free package there somewhere?
>>
>> Do you think that a downloading user cannot tell whether some
>> software is free or not?  If so, is this about trying to hide
>> that non-free software from their unsuspecting hands, so they
>> cannot make the awful mistake of not recognizing it?
>
> It seems like a reasonable assumption that the overwhelming mass is
> licensed under the GPL, but I absolutely do think a user cannot tell
> whether an unlabelled package is free or not, at least I can't, not
> without consulting the author.

Is it even "legal" to distribute any elisp code that is not at least
compatible with the GPL?  After all, any elisp code will have to link
with Emacs to be usable.

Steve Berman

RE: enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams]

> Is it even "legal" to distribute any elisp code that is not at least
> compatible with the GPL?  After all, any elisp code will have to
> link with Emacs to be usable.

Not sure why you put "legal" in quotes.  And it's not clear what you
have in mind by "compatible with", here.

But of course it is legal to distribute Emacs Lisp code that is not
under GPL.  GNU/FSF does not want to distribute such code itself,
naturally.  And it does not like anyone else to do so.  But it is
not illegal for someone to do that.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Stephen Berman]

On Tue, 7 Jan 2014 09:44:32 -0800 (PST) Drew Adams <drew.adams@oracle.com> wrote:

>> Is it even "legal" to distribute any elisp code that is not at least
>> compatible with the GPL?  After all, any elisp code will have to
>> link with Emacs to be usable.
>
> Not sure why you put "legal" in quotes.

Just a hedge, since I'm not sure of the legal status of the GPL, whether
in the US or any other jurisdiction.

>                                          And it's not clear what you
> have in mind by "compatible with", here.

I meant code with a license whose terms contradict (in whole or part)
the GPL.  Since you cannot (IIUC) distribute Emacs (or a fork of it)
under a license that contradicts the GPL, it seems to follow that any
elisp code, which must link with Emacs to be executed, also cannot be
distributed under a license that contradicts the GPL.  Or maybe it just
follows that any such code could not be part of Emacs.  Anyway, I'm not
interested in such code and was more or less just idly speculating.

Steve Berman

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Tassilo Horn]

Stephen Berman <stephen.berman@gmx.net> writes:

>>> Is it even "legal" to distribute any elisp code that is not at least
>>> compatible with the GPL?  After all, any elisp code will have to
>>> link with Emacs to be usable.
>>
>> Not sure why you put "legal" in quotes.
>
> Just a hedge, since I'm not sure of the legal status of the GPL,
> whether in the US or any other jurisdiction.

At least here in Germany, the GPL has been confirmed several times by
German courts.

Bye,
Tassilo

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[David Kastrup]

Tassilo Horn <tsdh@gnu.org> writes:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>>>> Is it even "legal" to distribute any elisp code that is not at least
>>>> compatible with the GPL?  After all, any elisp code will have to
>>>> link with Emacs to be usable.
>>>
>>> Not sure why you put "legal" in quotes.
>>
>> Just a hedge, since I'm not sure of the legal status of the GPL,
>> whether in the US or any other jurisdiction.
>
> At least here in Germany, the GPL has been confirmed several times by
> German courts.

Whatever you may consider "confirmed".  The point is just that the
defense against GPL violations is rather weak.  "Your honor, we consider
the GPL to be invalid and ourselves not bound by it."  Which is
perfectly fine, and the GPL explicitly allows for it.  The problem is
that the followup question then is "Ok, let's put aside the GPL.  What
_other_ permission did you have for using this software?"  And things go
downhill from there.  The ultimate position tends to be something along
the line of "no reasonable person could have expected the license to
mean what it says".

And getting a judge to swallow that is a challenge.

It's not as much the GPL that is confirmed in such cases, but rather
copyright as such.  One reason there is more confirmation in Germany
might be that in Germany, "loser pays all".  In the U.S., it is much
more expensive to defend what is obviously yours.

-- 
David Kastrup

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Stefan Monnier]

> Is it even "legal" to distribute any elisp code that is not at least
> compatible with the GPL?

I think it is indeed "not legal", but I don't think this has been tested
in court, nor have I even heard any rumor of a lawyer expressing an
opinion on the issue.


        Stefan

Re: enable MELPA & Marmalade by defaul

[Glenn Morris]

Stefan Monnier wrote:

>> Is it even "legal" to distribute any elisp code that is not at least
>> compatible with the GPL?
>
> I think it is indeed "not legal", but I don't think this has been tested
> in court, nor have I even heard any rumor of a lawyer expressing an
> opinion on the issue.

rms has said at least twice (IIRC) that he was asking a lawyer this
question, but I never seen an answer. Eg:

http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01368.html

(I think there was a more recent repeat than that, but I can't find it
now.)

RE: enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams]

Hi Grim,

> > Putting them in the available-by-default list does *not*
> > recommend them, IMO.  And it is certainly possible for GNU
> > Emacs to post a big banner saying that the ONLY repository
> > it recommends is its own ELPA repository, genuine GNU ELPA.
> > Nothing wrong with that.  Would that satisfy your
> > recommendation worry?
> 
> A reluctant endorsement is still an endorsement.

Where do you see an endorsement in that - reluctant or enthusiastic?

> > And anyway, nothing says that those repositories involve much
> > non-free software, or even any at all.
> 
> I viewed a random package in Marmalade and it had no indication
> of a license whatsoever.

How many times did you pick a "random" package?  Once?
What proportion of Marmalade packages have no license?

> Perhaps the author intended to release it as free software or
> could easily be convinced to do so, but as it stands now,
> Marmalade is not completely free software.

I never claimed that either MELPA or Marmalade is completely
free software.  Is there some free software there?  Is it useful?

> > Without looking, I'd bet that the *overwhelming mass* of packages
> > in those two repositories are free software (GPL'd).  Why make
> > users jump through extra hoops to access all that free software,
> > even if there might also be a non-free package there somewhere?
> >
> > Do you think that a downloading user cannot tell whether some
> > software is free or not?  If so, is this about trying to hide
> > that non-free software from their unsuspecting hands, so they
> > cannot make the awful mistake of not recognizing it?
> 
> It seems like a reasonable assumption that the overwhelming mass is
> licensed under the GPL, but I absolutely do think a user cannot tell
> whether an unlabelled package is free or not, at least I can't, not
> without consulting the author.

I'm no expert on package.el.  But perhaps it is a current limitation
if it does not either (a) provide a command that shows the license
(e.g., by searching the file header) or (b) let you easily browse
(at least) the main file of the package (which presumably has a
license) before downloading (or perhaps before installing).

IOW, I agree that it would be good for a user to be able to see
such info before hand, while browsing the repository.  Likewise,
to see the name of the author/maintainer.  Whether that is a
(missing) package.el feature or a (missing) repository feature,
I don't know.

> > If so, that kind of protection-by-ignorance is doomed to be
> > ineffective and even counterproductive in the long run, IMHO.
> >
> >> RMS and his defense of the FSF position (and composure in
> >> the face of very shabby treatment) are remarkable.
> >
> > Agreed 100%.  And so?  Has RMS said that listing those two
> > repositories would hurt free software?  Maybe a lawyer from
> > the FSF will chime in.  (As if we didn't get enough
> > software-development-by-legal-department these days..., but
> > I digress.)
> 
> You're suggesting it's a legal issue. I don't see how it is. It's
> not illegal to recommend non-free software.

Please read what I wrote.  Did I say anything about illegality?

I'm not suggesting that.  I'm suggesting that perhaps RMS or FSF
would not want to list those repos by default because of legal
considerations.  And "legal considerations" does not mean that
something is illegal.  Most commonly these days, it means "for
fear of a lawsuit", but it can also mean, "just to avoid any
possible legal problems."

But mainly I was saying that, so far, RMS and FSF have not
said anything about this.  They have not chimed in with any
objection.  This was in response to statements that presumably
this would go against software freedom.  If it does, then I
am sure we should hear from RMS/FSF soon enough about that.

> > How about my Samsung - Netflix analogy?  Do you think you'd
> > stand a chance if you sued Samsung because one of Netflix's
> > films offended you?  Is Samsung liable for bad Netflix films
> > because it makes Netflix available by default on your new TV?
> 
> As far as I know it's not illegal to include Netflix in your
> products either.

It really sounds like you are confusing law, which includes
civil and criminal law, with criminal law.  I spoke about law
suits, not illegality.

> It's a social problem, not a legal one, and yes, Samsung
> should be held responsible for it. 

Good luck with a law suit on that basis.

> If they were distributing Busybox without the source, that
> would be both a social and a legal issue.

Irrelevant.  No one is saying anything about distributing
GPL software (or any software) without the source code.  You
are off the mark here.

> > I think you are really exaggerating there (but I am not a lawyer).
> >
> > That sounds very much like the kind of thing one sometimes hears
> > in commercial companies about GNU (!) and why GNU software should
> > be avoided like the plague by companies because it supposedly
> > sucks all of the company's own software into a free-software
> > tainted purgatory.  Dueling bogeymen.
> 
> Although unrelated to the current discussion, Bradley Kuhn does a
> good job explaining why some companies oppose copyleft software
> of which they are not sole copyright holders:
> http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

Thanks for the info; interesting.

Regards,

  Drew

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    How many times did you pick a "random" package?  Once?
    What proportion of Marmalade packages have no license?

A program with no license notice is not free software.
(See http://gnu.org/licenses/license-list.html#NoLicense.)
It is very bad practice for a repository to permits nonfree programs.
Every repository should have a policy not to do that.

    > It seems like a reasonable assumption that the overwhelming mass is
    > licensed under the GPL, but I absolutely do think a user cannot tell
    > whether an unlabelled package is free or not, at least I can't, not
    > without consulting the author.

If a source file doesn't have a license notice then it is nonfree.

Maybe this policy results from a misunderstanding on the part
of whoever runs Marmalade.  We should try explaining the facts
about missing licenses and see if the maintainer of Marmalade
will change the policy to stop allowing them.  Can someone put me
in touch with the right people?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Bob Bobeck]

When you talk to them, don't forget to mention the BSD 2-Clause
License as an option: http://opensource.org/licenses/BSD-2-Clause

On 1/7/14, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     How many times did you pick a "random" package?  Once?
>     What proportion of Marmalade packages have no license?
>
> A program with no license notice is not free software.
> (See http://gnu.org/licenses/license-list.html#NoLicense.)
> It is very bad practice for a repository to permits nonfree programs.
> Every repository should have a policy not to do that.
>
>     > It seems like a reasonable assumption that the overwhelming mass is
>     > licensed under the GPL, but I absolutely do think a user cannot tell
>     > whether an unlabelled package is free or not, at least I can't, not
>     > without consulting the author.
>
> If a source file doesn't have a license notice then it is nonfree.
>
> Maybe this policy results from a misunderstanding on the part
> of whoever runs Marmalade.  We should try explaining the facts
> about missing licenses and see if the maintainer of Marmalade
> will change the policy to stop allowing them.  Can someone put me
> in touch with the right people?
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
>
>
>

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> A program with no license notice is not free software.
> (See http://gnu.org/licenses/license-list.html#NoLicense.)
> It is very bad practice for a repository to permits nonfree programs.
> Every repository should have a policy not to do that.
>
>     > It seems like a reasonable assumption that the overwhelming mass is
>     > licensed under the GPL, but I absolutely do think a user cannot tell
>     > whether an unlabelled package is free or not, at least I can't, not
>     > without consulting the author.
>
> If a source file doesn't have a license notice then it is nonfree.
>
> Maybe this policy results from a misunderstanding on the part
> of whoever runs Marmalade.  We should try explaining the facts
> about missing licenses and see if the maintainer of Marmalade
> will change the policy to stop allowing them.  Can someone put me
> in touch with the right people?

I run marmalade.

It is not a misunderstanding on my part.

You and I have spoken about it already on email.

My position is that I *do* want to add licence functionality to
marmalade.


The functionality will:

* allow package authors to choose what licence they distribute their
  code under (hopefully without any extra effort if the licence is
  stated in the code in the usual Emacs way) 

* allow users of marmalade to choose to use a repository which is
  exclusively:

** Free software only
** or GPL only
** or GPL + LGPL


But I am not ready to introduce those features yet. I am still
struggling with getting marmalade even functional (it is very bad code
that I inherited).


I am (slowly) getting there.

I said earlier in this thread that I thought recommending a package
archive other than ELPA was a very bad idea. The licence issue is just
one reason.

Another is control and understanding of who wrote what package. MELPA is
anarchy in this regard (which some think is a good thing). Marmalade is
not much better.

Signed packages are being worked on. When I have introduced signed
package functionality to marmalade and when I have introduced the
licence features then I would be happy for marmalade to be included as a
recommendation in an Emacs distribution.

Till then, as the maintainer of Marmalade I would ask you not to do
that.


Nic Ferrier

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Achim Gratz]

Nic Ferrier writes:
> I said earlier in this thread that I thought recommending a package
> archive other than ELPA was a very bad idea. The licence issue is just
> one reason.

Currently, if multiple package archives offer the same packages, then
the archive offering the highest version number wins (which is always
MELPA, based on how they construct their version numbers).  All other
issues aside, a user would reasonably expect that an installed package
should not switch archives on updates automatically and that it is
possible to specify which archive is considered a valid source (in
general and for specific packages).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Andy Moreton]

On Wed 08 Jan 2014, Achim Gratz wrote:

> Nic Ferrier writes:
>> I said earlier in this thread that I thought recommending a package
>> archive other than ELPA was a very bad idea. The licence issue is just
>> one reason.
>
> Currently, if multiple package archives offer the same packages, then
> the archive offering the highest version number wins (which is always
> MELPA, based on how they construct their version numbers).  All other
> issues aside, a user would reasonably expect that an installed package
> should not switch archives on updates automatically and that it is
> possible to specify which archive is considered a valid source (in
> general and for specific packages).

With multiple independent package archives, packages with the same name
are not necessarily related in any way at all. This means that packages
names should be qualified by the archive they were installed from.

    AndyM

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Nic Ferrier]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Wed 08 Jan 2014, Achim Gratz wrote:
>
>> Nic Ferrier writes:
>>> I said earlier in this thread that I thought recommending a package
>>> archive other than ELPA was a very bad idea. The licence issue is just
>>> one reason.
>>
>> Currently, if multiple package archives offer the same packages, then
>> the archive offering the highest version number wins (which is always
>> MELPA, based on how they construct their version numbers).  All other
>> issues aside, a user would reasonably expect that an installed package
>> should not switch archives on updates automatically and that it is
>> possible to specify which archive is considered a valid source (in
>> general and for specific packages).
>
> With multiple independent package archives, packages with the same name
> are not necessarily related in any way at all. This means that packages
> names should be qualified by the archive they were installed from.

I don't agree with that. 

With your proposal we would be moving away from the very simple
but effective system we have now into much more complex territory.

As can be seen from package stores like Debian, some people want to
upgrade a package from different stores and some people want to pin.

It's not as easy as just being able to say "let's do it only one way".


But again, we're getting away from the point. The point was should Emacs
distribute a pointer to Marmalade or MELPA.

I reiterate that as the maintainer of Marmalade, I don't think it is.


Nic Ferrier

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Tassilo Horn]

Achim Gratz <Stromeko@nexgo.de> writes:

>> I said earlier in this thread that I thought recommending a package
>> archive other than ELPA was a very bad idea. The licence issue is
>> just one reason.
>
> Currently, if multiple package archives offer the same packages, then
> the archive offering the highest version number wins (which is always
> MELPA, based on how they construct their version numbers).

Is that true?  I have MELPA enabled, and for packages that appear both
in GNU ELPA and MELPA, I get for example

  diff-hl            1.5.1        available  gnu        Highlight uncommitted changes
  diff-hl            20131114.53  available  melpa      Highlight uncommitted changes

so that I can decide to either use the stable release or the bleeding
edge version.

Bye,
Tassilo

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[chad]

On 08 Jan 2014, at 23:55, Tassilo Horn <tsdh@gnu.org> wrote:

> Achim Gratz <Stromeko@nexgo.de> writes:
> 
>> Currently, if multiple package archives offer the same packages, then
>> the archive offering the highest version number wins (which is always
>> MELPA, based on how they construct their version numbers).
> 
> Is that true?  I have MELPA enabled, and for packages that appear both
> in GNU ELPA and MELPA, I get for example
> 
>  diff-hl            1.5.1        available  gnu        Highlight uncommitted changes
>  diff-hl            20131114.53  available  melpa      Highlight uncommitted changes
> 
> so that I can decide to either use the stable release or the bleeding
> edge version.

I believe that this feature is in HEAD but not yet any release.

Hope that helps,
~Chad

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Achim Gratz]

Tassilo Horn writes:
> Is that true?  I have MELPA enabled, and for packages that appear both
> in GNU ELPA and MELPA, I get for example
>
>   diff-hl            1.5.1        available  gnu        Highlight uncommitted changes
>   diff-hl            20131114.53  available  melpa      Highlight uncommitted changes
>
> so that I can decide to either use the stable release or the bleeding
> edge version.

Yes, but once you have installed the 1.5.1 version, the information
which package archive you installed it from is gone and the next update
from package manager will switch you to melpa because it has a higher
version.  I've just tested it again with an Emacs from trunk a few days
old.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Stephen J. Turnbull]

Grim Schjetne writes:

 > I viewed a random package in Marmalade and it had no indication of a
 > license whatsoever. Perhaps the author intended to release it as free
 > software

If so, it *is* free software.  It's just very risky for users, because
without a verifiable statement of license, the author could change his
mind and the users would have no recourse.

True, failing to post a license violates best practices, but it's
unlikely that even a patent shark would upload a file to Marmalade in
the hopes that they could sue users for enough money to pay court
costs.  It would be nice if the repos would enforce a policy of
removing packages that do not contain an explicit statement of
license.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Grim Schjetne writes:
>
>  > I viewed a random package in Marmalade and it had no indication of a
>  > license whatsoever. Perhaps the author intended to release it as free
>  > software
>
> If so, it *is* free software.  It's just very risky for users, because
> without a verifiable statement of license, the author could change his
> mind and the users would have no recourse.

A user does not have a "recourse" anyway.  The author can always change
his mind even with a verifiable statement of license and sue.  A
verifiable statement of license is no help against that, but it is a
good defense.  Note that in the U.S.A., the financial risk of even a
meritless lawsuit is enough of a detraction for anybody: only in the
case of _frivolous_ lawsuits (and the barrier for that is rather high)
does the defendant get to reclaim his court fees and attorney costs.

> True, failing to post a license violates best practices, but it's
> unlikely that even a patent shark would upload a file to Marmalade in
> the hopes that they could sue users for enough money to pay court
> costs.

That's not the shark model for small fry.  The shark model is to sue
and/or send a cease and desist letter, then settle out of court for less
than the cost of a successful defense.

> It would be nice if the repos would enforce a policy of removing
> packages that do not contain an explicit statement of license.

Yes, definitely.

-- 
David Kastrup

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    So?  GNU Emacs is not responsible for whatever it might be that
    those repos have or do.

We are not looking for excuses to be irresponsible, so we will
maintain control over what code GNU Emacs recommends to users.  We
will therefore not recommend repositories that are maintained outside
of the GNU Project.

Mentioning a repository constitutes recommending it.

    When you buy a Samsung TV and it comes enabled for use by Netflix
    (provided you subscribe), does that make Samsung responsible for
    something that Netflix might offer?

This example is cogent, because the Netflix app is nonfree software:
immoral and unjust.  Even nastier, it implements DRM.  To distribute
that is wrong, and even recommending it is wrong.

How can we make sure we don't recommend an Emacs library to run
Netflix (perhaps by fork and exec)?  By maintaining control over
what we recommend.

There are various reasons we might not want to recommend something,
so we will make we sure remain in a position to decide.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Stephen J. Turnbull]

Richard Stallman writes:

 > Mentioning a repository constitutes recommending it.

[...]

 > This example is cogent, because the Netflix app

Newsflash!  RMS recommends Netflix![1]  ;-)

Please say "enabling access constitutes recommendation."

Allowing the user to specify a generic base URL in the package access
software is a very weak recommendation, since it "recommends" everything
on the web.  Adding a specific :choice element to the defcustom is a
clear recommendation IMO.  Enabling by default is a strong
recommendation.

Anyone who feels that strongly about the issue can create a file
"repo-registry" which adds the other repos to the defcustom and even
enables them by default, and interested users can download and use
that file.  Possibly even from MELPA or Marmalade.


Footnotes: 
[1]  N.B. The deliberate taking from context is to make the point
about the word "mention", but remember the politician's proverb, "Call
me anything you like, but spell my name correctly."  The context
doesn't really help to weaken any implicit recommendation, as when it
comes to decrying non-free software, RMS is likely to choose the
best-of-breed as the example.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

     > Mentioning a repository constitutes recommending it.

    [...]

     > This example is cogent, because the Netflix app

    Newsflash!  RMS recommends Netflix![1]  ;-)

We were talking about mentioning a repository as an option for people
to use.  I didn't make sure to repeat that in full, I said just
"mentioning", but I think you could have understood the intended
meaning from the context.

    Allowing the user to specify a generic base URL in the package access
    software is a very weak recommendation, since it "recommends" everything
    on the web.

A general facility like that doesn't recommend anything in particular.
Listing particular programs or collections leads people towards them;
that's what we need to be selective about.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

RE: enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams]

>     So?  GNU Emacs is not responsible for whatever it might be that
>     those repos have or do.
> 
> We are not looking for excuses to be irresponsible, so we will
> maintain control over what code GNU Emacs recommends to users.  We
> will therefore not recommend repositories that are maintained
> outside of the GNU Project.
> 
> Mentioning a repository constitutes recommending it.

OK, so there we have it: a clear statement.  End of story.  Thx.

I can certainly live with that decision (though I do not agree
at all that mentioning something constitutes recommending it).

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Ted Zlatanov]

On Mon, 6 Jan 2014 15:00:37 -0800 (PST) Drew Adams <drew.adams@oracle.com> wrote: 

>> GNU ELPA (enabled by default with Emacs, unlike MELPA or Marmalade).
DA> Apropos: Why shouldn't GNU Emacs enable all three by default?

I would be against that by default.

But they could be made easier to enable, maybe as pre-canned options you
can check to enable in the Customize view of `package-archives'.  I'd be
in favor of that.

Ted

RE: enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams]

> > Why shouldn't GNU Emacs enable all three by default?
> 
> I would be against that by default.
> 
> But they could be made easier to enable, maybe as pre-canned options
> you can check to enable in the Customize view of `package-archives'.
> I'd be in favor of that.

Yes.  But it is less about the difficulty of enabling that it is
about lack of any indication that they even exist as possibilities.

Even just mentioning them in the interface would help users.
Yes, it would help them find (lots!) more *free software* that is
useful.

Re: enable MELPA & Marmalade by defaul [was: mykie.el]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Yes.  But it is less about the difficulty of enabling that it is
    about lack of any indication that they even exist as possibilities.

Yes, exactly.  We are selective about which packages we mention
as possibilities, so we decline to indirect that to a list maintained
by someone else.

If you'd like your package to be mentioned as a possibility,
you should make arrangements to get it into the GNU ELPA.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: mykie.el

[Yuta Yamada]

I sent same message from my mailer on Emacs, but it seems not reached
to this place. so I re-sent same message from web.
Sorry if you see same message again.

Hello emacssen, I'm author of the mykie.el.
I'm not sure this is correct way to reply this article.
Let's me know if this way is any problem by yours.

I'm glad someone interested about this package.
But about assigning copyright and signing the Emacs contributor papers is
I'm just worried whether I can keep developing at GitHub.
Is that ok? Or do I need something if I change this package's code?

Even if it's no, I don't care to assign copyright and sign the Emacs
contributor papers. But I'm just wondered.

BTW my name is Yuta Yamada. Not Yato.
(I'm not angry. don't worry Mr.Ted)

Yuta

Re: mykie.el

[Stefan Monnier]

> Here's an example of context-dependent usage:

> (mykie:global-set-key "C-j"
>    :default  '(progn
>                 (delete-trailing-whitespace)
>                 (case major-mode
>                   (org-mode (org-return-indent))
>                   (t        (newline-and-indent))))
>    :C-u&eolp '(fill-region (point-at-bol) (point-at-eol))
>    :region   'query-replace-regexp)

> (many other keywords are available, e.g. :prog for activating only in
> programming modes)

Is that really much better than:

  (global-set-key "\C-j"
     (lambda ()
       (interactive)
       (cond
        (current-prefix-arg (fill-region (point-at-bol) (point-at-eol)))
        ((and (use-region-p) (eolp))
         (call-interactively 'query-replace-regexp))
        (t
         (delete-trailing-whitespace)
         (case major-mode
           (org-mode (org-return-indent))
           (t        (newline-and-indent)))))))

IIUC the need for "context dependent bindings" becomes more interesting
when you want the different cases to be specified independently.
As in

  (my-global-set-key "\C-j"
                     :predicate current-prefix-arg
                     :action (fill-region (point-at-bol) (point-at-eol)))

  (my-global-set-key "\C-j"
                     :predicate (and (use-region-p) (eolp))
                     :action 'query-replace-regexp)

I'm not sure exactly how best to do that, tho.


        Stefan

Re: mykie.el

[Leo Liu]

On 2014-01-04 12:34 +0800, Stefan Monnier wrote:
> Is that really much better than:
>
>   (global-set-key "\C-j"
>      (lambda ()
>        (interactive)
>        (cond
>         (current-prefix-arg (fill-region (point-at-bol) (point-at-eol)))
>         ((and (use-region-p) (eolp))
>          (call-interactively 'query-replace-regexp))
>         (t
>          (delete-trailing-whitespace)
>          (case major-mode
>            (org-mode (org-return-indent))
>            (t        (newline-and-indent)))))))

My thought exactly. Elisp is the best DSL for emacs.

Leo

Re: mykie.el

[Mitchel Humpherys]

On Fri, Jan 03 2014 at 08:34:01 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Here's an example of context-dependent usage:
>
>> (mykie:global-set-key "C-j"
>>    :default  '(progn
>>                 (delete-trailing-whitespace)
>>                 (case major-mode
>>                   (org-mode (org-return-indent))
>>                   (t        (newline-and-indent))))
>>    :C-u&eolp '(fill-region (point-at-bol) (point-at-eol))
>>    :region   'query-replace-regexp)
>
>> (many other keywords are available, e.g. :prog for activating only in
>> programming modes)
>
> Is that really much better than:
>
>   (global-set-key "\C-j"
>      (lambda ()
>        (interactive)
>        (cond
>         (current-prefix-arg (fill-region (point-at-bol) (point-at-eol)))
>         ((and (use-region-p) (eolp))
>          (call-interactively 'query-replace-regexp))
>         (t
>          (delete-trailing-whitespace)
>          (case major-mode
>            (org-mode (org-return-indent))
>            (t        (newline-and-indent)))))))

Define "better". It's cool that yours is just vanilla Elisp but it took
me about 5 seconds to fully parse the mykie version and about 20 seconds
to fully parse your version.


-- 
Mitch

Re: mykie.el

[Leo Liu]

On 2014-01-05 16:10 +0800, Mitchel Humpherys wrote:
> Define "better". It's cool that yours is just vanilla Elisp but it took
> me about 5 seconds to fully parse the mykie version and about 20 seconds
> to fully parse your version.

For me it is the other way around. The elisp syntax flows so smoothly
and gives me a sense of beauty and reassurance...

Don't get me wrong. I have nothing against mykie. It is perfectly fine
to introduce some syntax helper for writing the staff you want to write.
But this doesn't need to be in emacs core.

Leo

Re: mykie.el

[Nicolas Richard]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> IIUC the need for "context dependent bindings" becomes more interesting
> when you want the different cases to be specified independently.

One could check the predicate while looking up the key sequence in
active keymaps. AIUI, currently, keymaps are checked and if the sequence
is bound to a command it is used, otherwise lookup continues. My
suggestion is to change the condition "is bound" to "is bound *and* some
predicate is non nil". [I must say that since this likely requires
changes to C code, I don't have even the beginning of a patch.]

-- 
Nico.

Re: mykie.el

[Ted Zlatanov]

On Fri, 03 Jan 2014 23:34:01 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Is that really much better than [vanilla Emacs lisp]?

Yes.  The difference is huge for a beginner.

SM> IIUC the need for "context dependent bindings" becomes more interesting
SM> when you want the different cases to be specified independently.
...
SM> I'm not sure exactly how best to do that, tho.

Me neither.  Maybe Yuta Yamada can suggest, or mykie.el does it already.

Ted

Re: mykie.el

[Stefan Monnier]

SM> Is that really much better than [vanilla Emacs lisp]?
> Yes.  The difference is huge for a beginner.

I'm far from convinced.  The beginner will have to learn the
mykie-specific sublanguage.  Maybe it's slightly simpler, but then this
effort won't help him understand other code.

Making it easier to customize Emacs is great, but it's better if it also
gets you some way towards hacking on Emacs so as to become a contributor.

Of course, there are cosmetic issues in the mykie.el syntax that rub me
the wrong way.  Most obvious is the need to quote code.  I already spend
enough time telling people not to quote their lambdas and trying to fix
code that abuses `eval' in all kinds of useless ways.

Starting from

(mykie:global-set-key "C-j"
   :default  '(progn
                (delete-trailing-whitespace)
                (case major-mode
                  (org-mode (org-return-indent))
                  (t        (newline-and-indent))))
   :C-u&eolp '(fill-region (point-at-bol) (point-at-eol))
   :region   'query-replace-regexp)

I'd suggest to first get rid of the quotes and the
`mykie:global-set-key' (so that it can be used with
local-set-key, define-key, you name it):

   (global-set-key "C-j"
      (smkie
       :default  (progn
                  (delete-trailing-whitespace)
                  (case major-mode
                    (org-mode (org-return-indent))
                    (t        (newline-and-indent))))
       :C-u&eolp (fill-region (point-at-bol) (point-at-eol))
       :region   'query-replace-regexp))

Then I suggest we use a parenthesized syntax, and descriptive name, to
be more Lispish:

   (global-set-key "C-j"
      (sm-combined-command
       (:default
        (delete-trailing-whitespace)
        (case major-mode
          (org-mode (org-return-indent))
          (t        (newline-and-indent))))
       (:C-u&eolp (fill-region (point-at-bol) (point-at-eol)))
       (:region   'query-replace-regexp)))

Also, since the user knows about "t is default" from "case", we might as
well get rid of ":default":

   (global-set-key "C-j"
      (sm-combined-command
       (:C-u&eolp (fill-region (point-at-bol) (point-at-eol)))
       (:region   'query-replace-regexp)
       (t
        (delete-trailing-whitespace)
        (case major-mode
          (org-mode (org-return-indent))
          (t        (newline-and-indent))))))

And sm-combined-command is a very simple macro:

  (defconst sm-combined-command-predicates
    '((:region . (use-region-p))
      (:C-u . current-prefix-arg)
      (:C-u&eolp . (and current-prefix-arg (eolp)))
      ...))

  (defmacro sm-combined-command (branches)
    `(lambda ()
       (interactive)
       (cond
        ,@(mapcar (lambda (branch)
                    `(,(or (cdr (assq (car branch)
                                      sm-combined-command-predicates))
                           (car branch))
                      ,@(pcase (cdr branch)
                          (`(',cmd) `((call-interactively ',cmd)))
                          (,cmds cmds))))
                  branches))))
          
-- Stefan

Re: mykie.el

[Ted Zlatanov]

On Mon, 06 Jan 2014 19:37:01 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Is that really much better than [vanilla Emacs lisp]?
>> Yes.  The difference is huge for a beginner.

SM> I'm far from convinced.  The beginner will have to learn the
SM> mykie-specific sublanguage.  Maybe it's slightly simpler, but then this
SM> effort won't help him understand other code.

That's a problem with anything that hides code complexity, and yet we do
it all the time.  I doubt beginners can handle `pcase' and the
subtleties of context-sensitive key definitions, so I think for this
specific case the simplification is necessary.

SM> Making it easier to customize Emacs is great, but it's better if it also
SM> gets you some way towards hacking on Emacs so as to become a contributor.

I completely disagree with that line of thinking.

SM> Of course, there are cosmetic issues in the mykie.el syntax that rub me
SM> the wrong way.  Most obvious is the need to quote code.  I already spend
SM> enough time telling people not to quote their lambdas and trying to fix
SM> code that abuses `eval' in all kinds of useless ways.

That's a good point.

...
SM>    (global-set-key "C-j"
SM>       (sm-combined-command
SM>        (:C-u&eolp (fill-region (point-at-bol) (point-at-eol)))
SM>        (:region   'query-replace-regexp)
SM>        (t
SM>         (delete-trailing-whitespace)
SM>         (case major-mode
SM>           (org-mode (org-return-indent))
SM>           (t        (newline-and-indent))))))

SM> And sm-combined-command is a very simple macro:

SM>   (defconst sm-combined-command-predicates
SM>     '((:region . (use-region-p))
SM>       (:C-u . current-prefix-arg)
SM>       (:C-u&eolp . (and current-prefix-arg (eolp)))
SM>       ...))

SM>   (defmacro sm-combined-command (branches)
SM>     `(lambda ()
SM>        (interactive)
SM>        (cond
SM>         ,@(mapcar (lambda (branch)
SM>                     `(,(or (cdr (assq (car branch)
SM>                                       sm-combined-command-predicates))
SM>                            (car branch))
SM>                       ,@(pcase (cdr branch)
SM>                           (`(',cmd) `((call-interactively ',cmd)))
SM>                           (,cmds cmds))))
SM>                   branches))))

That's very nice (you and your pcase :).  I think it's fairly difficult
to explain *how* it works to a beginner and would need lots of
documentation, but from the user's standpoint it's exactly what I was
hoping to bring out of mykie.el.  The developers can then contribute
more predicates and the users can happily use them.

The important question for you and Yamada-san is, would you be
interested in something like `sm-combined-command' in the Emacs core,
regardless of how mykie.el evolves?  Then mykie.el can remain a place
for experimentation and perhaps it can use `sm-combined-command'
internally, enriching it with special extensions that maybe don't make
sense in the core.

The other way I imagine is to put mykie.el in the GNU ELPA, but I would
rather enable this facility by default if there are no objections.

Ted

Re: mykie.el

[Stefan Monnier]

SM> Making it easier to customize Emacs is great, but it's better if it also
SM> gets you some way towards hacking on Emacs so as to become a contributor.
> I completely disagree with that line of thinking.

I can't begin to imagine why you'd disagree with it.

> The important question for you and Yamada-san is, would you be
> interested in something like `sm-combined-command' in the Emacs core,

You could add it to subr-x.el (after 24.4),


        Stefan

Re: mykie.el

[Ted Zlatanov]

On Tue, 07 Jan 2014 22:24:16 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Making it easier to customize Emacs is great, but it's better if it also
SM> gets you some way towards hacking on Emacs so as to become a contributor.
>> I completely disagree with that line of thinking.

SM> I can't begin to imagine why you'd disagree with it.

Because hacking should be an exploration, not a guided expedition.
Anyhow, I didn't mean to sidetrack things, I think we agree on this.

>> The important question for you and Yamada-san is, would you be
>> interested in something like `sm-combined-command' in the Emacs core,

SM> You could add it to subr-x.el (after 24.4),

Wonderful, thanks.  Yamada-san, WDYT?  Do you want to work on the
approach Stefan suggested in the Emacs core and integrate mykie.el with
it, or would you rather keep mykie.el separate from this work?

Shall I name this `define-key-contextual' or something else?

Ted

Re: mykie.el

[Stefan Monnier]

> Shall I name this `define-key-contextual' or something else?

I don't see anything "define-key ish" in there.  It's a macro that lets
you define a *command*.


        Stefan

Re: mykie.el

[Ted Zlatanov]

On Wed, 08 Jan 2014 11:11:04 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Shall I name this `define-key-contextual' or something else?
SM> I don't see anything "define-key ish" in there.  It's a macro that lets
SM> you define a *command*.

Assuming we're not moving to a megalomaniacal[1] `sm-*' prefix for new
additions, what name you you like me to use for this macro?

Ted

[1] not that there's anything wrong with that

Re: mykie.el

[Stefan Monnier]

> Assuming we're not moving to a megalomaniacal[1] `sm-*' prefix for new
> additions, what name you you like me to use for this macro?

No idea.  "make-combo-command"?
Sounds pretty poor, but at least it describes somewhat what it does.


        Stefan

Re: mykie.el

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Shall I name this `define-key-contextual' or something else?
>
> I don't see anything "define-key ish" in there.  It's a macro that
> lets you define a *command*.

FWIW, I'd much prefer the define-key-like approach you've suggested
earlier this thread (sorry, can't look it up right now), i.e., where you
can add different clauses separately.  Ideally, it would be cool if it
allowed to define the same key in different keymaps and still be working
as expected.  E.g.:

  (define-context-key outline-minor-mode-map (kbd "TAB")
    :predicate outline-heading-p
    :action org-cycle)

  (define-context-key emacs-lisp-mode-map (kbd "TAB")
    :predicate beginning-of-defun-p
    :action eval-defun)

And then in a elisp buffer with outline-minor-mode enabled, if I'm on a
outline heading, it would cycle through the outline states, if I'm at
the beginning of a defun, if would eval it, and if I'm on neither of
those, then it does what TAB would do usually.

I already do have such a macro, but it doesn't allow defining multiple
separate predicate-action combos for the same key.  Falling back to the
"do what TAB would do by default" does work, however.  (Actually, you
helped me implementing it.)

--8<---------------cut here---------------start------------->8---
(defmacro th/define-context-key (keymap key dispatch)
  "Define KEY in KEYMAP to execute according to DISPATCH.

DISPATCH is a form that is evaluated and should return the
command to be executed.

If DISPATCH returns nil, then the command normally bound to KEY
will be executed.

Example:

  (th/define-context-key hs-minor-mode-map
     (kbd \"<C-tab>\")
     (cond
      ((not (hs-already-hidden-p))
       'hs-hide-block)
      ((hs-already-hidden-p)
       'hs-show-block)))

This will make <C-tab> show a hidden block.  If the block is
shown, then it'll be hidden."
  `(define-key ,keymap ,key
     `(menu-item "context-key" ignore
                 :filter ,(lambda (&optional ignored)
                            ,dispatch))))
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: mykie.el

[Stefan Monnier]

> can add different clauses separately.  Ideally, it would be cool if it
> allowed to define the same key in different keymaps and still be working
> as expected.  E.g.:

>   (define-context-key outline-minor-mode-map (kbd "TAB")
>     :predicate outline-heading-p
>     :action org-cycle)

>   (define-context-key emacs-lisp-mode-map (kbd "TAB")
>     :predicate beginning-of-defun-p
>     :action eval-defun)

AFAIK we don't know how to implement it.


        Stefan

Re: mykie.el

[Yuta Yamada]

Sorry, I forgot to conform a problem when we define keybind by
anonymous function to [a-z] key of self-insert-command.

rubikitch who contribute mykie.el about this problem pull-requested :
https://github.com/yuutayamada/mykie-el/pull/5

If we define contextual-command by anonymous function, cannot use
Mew.el.
I'm not sure the detail.
But actually I couldn't use old version mykie's keybind related
self-insert-command at Mew.el.
(I heard Mew.el make sure keybind's name from @rubikitch on twitter)

Old version mykie.el registration form is like this:
※ this form can use current version too
(global-set-key "a"
                (lambda ()
                  (interactive)
                  (mykie :default 'self-insert-command
                         :C-u     '(message "C-u"))))

Current version(future branch):

(mykie:define-key-with-self-key "a"
  ;; we don't need self-insert-command
  :C-u     (message "C-u"))

Or

(mykie:global-set-key "a"
  ;; you can specify t instead of :default too
  :default self-insert-command
  :C-u     (message "C-u"))

Or

(mykie:define-key global-map "a"
  :default self-insert-command
  :C-u     (message "C-u"))

Or

Below function is more convenient than others.
This function can register multiple keybinds.

(mykie:set-keys 'with-self-key
  "a" :C-u     (message "C-u of a")
  "b" :C-u     (message "C-u of b"))

You can specify specific keymap instead of 'with-self-key.
If you specified nil then register keybinds to global-map.

(mykie:set-keys emacs-lisp-mode-map

  "C-0"
  :default (message "default of C-0")
  :C-u     (message "C-u of C-0")

  "C-1"
  :default (message "default of C-1")
  :C-u     (message "C-u of C-1")
  ;; you can add more keybinds
  )

Re: mykie.el

[Yuta Yamada]

Hi, I asked someone about how to implement `mykie' function by using
macro. But somehow I could implement by myself. Sorry bother you.
And I could add parenthesized syntax too at feature branch.
https://github.com/yuutayamada/mykie-el/tree/feature
(I mistyped branch name, so renamed from future -> feature)

Mykie parenthesized syntax:
;; use * to use parenthesized syntax
(mykie:define-key* global-map "C-j"
   (:default (message "default")
             (message "second line"))
   (:C-u     (message "C-u function")))

Re: mykie.el

[Stefan Monnier]

> (mykie:define-key* global-map "C-j"

Why this instead of

  (define-key global-map "C-j" (mykie


-- Stefan

Re: mykie.el

[Yuta Yamada]

> > (mykie:define-key* global-map "C-j"

> Why this instead of

>   (define-key global-map "C-j" (mykie

There is a problem.
Mew.el that is Emacs mailer check function name whether the name
contain self-insert-command.(http://www.mew.org/en/)
(I don't know how many program does check global map's function-name.)

If we set keybind to self-insert-command like [a-z],
then Mew occur an error.

To solve this problem, mykie create function name automatically.
But to create function name, use keymap name and key name.

If I create the solving function. setting is like this?

(define-key global-map (kbd "a")
  (mykie:combined-command global-map "a"
    :default self-insert-command
    :C-u     (message "C-u + a")))

User needs extra argument...

Or use `advice' to global-set-key, define-key?
I might can write more simply.

But if nobody care function name, then I could write:

(defmacro mykie:combined-command (&rest args)
  `(lambda ()
     (interactive)
     (mykei:core (quote ,args))))

(global-set-key (kbd "C-0")
   (mykie:combined-command :default (message "foo")))

Using anonymous function or named function, which is recommending?
I think we might create function to lookup the keybind information if
we choose named function.

Yuta

Re: mykie.el

[Stefan Monnier]

>> (define-key global-map "C-j" (mykie
                           ^^^
                           \C-j

Sorry.

> There is a problem.
> Mew.el that is Emacs mailer check function name whether the name
> contain self-insert-command.(http://www.mew.org/en/)
> (I don't know how many program does check global map's function-name.)
> If we set keybind to self-insert-command like [a-z],
> then Mew occur an error.

I don't understand.


        Stefan

Re: mykie.el

[Yuta Yamada]

> > There is a problem.
> > Mew.el that is Emacs mailer check function name whether the name
> > contain self-insert-command.(http://www.mew.org/en/)
> > (I don't know how many program does check global map's function-name.)
> > If we set keybind to self-insert-command like [a-z],
> > then Mew occur an error.

> I don't understand.

Sorry my information lacked details.

Mew.el can change folder by pushing "g" key at mew-summary-mode.
(Mew binds mew-summary-goto-folder function to the "g" key)
To make sure that problem, I set following configuration:

(define-key global-map
  "a" (lambda () (interactive)
        (call-interactively 'self-insert-command)))

(defmacro mykie:combined-command (&rest args)
  `(lambda ()
     (interactive)
     (mykie:core (quote ,args))))

(define-key global-map
  "b" (mykie:combined-command
       :default self-insert-command
       :C-u     (message "C-u + b")))

And then I typed "g" at mew-summary-mode after I boot mew.
And then when I typed a or b, I saw following error on minibuffer.

-- error message
mew-input-folder-self-insert: Wrong type argument: symbolp, #[nil "ÀÁ!‡" [call-interactively self-insert-command] 2 nil nil]
--

I extracted partial code from mew-minibuf.el, you can see full code
here: https://github.com/kazu-yamamoto/Mew/blob/master/mew-minibuf.el

--- from mew-minibuf.el ---
(defun mew-input-folder-self-insert ()
  "This function normally inserts its bound key to minibuffer.
When in folder search mode, this function searches a candidate
folder and displays it in addition to its bound key."
  (interactive)
  (let ((key (this-command-keys))
        last-str gfunc)
    (cond
     ((stringp key)
      (setq last-str key)
      (setq gfunc (lookup-key (current-global-map) key)))
     ((vectorp key)
      (setq gfunc (lookup-key (current-global-map) key))
      (unless gfunc
        (setq key (lookup-key function-key-map key))
        (cond
         ((vectorp key) ;; normal Emacs
         (setq gfunc (lookup-key (current-global-map) key)))
         ((stringp key) ;; Meadow
         (setq last-str key)
         (setq gfunc (lookup-key (current-global-map) key)))))))
    (if mew-input-folder-search-direction
        (cond
         ((or (equal key "\177") (equal key [127])
         (equal key 'delete) (equal key 'backspace))
         (if (null mew-input-folder-search-key)
         (mew-input-folder-display "not allowed")
         (setq mew-input-folder-search-key
                 (substring mew-input-folder-search-key 0 -1))
         (when (string= mew-input-folder-search-key "")
         (setq mew-input-folder-search-key nil)
         (setq mew-input-folder-search-match nil)
         (with-current-buffer mew-input-folder-search-buf
                (cond
                 ((eq mew-input-folder-search-direction 'forward)
                 (goto-char (point-min)))
                 ((eq mew-input-folder-search-direction 'backward)
                 (goto-char (point-max))))))
         (mew-input-folder-display)))
         ((not (string-match "self-insert-command" (symbol-name gfunc)))
         (mew-input-folder-display "not allowed"))
         ((eq mew-input-folder-search-direction 'forward)
         (setq mew-input-folder-search-key
                (concat mew-input-folder-search-key last-str))
         (mew-input-folder-search-forward-1))
         ((eq mew-input-folder-search-direction 'backward)
         (setq mew-input-folder-search-key
                (concat mew-input-folder-search-key last-str))
         (mew-input-folder-search-backward-1)))
      (cond
       ((null gfunc)
        ())
       ((string-match "self-insert-command" (symbol-name gfunc))
        (insert last-command-event))
       ((and (fboundp gfunc) (commandp gfunc))
        (call-interactively gfunc))))))
--- END ----

I think below part seems problem codes.

---
  ;; gfunc is current global-map's function
  ((not (string-match "self-insert-command" (symbol-name gfunc)))
   (mew-input-folder-display "not allowed"))
---

Yuta

Re: mykie.el

[Stefan Monnier]

>   ;; gfunc is current global-map's function
>   ((not (string-match "self-insert-command" (symbol-name gfunc)))
>    (mew-input-folder-display "not allowed"))

That's a bug in Mew.  We don't need to worry about it (but do report
it, of course, so the Mew guys can fix it),


        Stefan

Re: mykie.el

[Yuta Yamada]

> >   ;; gfunc is current global-map's function
> >   ((not (string-match "self-insert-command" (symbol-name gfunc)))
> >    (mew-input-folder-display "not allowed"))

> That's a bug in Mew.  We don't need to worry about it (but do report
> it, of course, so the Mew guys can fix it),

I see.
That's means Emacs devel or common emacser do not restrict user keybind
of self-insert-command, isn't it?

Anyway I'll report or pull-req to Mew's developer about it.
Thank you for advice!

Yuta

Re: mykie.el

[Stefan Monnier]

> That's means Emacs devel or common emacser do not restrict user keybind
> of self-insert-command, isn't it?

This has nothing to do with self-insert-command, really.  Mew assumes
that the key-binding it gets is either nil or a symbol, whereas
a command can also be a byte-code vector, a plain vector, or a list
(representing an interpreted lambda expression).  So Mew's code needs
a `symbolp' test before calling `symbol-name'.


        Stefan

Re: mykie.el

[Yuta Yamada]

> > That's means Emacs devel or common emacser do not restrict user keybind
> > of self-insert-command, isn't it?

> This has nothing to do with self-insert-command, really.  Mew assumes
> that the key-binding it gets is either nil or a symbol, whereas
> a command can also be a byte-code vector, a plain vector, or a list
> (representing an interpreted lambda expression).  So Mew's code needs
> a `symbolp' test before calling `symbol-name'.

Sorry, I misunderstood.
(And I pull-requested fixed commit to Mew)

Yuta

Re: mykie.el

[Yuta Yamada]

> > SM> You could add it to subr-x.el (after 24.4),
> 
> > Wonderful, thanks.  Yamada-san, WDYT?  Do you want to work on the
> > approach Stefan suggested in the Emacs core and integrate mykie.el with
> > it, or would you rather keep mykie.el separate from this work?
> 
> 

Oh, I misunderstood meaning.
(Sorry I'm English learner yet.)

That means mykie can in the Emacs core if mykie fixed the cosmetic
problems. right?
If it's yes.
I would like mykie to in the Emacs core.

I already fixed some cosmetic issues at future branch.
done:
 - delete needless quotation
 - treat 't symbol as default function
almost done:
 - delete wrong eval(remaining two eval...)
yet:
 - use parenthesized syntax to lispish
 - mykie:global-set-key -> other name

However current mykie took just different approach to check conditions.
Below function is mykie's core logic.

(defun* mykie (&rest args &allow-other-keys)
  (catch 'done
    ;;    ↓ check wheter ignore major-mode overriding
    (loop initially (when (eq 'exit (mykie:init args)) (return))
          ;; collect user specified keywords
          with keywords = (loop for arg in args if (keywordp arg) collect arg)
          ;; conditions separate three group: region, C-u, otherwise
          for conditions in mykie:group-conditions
          ;; check region-acitive-p or current-prefix-arg if needed
          if (funcall mykie:precheck-function conditions) do
          (loop with conds = (symbol-value conditions)
                for keyword in keywords
                ;; conds is like (:C-u&eolp . (eolp))
                if (and (loop for (expect . c) in conds
                              if (or (eq expect keyword)
                                     ;; irregular case for :MAJOR-MODE
                                     ;; C-u*N, M-N
                                     (and (stringp expect)
                                          (string-match
                                           expect (symbol-name keyword))))
                              do (return t))
                        (mykie:predicate conds keyword))
                do (progn (setq mykie:current-state keyword)
                          ;; do specific command
                          (mykie:execute (plist-get args keyword))
                          (throw 'done 'done)))
          ;; do :default or t's function if function was not found
          finally (mykie:execute (or (plist-get args :default)
                                     (plist-get args t)))))
  ;; for :repeat
  (unless (mykie:repeat-p)
    (setq mykie:current-point (point))))

I like pre check function that can ignore needless conditions.
Is it ok?
There is a merit. User don't need useless (region-active-p) or
current-prefix-arg when user register user's condition.

About remaining cosmetic issues,
 - mykie:global-set-key -> ather name and use combind macro

Above mykie function can call like this
(mykie :default '(message "default") :C-u '(message "C-u"))

I don't have much experience of lisp macro.
So I can't say correctly whether it can implement by lisp macro.
But can we use like this?:

(defmacro sm-combind-command (&rest branches)
  `(lambda ()
     (interactive)
     (apply 'mykie ,branches)))

I tried above macro, but I couldn't use correctly.
Could someone help me?
Or Is it impossible?

yet:
 - use parenthesized syntax to lispish

I prefer without parenthesized syntax.
But if we can use above macro then it's easy to create parenthesized
syntax or not too.

Sorry long sentence.
I want to know current mykie can use at next Emacs core.
Or do I need more change?

Yuta

Re: mykie.el

[Yuta Yamada]

Hello, mykie.el was updated recently to v0.1.1.
Let's me introduce little bit to advance discussion.

New version mykie can change order by each keybinds like this:

(setq mykie:use-lazy-order t) ; <- this is requirement
(mykie:set-keys nil ; <- nil means registering global-map
   "C-0"
   :default '(message "hi")
   :C-u*2   '(message "howdy")
   :C-u     '(message "hello")
   :C-u*3   '(message "hey") ; <- you can't see
   "C-1"
   :default '(message "hi")
   :C-u*3   '(message "howdy")
   :C-u     '(message "hello")
   :C-u*2   '(message "hey")) ; <- you can't see

As you can see above example is reverse part of :C-u*2 and :C-u*3.
This example is prior above :keyword and function pair without :default
when you set t to `mykie:use-lazy-order'.
So if you do this example, you can't execute C-0's :C-u*3 function and
C-1's :C-u*2 function.
Since mykie will execute :C-u's function.(:C-u*2 and :C-u*3 satisfy
:C-u's condition too)

This function can control order without conditional.
I don't know how many people like this future,
but I think it's easy to understand the function's structure.

Yuta

P.S. new version is added :err, :C-u&err, :region&err that activate
function when current state have flymake or flycheck error too.