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

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?

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

[tomas]

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[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.
 

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

[tomas]

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[John Yates]

On Tue, Jul 30, 2019 at 9:31 AM <tomas@tuxteam.de> 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

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

[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.
 

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

[tomas]

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Stefan Monnier]

> 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))

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

[Eli Zaretskii]

> Date: Tue, 30 Jul 2019 16:13:06 +0200
> From: <tomas@tuxteam.de>
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> 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.

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

[Emanuel Berg]

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

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

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

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

[Óscar Fuentes]

ndame <emacsuser@freemail.hu> 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.

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

[Óscar Fuentes]

ndame <emacsuser@freemail.hu> 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.