Dear Maintainer,
The functions home-end-end and home-end home didn't work for me,
because they were assuming a keyboard-event (key-press) was being
stored as a single byte, or single element, in the vector returned by
funciton recent-keys. However, on my machine at least, each of those
key-presses seems to be three bytes in length, and is recorded as
three elements of the vector returned by recent-keys. ( [home] was
being recorded as the sequence '27 79 72' (ESC-O-H); [end] was being
recorded as the sequence '27 79 70' (ESC-O-F)).
So, I started modifying the code. Results below.
While I was at it, I generalized the core functionality into a
separate function, so that it might easily and portably be re-used for
repeating other (three-byte-long) keyboard-events. I supose I could
rewrite it for an unlimited number of unique repetition reactions to
any-byte-length event, but I don't see the pressing need for such.
;---------------------------------------------------------------------
(defun home-quadruple-play (&optional arg)
"React uniquely to repeated presses of the `home' key. A first key-pre\
ss moves the point to the beginning of the current line; a second key-pr\
ess moves the point to the beginning of the current visible window, and;\
a third key-press moves the point to the beginning of the buffer.
Additionally, with numeric `arg' N, this command calls function `begi\
nning-of-buffer' to move the point to the (N*10)% position of the buffer\
..
Recommended usage is to bind this function to the `home' key by, for i\
nstance, placing the following in the .emacs file:
`(global-set-key [home] \'home-quadruple-play)'"
(interactive "P")
(if arg
(beginning-of-buffer arg)
(keypress-triple-play
'(lambda() (setq home-end-marker (copy-marker (point)))
(beginning-of-line))
'(lambda() (push-mark home-end-marker)
(move-to-window-line 0))
'(lambda() (goto-char (point-min))))
))
(defun end-quadruple-play (&optional arg)
"React uniquely to repeated presses of the `end' key. A first key-pres\
s moves the point to the end of the current line; a second key-press mov\
es the point to the end of the current visible window, and; a third key-\
press moves the point to the end of the buffer.
Additionally, with numeric `arg' N, this command calls function `end-\
of-buffer' to move the point to the (100-N*10)% position of the buffer.
Recommended usage is to bind this function to the `end' key by, for in\
stance, placing the following in the .emacs file:
`(global-set-key [end] \'end-quadruple-play)'"
(interactive "P")
(if arg
(end-of-buffer arg)
(keypress-triple-play
'(lambda() (setq home-end-marker (copy-marker (point)))
(end-of-line))
'(lambda() (push-mark home-end-marker)
(move-to-window-line -1)
(end-of-line))
'(lambda() (goto-char (point-max))))
))
(defun keypress-triple-play (react_1 react_2 react_3)
"Respond to a repeated keyboard-event (key-press) based upon the numbe\
r of its repetitions. When the key-press has been performed once, react_\
by calling function `react_1'; When the key-press is repeated once, rea\
ct_ by calling function `react_2'; When the key-press is repeated more o\
ften, react_ by calling function `react_3'.
This function was originally written to support functions `home-quadr\
uple-play' and `end-quadruple-play'. See there as example usages. These \
three functions replace functions `home-end-home' and `home-end-end' in \
file `home-end.el' of Debian\'s `emacs-goodies-el' package."
(interactive)
(if (or executing-kbd-macro
defining-kbd-macro)
(funcall react_1))
(let* ((keys (recent-keys))
(len (length keys))
(key1 (if (> len 3) (vector (elt keys (- len 1))
(elt keys (- len 2))
(elt keys (- len 3)))
nil))
(key2 (if (> len 6) (vector (elt keys (- len 4))
(elt keys (- len 5))
(elt keys (- len 6)))
nil))
(key3 (if (> len 9) (vector (elt keys (- len 7))
(elt keys (- len 8))
(elt keys (- len 9)))
nil))
(key-equal-1 (equal key1 key2))
(key-equal-2 (and key-equal-1 (equal key2 key3))))
(cond
(key-equal-2 (funcall react_3))
(key-equal-1 (funcall react_2))
(t (funcall react_1))
)))
;---------------------------------------------------------------------
The flaw with my original patch is that it is too specific. Even on my
own computer, the ascii sequences generated will differ in length when
using emacs differently (eg. emacs-nox in gui frame versus in a tty
session without X). The SOLUTION (thank you, Stefan Monnier) was to not
use function `recall-keys', which was meant to be a debug tool only, and
instead, to use variables `this-command' and `last-command'
(defvar home-end-marker)
(defvar my-command-state 0)
(global-set-key [home] 'home-quadruple-play)
(global-set-key [end] 'end-quadruple-play)
(defun home-quadruple-play (&optional arg)
"React uniquely to repeated presses of the `home' key. A first
key-press moves the point to the beginning of the current line; a second
key-press mo\
ves the point to the beginning of the current visible window, and; a
third key-press moves the point to the beginning of the buffer.
Additionally, with numeric `arg' N, this command calls function
`beginning-of-buffer' to move the point to the (N*10)% position of the
buffer.
Recommended usage is to bind this function to the `home' key by, for
instance, placing the following in the .emacs file:
`(global-set-key [home] \'home-quadruple-play)'"
(interactive "P")
(if arg
(beginning-of-buffer arg)
(keypress-triple-play
(lambda() (setq home-end-marker (copy-marker (point)))
(beginning-of-line))
(lambda() (push-mark home-end-marker)
(move-to-window-line 0))
(lambda() (goto-char (point-min))))))
(defun end-quadruple-play (&optional arg)
"React uniquely to repeated presses of the `end' key. A first
key-press moves the point to the end of the current line; a second
key-press moves the\
point to the end of the current visible window, and; a third key-press
moves the point to the end of the buffer.
Additionally, with numeric `arg' N, this command calls function
`end-of-buffer' to move the point to the (100-N*10)% position of the
buffer.
Recommended usage is to bind this function to the `end' key by, for
instance, placing the following in the .emacs file:
`(global-set-key [end] \'end-quadruple-play)'"
(interactive "P")
(if arg
(end-of-buffer arg)
(keypress-triple-play
(lambda() (setq home-end-marker (copy-marker (point)))
(end-of-line))
(lambda() (push-mark home-end-marker)
(move-to-window-line -1)
(end-of-line))
(lambda() (goto-char (point-max))))))
(defun keypress-triple-play (react_1 react_2 react_3)
"Respond to a repeated keyboard-event (key-press) based upon the
number of its repetitions. When the key-press has been performed once,
reactby call\
ing function `react_1'; When the key-press is repeated once, react by
calling function `react_2'; When the key-press is repeated more often,
reactby c\
alling function `react_3'.
This function was originally written to support functions
`home-quadruple-play' and `end-quadruple-play'. See there as example
usages. These three \
functions replace functions `home-end-home' and `home-end-end' in file
`home-end.el' of Debian\'s `emacs-goodies-el' package."
(interactive)
(if (or executing-kbd-macro
defining-kbd-macro)
(funcall react_1))
(setq my-command-state (if (eq this-command last-command)
(1+ my-command-state)
0))
(pcase my-command-state
(`0 (funcall react_1))
(`1 (funcall react_2))
(`2 (funcall react_3))))
control: retitle -1 remove home-end.el control: severity -1 important Dear Boruch; Thanks very much for taking the time to write a fix for the problem with home-end.el. Unfortunately Debian acting as upstream for many small emacs packages is not sustainable so we're retiring parts of emacs-goodies-el which seem to need substantial maintainance and have no upstream home. If you happen to want to take on maintaining an upstream package of home-end.el (e.g. on melpa.org), then we'd be happy to look at packaging that.
Hi Boruch, In a moment I will remove home-end.el from emacs-goodies-el in git, and as David mentioned we would be happy to package a maintained copy. For your convenience, in case you're interested: # git clone https://salsa.debian.org/emacsen-team/emacs-goodies-el.git # git checkout debian/37.0 File is here: elisp/emacs-goodies-el/home-end.el And there's some documentation here: elisp/emacs-goodies-el/emacs-goodies-el.texi And it's customisation options are defined here: elisp/emacs-goodies-el/emacs-goodies-el.el Alternatively, I wonder if the following would be more useful: https://github.com/maximbaz/emacs-smart-home-end Cheers, Nicholas
Hi Boruch, In a moment I will remove home-end.el from emacs-goodies-el in git, and as David mentioned we would be happy to package a maintained copy. For your convenience, in case you're interested: # git clone https://salsa.debian.org/emacsen-team/emacs-goodies-el.git # git checkout debian/37.0 File is here: elisp/emacs-goodies-el/home-end.el And there's some documentation here: elisp/emacs-goodies-el/emacs-goodies-el.texi And it's customisation options are defined here: elisp/emacs-goodies-el/emacs-goodies-el.el Alternatively, I wonder if the following would be more useful: https://github.com/maximbaz/emacs-smart-home-end Cheers, Nicholas
We believe that the bug you reported is fixed in the latest version of
emacs-goodies-el, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 759721@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
David Bremner <bremner@debian.org> (supplier of updated emacs-goodies-el package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 30 Jun 2018 07:36:47 -0300
Source: emacs-goodies-el
Binary: emacs-goodies-el devscripts-el
Architecture: source
Version: 38.0
Distribution: experimental
Urgency: medium
Maintainer: Debian Emacsen team <debian-emacsen@lists.debian.org>
Changed-By: David Bremner <bremner@debian.org>
Description:
devscripts-el - Emacs wrappers for the commands in devscripts
emacs-goodies-el - Miscellaneous add-ons for Emacs
Closes: 495989 552164 581238 584305 591432 759721 850151
Changes:
emacs-goodies-el (38.0) experimental; urgency=medium
.
[ Nicholas D Steeves ]
* Drop elpafied pkgs from goodies customisation group.
* Add elpafied packages to emacs-goodies-el's Recommends.
* Drop highlight-completion.el (Closes: #581238).
* Add debian/NEWS, to provide a short introduction to how this
package is changing, particularly as this will affect xemacs users.
* Document the state of emacs-goodies-el's subpackages in README.Debian.
eg: Elpafied, Dropped, or Transitioned to a suitable replacement.
* Drop browse-kill-ring.el (it was elpafied).
* Drop home-end.el, which is dead upstream (Closes: #759721).
* Drop htmlize.el (it was elpafied).
* Drop diminish.el, which was elpafied (Closes: #850151).
* Drop csv-mode.el, which was elpafied (Closes: #495989).
* Drop show-wspace.el, which is obsolete and dead upstream.
See Bug #590994 for more information.
* Fix typos in README.Debian.
* Drop filladapt.el, which is dead upstream (Closes: #552164).
* Drop tail.el, which is dead upstream (Closes: #584305).
.
[ David Bremner ]
* Patch emacs-goodies-el.texinfo. Bug fix: "emacs-goodies-el info manual
ccmode xref", thanks to Kevin Ryde (Closes: #591432). Note that this
file will eventually go away.
Checksums-Sha1:
dbc98687b7d0768419aafe56ea93ef7566a4dede 1707 emacs-goodies-el_38.0.dsc
be30a3ea08e8f17cc7af5862bbab4e8f48ed0180 589632 emacs-goodies-el_38.0.tar.xz
Checksums-Sha256:
362fea1fa612efd7e068353ae83134e7753794b7319bf75116b5bf884fbe1591 1707 emacs-goodies-el_38.0.dsc
9f22572459be66d35ac3fbc017de470808128217962b89a9e7243645e5d7c8a3 589632 emacs-goodies-el_38.0.tar.xz
Files:
b61c4664230e4437643ff9346b460e72 1707 editors optional emacs-goodies-el_38.0.dsc
682bca9ee3066ab3fd1d0e24de9c2305 589632 editors optional emacs-goodies-el_38.0.tar.xz
-----BEGIN PGP SIGNATURE-----
iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAls3YGkACgkQ8gKXHaSn
niyOlAv+ODtobtRNYosaEoV6V1rKX5+0AYVHUnvYKr4P/2mJy23GhcwZJTnLByWT
mYLdYLrZN8kh+ou97HQso9CE7vNUCB/OY1F15lZZW0sHfZHt6A+spLXhpcyB6LLQ
YO+seQoPlLPzxjenuuBZNfSCeh1pElLm8z2Za/djoSmMAbPBAW1f2cbGBLbK/w/4
OzsVKTiK2OT1id3FGTgIU3fx89P/xIXqnPShSn4hw9m007k0cV1ExG1U3X9LyCSm
+9x3ooIoMWw2GQMh7z8zNpDmI0CsA20SgFG4jMz3NDljGVA57xo91AHtwTIZME9l
DmI2AMcF4+Dp5+GAXB9axEfU2nHbOuqh2Nl2thgtPOOA/TaHU5bFaKV1iFmL674S
CxfcPsD1IW56xtf0TOFhTHzydcD9KKu83H3D/vL8eNBHlcA/JZqklhtXR3wVxc4X
vZqynmGnPrlxRGxT8pZtqRUVTlngwnG0fz8JAIlfSGewE+Wg9qxUhtDGpXluig9g
wG9XA8la
=RF2q
-----END PGP SIGNATURE-----
Hi David, After four unsuccessful attempts to contact the original authors of home-end.el, I re-wrote it to remove some minor bugs and quibbles[1], and think I've prepared it properly for MELPA [2][3]. This MELPA stuff is new to me, and a few of the steps were unclear to me, so I'm not sure whether my submission will be accepted. If it is accepted, I would be available to maintain other 'retired' components of debian's `emacs-goodies'. Let me know. Also, if you are familiar with submitting to MELPA, I'd like to ask you a question about it off-line. [1] https://github.com/Boruch-Baum/MELPA_misc_contrib [2] https://github.com/Boruch-Baum/melpa/pull/1 [3] https://github.com/Boruch-Baum/melpa/pull/2 Kind regards,
My prior email had wrong links for my MELPA pull requests. The correct links are: https://github.com/melpa/melpa/pull/5594 https://github.com/melpa/melpa/pull/5595
ref: https://github.com/melpa/melpa/pull/5594 The method I used to re-write 'home-end' for MELPA was to first write a small generic el that handles an arbitrary number of responses for an arbitrary number of repeated key-presses for an arbitrary key (I'm calling it 'keypress-multi-event'), and then have my version of 'home-end' use that as its back-end. For the purpose of debian packaging, should those two files (each very small, BTW) be packaged separately? Does debian want each small file to be in a separate repository (eg., on github). Also, does debian have any strong feelings on where such a repository should be hosted (eg. microsoft). In the bigger picture, I question the 'efficiency' of administering emacs packages this way. Debian is setting itself up for a tremendous amount of work involving potentially hundreds of MELPA packages. Going through the use-cases and scenarios in my head, it doesn't make sense to me that on the one hand debian is not restricting individual user accounts from using MELPA (eg. by removing / patching-out functions from package.el ), but on the other hand is curating a MELPA subset that individual user accounts would potentially be duplicating in their local user-space, with much potential for version mis-matching. Two alternatives to consider would be to: 1] Package nothing that is available on MELPA; let MELPA handle it, and let individual users curate packages for themselves (debian already allows them to self-curate using MELPA, anyway); 2] Package the entirety of MELPA as a single debian package, and remove the package.el functionality of external downloading (hear me out, please...) 2.1] A user-account could always 'opt-in' to over-ride that policy by copying 'package.el' from an external source. 2.2] This would allow debian to curate all MELPA packages using a blacklist method of patching the *single* debian package (ie. to remove a MELPA component deemed insecure / unsafe), much simpler than managing n < zillion small debian packages. 2.3] On large enterprise debian installations (eg. universities), this would save a lot of redundant bandwidth and storage, since all of MELPA would already be local. 2.4] Currently, if a debian administrator does want to locally offer all MELPA packages that are currently packaged by debian, is there even a way to simply do that? I see no meta-package that brings in all of them, and the naming convention is inconsistent. 2.5] Debian could similarly address the policy conflict between MELPA and emacswiki users such as Drew, by curating a similar single curated package for emacswiki content (maybe in that case a lot of red-ink blacklisting to happen for all the very old cruft that might be there, but that would be a one-time operation, and could be simplified by using a modification date cut-off).
Dear Boruch, They can be in the same repository, if the intent is for home-end.el and keypress-multi-event.el to always have equal versions and every update to one file necessitates upgrading both packages, because a tag stores the state of the branch. Is that the intent? Magit did it this way for a while. If keypress-multi-event.el is a library that would be useful to most GNU Emacs users, then—ideally—a patch should be submitted to GNU Emacs. I noticed that you're willing to assign © to the FSF, so maybe this is the plan? It makes sense to keep them as separate files to make upstreaming a portion of your work easier rather than merging keypress-multi-event.el into home-end.el :-) As a counterpoint, Elpy (many files!) currently bundles yasnippet-snippets that are useful to Python programmers who don't use elpy, so I'm in the middle of a PR to merge them into yasnippet-snippets. After that they will be unbundled. Thanks to Sean Whitton for pointing this out, and for Jorgen Schaefer (upstream maintainer of Elpy) for ACKing the unbundling. From what I've heard from others, Github is fine...I think it's up to you. Proportionally few projects migrated from Github to Gitlab following the Microsoft acquisition, and personally I think that Github will probably remain the Linkedin of code. One reason emacs-goodies-el is being broken up is to distribute the burden of maintenance of x packages between y volunteers, where previously it was 1 mega-package that no one had time to maintain. [3] and elpa-bar-mode=1.0; list-packages will display the status "external" for both packages, and list-packages will not upgrade these packages from MELPA to MELPA versions. A user wants to install, from MELPA, zebra-1.0, which depends on libfoo-1.5. After selecting libfoo from the menu, the *Help* buffer will show zebra-1.0 as "Status: Incompatible in /path/to/lib-foo-1.0". Installing an elpafied Debian package protects the user from upstream changes to elisp libraries (eg: not rolling). If a user wants wildebeest-5.0, from MELPA, and has not installed elpa-wildebeest, and wildebeest-5.0 depends on <=libfoo-1.0 then a user can install this package from MELPA. Installing packages from MELPA via Packages.el is not curation. Maintaining a separate list of packages or a puppet configuration might count as a weak form of curation (creating a list assigns value). Already implemented on a per-elpa package basis, see above. That's not curation, that's replication with a blacklist. The following process is, at best, weak curation: 1) build a whitelist 2) maintain this whitelist by adding and removing elements. Finally, no one is going to do a copyright review for the entirety of MELPA, so the entirety of MELPA will never be part of Debian...nor should it be. [3] Unmaintainable mega package that is impossible to QA as a whole. We dropped a handful of packages from emacs-goodies-el that were below the 20th percentile of downloads counts, even though they were on MELPA. If a user misses one we'll bring it back of course :-) "Every package" is a massive exploitable attack surface (and source of bugs) and will slow down package upgrades and Emacs initialisation, not to mention impossible to QA. A MELPA mirror or a web cache would also save bandwidth. This should do the trick apt install elpa-.* Package-foo might still exist as a transitional package to elpa-package-foo. Please mention a few packages (from MELPA) that don't have a corresponding elpa-package. Those are outliers that need to be elpafied. https://github.com/melpa/melpa/issues/2342 To the best of my knowledge, this is not going to happen in Debian either. Yes, curating a blacklist is a weak form of curation; however, curating a blacklist against an unbounded package set is more work than curating a (bounded) whitelist...and emacs-goodies-el was the package that held curated emacswiki content. AFAIK it also curated lisp files from mailing lists and personal web pages before that. Transitioning away from years of history and uncountable hours of hard work maintaining this monolith towards a set of packages is 86% complete. Curation is a more involved process than maintaining lists. P.P.S. You mentioned you're at debconf? To meet the team, #debian-emacs on irc.oftc.net Cheers, Nicholas
I don't have a specific intent. From the programming design perspective it makes sense to maintain them independently, but from the perspective of a distribution, it would be piling on two more debian packages for a very minor feature of a program. For a person not using either MELPA or debian, it means an extra download / un-compress operation. No, but if they want it, they already know who I am, and I'm happy to perform the assignment. Huh? How does that math work? How do you auto-magically get those more volunteers (rhetorical question, no need to answer in writing)? $ apt-cache show emacs25 |grep dh-elpa I'm not getting an indication that debian is requiring / suggesting / recommending the install of that package. Should I file that as a bug against all emacsen? How? I then thought that maybe the dependency should only be upon the class of debian elpa-* packages, but performing the same check for elpa-org likewise came up with nothing (BTW, isn't org-mode now packaged by fsf itself as part of emacs, and installed by all debian emacs core packages?). tldr; (nothing personal, just not for now, for me). Now that's a real policy issue to respect, if you aren't respecting MELPA's own due diligence. Maintenance and QA of the mega-package is by upstream, as is the case for emacs itself (the mother of all mega-packages - my latest head-slap is 'M-x proc-ed' ...); why should debian be micro-managing individual features / extensions of such mega-upstream-packages on an opt-in basis? (another question for your consideration but don't need to respond here in writing). ... that already exists currently for the entire emacs community. Any individual component would still need to be manually installed / loaded by the individual user-account, but it would be a completely local operation, not requiring a specific site-wide intervention of a sysadmin. If I understand you correctly, quite the opposite. The semi-automatic site-wide upgrading of debian by a sysadmin is going to be more current, consistent, and reliable than that of each individual user-account remembering to manually check and update their local MELPA downloads. Ah, I wasn't clear. My intent was not to propose that debian have emacs load all MELPA packages upon launching any emacs instance, only that debian offers a debian-ized MELPA copy, with blacklist curation. Upstream MELPA does that. That is close to what this proposal would be doing. started with the MELPA package wanderlust, which exists as two debian (seemingly non-transitional) packages, named: wl and wl-beta. Also, check out debian packages git-el, mu-cite, apel, flim, w3m-el, w3m-el-snapshot, puppet-el, notmuch-emacs, semi, tuareg-mode. At that point I stopped. You only need to black-list known bad actors that for some reason MELPA hasn't already black-listed. Nope. I could be available to help out some, but it might require someone to do some hand-holding me through the parts of the initial process (I did start and eventually abort a DM effort a few years ago). Best wishes for an enjoyable and productive trip.
I've prepared this as a set of two github repositories for MELPA, which has accepted them for their purposes. If debian would like to build a package for it, the repositories are at: https://github.com/Boruch-Baum/emacs-home-end https://github.com/Boruch-Baum/emacs-keypress-multi-event MELPA insisted that they be divided into two separate MELPA packages / github repositories; if debian wants to combine them into a single debian package, that's fine with me.