* Re: What is the policy for moving a feature into core or not?
@ 2019-07-30 14:10 ndame
2019-07-30 14:13 ` tomas
0 siblings, 1 reply; 14+ messages in thread
From: ndame @ 2019-07-30 14:10 UTC (permalink / raw)
To: help-gnu-emacs@gnu.org
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 14:10 What is the policy for moving a feature into core or not? ndame
@ 2019-07-30 14:13 ` tomas
2019-07-30 14:53 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: tomas @ 2019-07-30 14:13 UTC (permalink / raw)
To: ndame; +Cc: help-gnu-emacs@gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 14:13 ` tomas
@ 2019-07-30 14:53 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2019-07-30 14:53 UTC (permalink / raw)
To: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
@ 2019-07-30 11:58 ndame
2019-07-30 13:31 ` tomas
2019-07-30 14:34 ` Stefan Monnier
0 siblings, 2 replies; 14+ messages in thread
From: ndame @ 2019-07-30 11:58 UTC (permalink / raw)
To: help-gnu-emacs@gnu.org
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 11:58 ndame
@ 2019-07-30 13:31 ` tomas
2019-07-30 13:59 ` John Yates
2019-07-30 14:34 ` Stefan Monnier
1 sibling, 1 reply; 14+ messages in thread
From: tomas @ 2019-07-30 13:31 UTC (permalink / raw)
To: help-gnu-emacs
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 11:58 ndame
2019-07-30 13:31 ` tomas
@ 2019-07-30 14:34 ` Stefan Monnier
2019-08-03 17:45 ` Emanuel Berg
1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2019-07-30 14:34 UTC (permalink / raw)
To: help-gnu-emacs
> 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))
^ permalink raw reply [flat|nested] 14+ messages in thread
* What is the policy for moving a feature into core or not?
@ 2019-07-30 6:20 ndame
2019-07-30 7:31 ` tomas
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: ndame @ 2019-07-30 6:20 UTC (permalink / raw)
To: help-gnu-emacs@gnu.org
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 6:20 ndame
@ 2019-07-30 7:31 ` tomas
2019-12-14 11:29 ` Emanuel Berg via Users list for the GNU Emacs text editor
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: tomas @ 2019-07-30 7:31 UTC (permalink / raw)
To: help-gnu-emacs
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 6:20 ndame
2019-07-30 7:31 ` tomas
@ 2019-12-14 11:29 ` Emanuel Berg via Users list for the GNU Emacs text editor
2019-12-14 12:30 ` Óscar Fuentes
2019-12-14 14:05 ` Óscar Fuentes
3 siblings, 0 replies; 14+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2019-12-14 11:29 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 6:20 ndame
2019-07-30 7:31 ` tomas
2019-12-14 11:29 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2019-12-14 12:30 ` Óscar Fuentes
2019-12-14 14:05 ` Óscar Fuentes
3 siblings, 0 replies; 14+ messages in thread
From: Óscar Fuentes @ 2019-12-14 12:30 UTC (permalink / raw)
To: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the policy for moving a feature into core or not?
2019-07-30 6:20 ndame
` (2 preceding siblings ...)
2019-12-14 12:30 ` Óscar Fuentes
@ 2019-12-14 14:05 ` Óscar Fuentes
3 siblings, 0 replies; 14+ messages in thread
From: Óscar Fuentes @ 2019-12-14 14:05 UTC (permalink / raw)
To: ndame; +Cc: help-gnu-emacs@gnu.org
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-12-14 14:05 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-30 14:10 What is the policy for moving a feature into core or not? ndame
2019-07-30 14:13 ` tomas
2019-07-30 14:53 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2019-07-30 11:58 ndame
2019-07-30 13:31 ` tomas
2019-07-30 13:59 ` John Yates
2019-07-30 14:34 ` Stefan Monnier
2019-08-03 17:45 ` Emanuel Berg
2019-08-04 13:05 ` Stefan Monnier
2019-07-30 6:20 ndame
2019-07-30 7:31 ` tomas
2019-12-14 11:29 ` Emanuel Berg via Users list for the GNU Emacs text editor
2019-12-14 12:30 ` Óscar Fuentes
2019-12-14 14:05 ` Óscar Fuentes
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.