What is the policy for moving a feature into core or not?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

What is the policy for moving a feature into core or not?

ndame
Let's take the kill ring. It's a central piece of emacs, yet I don't see any keyboard
based solution built in to browse and search the kill ring. M-y is extremely basic. There is
a menu, but it's mouse based, inefficient.

There are external packages, of course, but I wonder if there should be a builtin way to
navigate and search the kill ring from the keyboard. By builtin I mean a package available
from at least elpa.

Is there a current policy which governs what features are integrated into the core (elpa) 
and what features are left to outside developers?
Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Tomas Zerolo
On Tue, Jul 30, 2019 at 06:20:34AM +0000, ndame wrote:
> Let's take the kill ring. It's a central piece of emacs, yet I don't see any keyboard
> based solution built in to browse and search the kill ring. M-y is extremely basic. There is
> a menu, but it's mouse based, inefficient.
>
> There are external packages, of course, but I wonder if there should be a builtin way to
> navigate and search the kill ring from the keyboard. By builtin I mean a package available
> from at least elpa.

Hm. Doing "M-x package-list-packages" and searching there for "kill" yields a few
hits, among them:

  browse-kill-ring  2.0.0   available  melpa-s... interactively insert items from kill-ring
  easy-kill         0.9.3   available  gnu        kill & mark things easily
  kill-ring-search  1.1     available  melpa-s... incremental search for the kill ring

(and several more; DISCLAIMER: I haven't tried any of them).

Perhaps one of those could fit your needs? Or be a starting point?

> Is there a current policy which governs what features are integrated into the core (elpa) 
> and what features are left to outside developers?

The only formal hurdle is the copyright assignment papers [0] (if you
want your code into Emacs or Elpa; there are alternatives). And if you
trust the FSF, this hurdle is minimal.

The informal hurdle is getting your stuff out there, maintaining it,
and convincing people that it's worth it having a look. Easy stuff,
really [1] ;-P

Cheers

[0] https://www.fsf.org/licensing/assigning.html/?searchterm=copyright%20assignment

[1] No, just kidding. And reminding myself of the nearly infinite debt
   I'm in towards the free software community.

-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

ndame
In reply to this post by ndame
> Hm. Doing "M-x package-list-packages" and searching there for "kill" yields a 
> few hits, among them:

As I said I know about such external packages, and it was only an example.
I'm just wondering if there is policy of keeping the core (elpa included) small to
lessen the burden of emacs maintainers, or there is no such policy, 
and if people submitted the necessary papers then they could dump packages into
elpa by the thousand.
 
Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Tomas Zerolo
On Tue, Jul 30, 2019 at 01:58:14PM +0200, ndame wrote:
> > Hm. Doing "M-x package-list-packages" and searching there for "kill" yields a 
> > few hits, among them:
>
> As I said I know about such external packages, and it was only an example.
> I'm just wondering if there is policy of keeping the core (elpa included) small to
> lessen the burden of emacs maintainers, or there is no such policy, 
> and if people submitted the necessary papers then they could dump packages into
> elpa by the thousand.

I'd first try one :-)

No, seriously. On the other side there are people, not machines. But as
far as contributing to GNU Elpa is concerned, [1] and [2] give a pretty
complete overview

Cheers

[1] https://www.emacswiki.org/emacs/ELPA
[2] http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

John Yates-4
On Tue, Jul 30, 2019 at 9:31 AM <[hidden email]> wrote:

>
> I'd first try one :-)
>
> No, seriously. On the other side there are people, not machines. But as
> far as contributing to GNU Elpa is concerned, [1] and [2] give a pretty
> complete overview
>
> Cheers
>
> [1] https://www.emacswiki.org/emacs/ELPA
> [2] http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

My sense is that the OP's question was not so much about
mechanics but rather about the level of curation.

/john

Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

ndame
In reply to this post by ndame
> My sense is that the OP's question was not so much about
> mechanics but rather about the level of curation.

Exactly. I don't want to put a package into the core right now. I'm just
curious if there is a distinction of packages "belonging to the core" or
anything can go into the core regardless of purpose if the papers are OK.
 
Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Tomas Zerolo
On Tue, Jul 30, 2019 at 04:10:09PM +0200, ndame wrote:
> > My sense is that the OP's question was not so much about
> > mechanics but rather about the level of curation.
>
> Exactly. I don't want to put a package into the core right now. I'm just
> curious if there is a distinction of packages "belonging to the core" or
> anything can go into the core regardless of purpose if the papers are OK.

No idea whether there's any formalism in place.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Stefan Monnier
In reply to this post by ndame
> As I said I know about such external packages, and it was only an example.
> I'm just wondering if there is policy of keeping the core (elpa included) small to
> lessen the burden of emacs maintainers, or there is no such policy, 
> and if people submitted the necessary papers then they could dump packages into
> elpa by the thousand.

For GNU ELPA specifically, there is no special policy: any package is
acceptable, basically.

For Emacs's core, there is no clear cut policy, but since the advent of
GNU ELPA we've tried to add packages there rather than in Emacs itself,
because it makes it much easier for the package to evolve at its own
pace (i.e. better for the package's maintainer) and it lessens the
burden for Emacs's maintainers as well.


        Stefan


PS: Here's my own kill ring browser, which I call from `yank-pop` when the
last command was not `yank`.


(defun yank-browse (string)
  "Browse the `kill-ring' to choose which entry to yank."
  (interactive
   (minibuffer-with-setup-hook #'minibuffer-completion-help
     (let* ((kills (delete-dups (append kill-ring-yank-pointer kill-ring nil)))
            (entries
             (mapcar (lambda (string)
                       (let ((pos 0))
                         ;; FIXME: Maybe we should start by removing
                         ;; all properties.
                         (setq string (copy-sequence string))
                         (while (string-match "\n" string pos)
                           ;; FIXME: Maybe completion--insert-strings should
                           ;; do that for us.
                           (put-text-property
                            (match-beginning 0) (match-end 0)
                            'display (eval-when-compile
                                       (propertize "\\n" 'face 'escape-glyph))
                            string)
                           (setq pos (match-end 0)))
                         ;; FIXME: We may use the window-width of the
                         ;; wrong window.
                         (when (>= (* 3 (string-width string))
                                   (* 2 (window-width)))
                           (let ((half (- (/ (window-width) 3) 1)))
                             ;; FIXME: We're using char-counts rather than
                             ;; width-count.
                             (put-text-property
                              half (- (length string) half)
                              'display (eval-when-compile
                                         (propertize "……" 'face 'escape-glyph))
                              string)))
                         string))
                     kills))
            (table (lambda (string pred action)
                     (cond
                      ((eq action 'metadata)
                       '(metadata (category . kill-ring)))
                      (t
                       (complete-with-action action entries string pred))))))
       ;; FIXME: We should return the entry from the kill-ring rather than
       ;; the entry from the completion-table.
       ;; FIXME: substring completion doesn't work well because it only matches
       ;; subtrings before the first \n.
       ;; FIXME: completion--insert-strings assumes that boundaries of
       ;; candidates are obvious enough, but with kill-ring entries this is not
       ;; true, so we'd probably want to display them with «...» around them.
       (list (completing-read "Yank: " table nil t)))))
  (setq this-command 'yank)
  (insert-for-yank string))


Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Eli Zaretskii
In reply to this post by Tomas Zerolo
> Date: Tue, 30 Jul 2019 16:13:06 +0200
> From: <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
>
> On Tue, Jul 30, 2019 at 04:10:09PM +0200, ndame wrote:
> > > My sense is that the OP's question was not so much about
> > > mechanics but rather about the level of curation.
> >
> > Exactly. I don't want to put a package into the core right now. I'm just
> > curious if there is a distinction of packages "belonging to the core" or
> > anything can go into the core regardless of purpose if the papers are OK.
>
> No idea whether there's any formalism in place.

No formal policy, just pragmatic decisions.

Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Emanuel Berg-5
In reply to this post by Stefan Monnier
Stefan Monnier wrote:

> For GNU ELPA specifically, there is no
> special policy: any package is
> acceptable, basically.

Really? You are not browsing the code to see if
it makes sense and does something that is
useful to some thinkable subset of the Emacs
user base?

> PS: Here's my own kill ring browser, which
> I call from `yank-pop` when the last command
> was not `yank`.

I have this. I suppose it is one of those lines
of code you are not supposed to understand.

(defun yank-pop-back (&optional arg)
  (interactive "*p")
  (yank-pop (if arg (* arg -1) -1)) )

https://dataswamp.org/~incal/emacs-init/yank-my.el

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal


Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Stefan Monnier
>> For GNU ELPA specifically, there is no
>> special policy: any package is
>> acceptable, basically.
> Really? You are not browsing the code to see if
> it makes sense and does something that is
> useful to some thinkable subset of the Emacs
> user base?

I think this goes without saying (other I would have said "any package
whatsoever" or something like that).


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Emacs - Help mailing list
In reply to this post by ndame
ndame wrote:

> There are external packages, of course, but
> I wonder if there should be a builtin way to
> navigate and search the kill ring from the
> keyboard. By builtin I mean a package
> available from at least elpa.

OK, so what external package that contains kill
ring utilities is it that you want integrated
with core Emacs?

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal


Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Óscar Fuentes
In reply to this post by ndame
ndame <[hidden email]> writes:

> Let's take the kill ring. It's a central piece of emacs, yet I don't see any keyboard
> based solution built in to browse and search the kill ring. M-y is extremely basic. There is
> a menu, but it's mouse based, inefficient.
>
> There are external packages, of course, but I wonder if there should be a builtin way to
> navigate and search the kill ring from the keyboard. By builtin I mean a package available
> from at least elpa.

Elpa has undo-tree.

> Is there a current policy which governs what features are integrated into the core (elpa) 
> and what features are left to outside developers?

Elpa is not core. Anyone can contribute a package to Elpa as long as it
meets certain quality and legal requirements. It is relatively easy and
painless.

Contributions to core Emacs must meet much more strict quality and
usability requirements. Typically, long discussions ensue even for
apparently trivial details.

BTW, I'm not an Emacs maintainer. This is what I learnt after years of
observing the community.


Reply | Threaded
Open this post in threaded view
|

Re: What is the policy for moving a feature into core or not?

Óscar Fuentes
In reply to this post by ndame
ndame <[hidden email]> writes:

> Let's take the kill ring. It's a central piece of emacs, yet I don't see any keyboard
> based solution built in to browse and search the kill ring. M-y is extremely basic. There is
> a menu, but it's mouse based, inefficient.
>
> There are external packages, of course, but I wonder if there should be a builtin way to
> navigate and search the kill ring from the keyboard. By builtin I mean a package available
> from at least elpa.

Elpa has undo-tree.

> Is there a current policy which governs what features are integrated into the core (elpa) 
> and what features are left to outside developers?

Elpa is not core. Anyone can contribute a package to Elpa as long as it
meets certain quality and legal requirements. It is relatively easy and
painless.

Contributions to core Emacs must meet much more strict quality and
usability requirements. Typically, long discussions ensue even for
apparently trivial details.

BTW, I'm not an Emacs maintainer. This is what I learnt after years of
observing the community.